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

Beitrag lesen

Moin Moin!

Interessante Ausführungen.

Ich ging bisher davon aus, dass die tar-Lösung "die" Lösung ist.

Für Tapes ja (daher der Name ...).

Für Platten "geht" tar auch, aber eben mit den genannten Einschränkungen.

Ein weiterer Vorteil von tar kann sein, dass man das ganze Backup in einem Container hat und nicht einen ganzen Dateibaum "umtopfen" muß. Eine tar-Datei kann ich problemlos auch z.B. in ein FAT-basiertes Dateisystem schreiben, ohne dass mir die Meta-Informationen (insbesondere Owner und Mode) der Originaldaten verloren gehen. Das klappt mit rsync natürlich nicht (außer man bastelt mit Image-Dateien und Loop-Mounts).

Und tar hat den Vorteil, "dumm aber schnell" zu sein. Tar schreibt abwechselnd einen Header-Block und den Dateiinhalt (gepadded auf Blockgröße), auch z.B. über eine SSH-Verbindung oder einen Raw TCP Socket. Das geht mit wenig Resourcen und wenig Rechnerei. rsync berechnet ständig Prüfsummen, spart dann aber insbesondere nach dem ersten Lauf jede Menge Datenvolumen auf der Verbindung.

Allerdings kenne ich das auch nur in kleinerem Maßstab wo dann z.B. Virtual Hosts gesichert werden und jeder in ein einzelnes tar-File kommt. Da sind die einzelnen Files selten größer als 5 GiB.

Eben. Ich denke auch, dass da irgendwo die sinnvoll nutzbare Obergrenze (auf aktueller Hardware) ist.

Auf zuverlässigen Datenträgern (sprich: Festplatten im Gegensatz zu Tapes und Floppies) kann man tar auch wunderbar komprimieren. Weil die Komprimierung komplett extern ist, kann man auch den jeweils besten Komprimierer benutzen, ohne am tar etwas ändern zu müssen (z.B. compress, gzip, bzip2, lzma).

Auf Tapes komprimiert man besser nicht, denn die Komprimierer vertragen keine Fehler in den Datenblöcken.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".