Tach,
Ja, aber bei 1-2 mal täglich spielt es eher weniger eine Rolle, ob es mal nicht klappt, wenn der Backup-Prozess abbricht. Dann hat man entweder eine alte oder gar keine Dump-Datei. Das Ergebnis des Einlese-Jobs ist dann das gleiche als wenn das eine Backup-plus-Transfer-und-Einlesen-Script abbricht.
vermutlich, aber ein möglicher Worst-Case wäre: der Dump bricht in der Mitte ab, erstellt dabei aber einen syntaktisch korrekten Dump und der SQL-Server verabschiedet sich, kurz danach wird der teilweies vorhandene Dump eingelesen und auch auf der Backup-Kiste fehlen jetzt einige Tabellen.
Etwas mehr Kontrolle (für Fehler in beiden Szenarien) könnte man mit Monit hinbekommen. Wenn Dateidatum sich nicht ändert oder Größe = 0 ist, dann schrei(b eine EMail).
Aber wozu weitere Software installieren, wenn das alles problemlos mit den schon vorhandenen Mitteln machbar ist, um die Mail kümmert sich ja schon cron.
Ich meine
/usr/bin/mysqldump -A |gzip - >/var/backups/mysql.gz && \
/usr/bin/scp /var/backups/mysql.gz user@host:/var/backups/mysql.gz && \
/usr/bin/ssh user@host "/usr/bin/gunzip < /var/backups/mysql.gz | /usr/bin/mysql"
(ungetestet, vermutlich nicht ganz richtig und schickt vermutlich mails, weil irgendwo Ausgaben passieren) ist ja nun kein Hexenwerk.
Weiterer Vorteil meiner Methode ist, dass alles nur an einem Ort konfiguriert werden muß, es erzeugt keine Probleme, wenn mal die Serverzeit divergiert ...
mfg
Woodfighter