Hallo und guten Morgen,
Zum Anfang würde mir auch schon sowas wie ein incrementelles Backup per SSH reichen, was ich per Cron stündlich einspiele.
Incrementelles Backup ist bei Datenbanken, speziell wenn sie etwas größer werden, nicht mehr lustig. Um damit später die Daten wiederhersstellen zu können, müsstest Du bei MySQL auch das binary Log aktivieren und das schreibt ruck-zuck deine Platte voll.
Es ist auch immer fraglich, was sinnvoller ist. Einen Snapshot der gesamten Datenbank zu bestimmten Zeiten einzufrieren, oder eine Real-Time Synchronisation durchzuführen. Bei der Synchronisation ist auch die Kopie kaputt, wenn jemand Schindluder damit treibt.
Bei MySQL auf Linux-Systemen hat es sich bis zu einer bestimmten Größe der DB als zweckmäßig erwiesen, den Datenbankserver kurz herunterzufahren (disable Login und flush Buffers reichen meistens), die Dateien innerhalb des Hosts auf eine zweite Platte zu kopieren. Zweite deshalb, damit der arme Actuator der Platten nicht vor lauter Sprüngen heiß läuft...
Dann kannst Du den Server schon wieder aktivieren.
Die Kopie kannst Du dann in Seelenruhe in einen Tarball verpacken und kompromieren. Das dauert etwas, deshalb sollte man den Vorgang vom Kopieren getrennt durchführen. Den kompromierten Tarball kannst Du dann noch einmal über Leitung auf ein fernes Gerät kopieren. Damit sollten die Kriterien für eine klassische Datensicherung schon fast erfüllt sein: drei inhaltlich identische Versionen (1 Original und 2 Kopien) derselben Daten auf drei getrennten Datenträgern an drei getrennten Orten aufbewahren.
Grüße
TS