täglich große Menge an Daten sichern (nur neue und geänderte)

[Alexander (HH)]

Moin Moin!

Wie wär es damit?
http://www.gnu.org/software/automake/manual/tar/Incremental-Dumps.html

"Incremental dumps depend crucially on time stamps, so the results are unreliable if you modify a file's time stamps during dumping (e.g., with the ‘--atime-preserve=replace’ option), or if you set the clock backwards." Da ich mein Backup im laufenden Betrieb mache (wenn auch mit abgeschaltetem fetchmail, und erst nachdem ich meine PgSQL-DB in eine Datei gedumpt habe), ist das quasi das K.O.-Argument. Erschwerend kommt dazu, dass auf dem Server ein ntpd läuft, der gelegentlich mal etwas an der Uhr dreht. rsync nörgelt zwar auch, wenn man ihm die Datei oder deren Meta-Daten unter den Fingern verändert, aber es arbeitet weiter. Man hat dann im dümmsten Fall für die betroffene Datei einen inkonsistenten Stand.

Tar ist sehr allergisch auf Programmabbrüche und hinterläßt dann eine unbrauchbare Datei. rsync kann man recht gnadenlos neu starten, die gerade gesyncte Datei ist zwar im Worst Case vorübergehend kaputt, aber der nächste Lauf behebt das. Und so lange ich nicht die Tages-Rotation starte, kann ich das notfalls beliebig oft machen, bis der Tag gesichert ist.

Tar hinterläßt eine einzige, riesige Datei (bzw. eine Sammlung weniger großer Dateien). Auf meiner Datenpartition liegen aktuell 873 GByte, die müßte Tar beim ersten Lauf (Voll-Backup) in eine einzige Datei von rund 880 GByte schreiben. Theoretisch müßte mein System das können -- wetten möchte ich darauf nicht. rsync legt einen identischen Dateibaum in einem Unterverzeichnis der Festplatte an, mit handhabbaren Dateigrößen.

Tar erzeugt eine Basis-Datei mit dem Voll-Backup und dazu einige Inkrement-Dateien. Für ein Restore einiger weniger Dateien muß man alle Tar-Dateien durchwühlen lassen -- sequenziell, denn TAR hat keinen Index. Das dürfte gruselig langsam werden. Mit rsync kann ich direkt auf einen identischen Dateibaum zugreifen und mir gelöschte oder beschädigte Dateien mit mount, cp, umount zurückholen (wobei ich statt cp meistens den mc benutze).

Unbegrenzt viele Inkrements erzeugen also unbegrenzt viel Ärger beim Restore. Daher muß gelegentlich ein neues Voll-Backup her. Noch einmal 880 GByte auf die ohnehin "nur" 2 TByte große Platte. Zusammen mit den alten Inkrements dürfte die Platte damit fast voll sein. Das alte Voll-Backup darf ich aber nicht sofort löschen, denn ich will ja einige Tage zurück in die Vergangenheit gehen können. Und das geht nur mit dem alten Voll-Backup und den darauf folgenden Inkrements. Erst wenn ich mit dem zweiten Voll-Backup und dessen Inkrements die Mindest-Frist (9 Tage) garantieren kann, darf ich das alte Voll-Backup und dessen Inkrements löschen. Die Backup-Platte enthält also sehr lange mehr Daten, als ich eigentlich haben will. Über den groben Daumen belegt das Backup mindestens doppelt so viel Platz wie die zu sichernden Daten. Die Kombination aus cp -al, rsync, und Rotation belegt dagegen immer nur Platz für die Mindest-Frist, hält alle Dateiversionen nur jeweils einmal vor, und belegt aktuell 882 GByte für 873 GByte Daten und 9 Tage Historie.

Gegenüber Tar spart rsync hier fast 1 TByte, ich hab also noch einige Jahre Zeit, bis meine Sammelwut die Datenpartition auf knappe 2 TByte aufgebläht hat. Dann sollten auch größere E-SATA-Platten zu akzeptablen Preisen auf dem Markt sein, die die Backup-Platte ersetzen können. Mit Tar hätte ich die vollgelaufene Backup-Platte vermutlich noch dieses Jahr.

Tar paßt sehr genau auf die Meta-Daten (Timestamps, Rechte, Owner) auf, rsync ist da etwas relaxter, was gerade in Kombination mit den Hardlinks Probleme machen kann. Mich stört's nicht wirklich, die Timestamps sind mir ziemlich egal, ebenso Rechte und Owner. Die wenigsten Programme kümmern sich um Timestamps, Rechte und Owner ändere ich nur extrem selten.

Würde ich auf Band statt auf Platte sichern, sähe die Situation natürlich völlig anders aus, denn dann nützt rsync nichts. Bandlaufwerke lassen sich eben nur sequenziell ansprechen, man kann nicht ohne extreme Wartezeiten zwischen beliebigen Stellen auf dem Band hin und her springen. Damit gibt es kein wirkliches Dateisystem auf dem Band (nur ein paar Marker), und rsync kann nicht arbeiten.

Bandlaufwerke sind aber -- verglichen mit externen Platten -- extrem teuer und haben Anforderungen, die eine Platte nicht hat: Regelmäßige Reinigungszyklen, tägliche Bandwechsel, und eine Mindestbandbreite beim Schreiben.

Alexander