Die bekannte Software BorgBackup erstellt und verwaltet eure Backups. Neben Verschlüsselung bietet BorgBackup auch die Features Kompression und Deduplizierung. Ohne Kenntnisse über interne Vorgehensweisen (also aus Anwendersicht) schaue ich mir diese beiden Punkte genauer an.
Auch wenn Speicherplatz immer günstiger wird, so will man doch unnötigen Platzverbrauch vermeiden. Deshalb schaue ich mir anhand eines Praxisbeispiels die Auswirkungen von Komprimierung und Deduplizierung an und schaue unter welchen Voraussetzungen das beste Ergebnis erzielt wird. Nebenbei können wir auch noch einen Blick auf die benötigte Zeit werfen.
Kompression
Bei der Kompression werden auf eine Datenmenge Algorithmen angewendet, die die Daten auf die wesentlichen Informationen reduzieren. Man unterscheidet hier zwischen verlustbehafteten (bspw. bei JPEG-Bildern) und verlustfreien (hoffentlich bei euren Backups :-) ) Verfahren. Aus letzterem erhält man nach der Dekompression die vollständigen Daten wieder zurück.
Deduplizierung
Die Deduplizierung ist Teil der meisten Kompressionsverfahren. Im wesentlichen geht es dabei darum das mehrfache Vorkommen von Daten zu vermeiden. Dazu speichert man in der Regel an den sich wiederholenden Stellen einen Verweis auf schon gespeicherte Daten. Der einfachste Fall wäre ein zweites Backup einer Datei, die sich nicht verändert hat. Da verweist man dann einfach auf die bereits vorhandene Kopie.
Wie genau BorgBackup Deduplizierung einsetzt war mir vor dem Experiment nicht ganz klar. Vergleicht es nur Dateiweise im Bezug auf bereits existierende Backups? Eine andere Möglichkeit wäre das tiefer in die Daten geschaut wird und auch einzelne Ausschnitte dedupliziert werden anhand der bereits existierenden Backups. Meine Hoffnung war allerdings das BorgBackup noch einen Schritt weiter geht und auch innerhalb eines Backups, was gerade erstellt wird, doppelte Datenblöcke entfernt.
Die Beispieldaten
In meinem Beispiel möchte ich 127 Datenbankdumps backuppen. Die Dumps sind zu verschiedenen Zeiten innerhalb eines Monats entstanden und enthalten daher zu 95% identische SQL Statements. Aus genau diesem Grund möchte ich hier den Vorteil der Deduplizierung richtig ausnutzen.
Die Dumps sind jeweils etwa 520 MB gross, wurden von mir aber bereits mit gzip komprimiert abgespeichert und daher noch jeweils etwa 75 MB gross. Insgesamt reden wir hier also von rund 70 GB an Daten auf der Festplatte komprimiert zu 9,8 GB.
Die Idee
Es ist ein leichtes zu überprüfen ob die Deduplizierung von BorgBackup greift, wenn ein zweites Backup der gleichen Dateien erstellt. Bei jedem Versuch benötigte ein weiteres Backup weniger als 1 Kilobyte Speicherplatz.
Interessant ist in diesem Beispiel also nur das erste Backup. Die Idee ist, das sich Deduplizierung auf meine komprimierten Dateien deutlich schlechter anwenden lässt als auch den unkomprimierten Inhalt. Gleichzeitig will ich prüfen ob BorgBackup auch innerhalb eines Backups und ohne bestehende Datenbasis dedupliziert. Für jeden Versuch hab ich ein neues Borg Repository angelegt, also bei einem Datenbestand von 0 angefangen.
Die Referenz
Machen wir also ein Backup der mit gzip komprimierten Daten und schauen uns das Ergebnis an.
Ok, wie erwartet bringt die Komprimierung von bereits komprimierten Dateien fast gar nichts. Die Deduplizierung bringt noch ein wenig, rund ein halbes GB.
Backup der Plain-Text-Files
Jetzt dekomprimieren wir die Dateien auf der Platte und geben BorgBackup die ganzen 70 GB als Textdateien rein.
Das sieht schon anders aus. Ein Backup der gleichen Daten, aber nur halb so viel Speicherplatz benötigt. Gut das ganze hat doppelt so lange gedauert, aber die gzip Komprimierung hat irgendwann in der Vergangenheit auch mal Zeit in Anspruch genommen.
Anhand der Angabe „compressed size“ sieht man das BorgBackup nicht mit gzip arbeitet. Standardmäßig ist hier die lz4 Kompression eingestellt. Lassen sich also lz4 komprimierte Dateien besser deduplizieren? Noch ein Versuch.
Backup von lz4 Dateien
Also hab ich die Dateien auf der Festplatte vor dem Backup mit lz4 komprimiert und wiederum ein Backup erstellt.
Ernüchterndes Ergebnis. Die Deduplizierung bringt auch hier wenig, dafür brauchen wir den meisten Speicherplatz und etwa die gleiche Zeit wie bei den unkomprimierten Dateien. Lz4 ist als genauso schlecht deduplizierbar wie gzip.
Komprimierung abschalten
Rein aus Neugier noch ein Test was die Deduplizierung bei meinen Dateien eigentlich bringt ohne zu komprimieren. Also wird die Komprimierung bei BorgBackup ausgeschaltet und wieder mit den Plain-Text-Dateien gearbeitet.
Die reine Deduplizierung bringt also schon fast so viel wie eine Komprimierung mit lz4. Hier wurde einiges an Daten über die Leitung geschickt, daher dauert das ganze natürlich länger. Aber das war ja auch nur just for fun.
Fazit
Natürlich war das hier ein Beispiel in dem extrem viele Duplikate waren, aber dennoch sollte man sich Gedanken machen ob es Sinn macht die Daten gleich komprimiert zu speichern oder das ganze der Backup-Software zu überlassen. Dabei kommt es sicherlich auf die Art der Daten an und wie wichtig einem der Platzverbrauch sowohl auf dem Quellsystem als auch im Backupsystem ist. Erstellt man bspw. regelmässig ein .tar.gz-File von einem Ordner mit hunderten Dateien wo sich nur wenige ändern und erstellt davon Backups, so kann BorgBackup nur sehr begrenzt seine Stärken ausnutzen.
Mich würde interessieren, was es bringt, wenn man mehrere KVMs hat, die z.B. alle den gleichen Kernel und viele gleiche binaries in /usr/bin haben. Wenn man die KVM images sichert (z.B. nach Ausschalten der KVMs), wie gut ist dann die Deduplizierung.
Ich würde vermuten das verhält sich wie im Referenzbeispiel, also bringt schon ein wenig aber nicht das volle Potential. Aber das ist nur eine Vermutung. Das hängt stark vom Dateiformat ab, wie da die Daten organisiert bzw. strukturiert sind.
Ich wurde sagen garnix da jede kvm image eigenstandig ist. Problem ist auch das im laufenden betrieb du kein sicheres backup erstellen kannst von einer qcow2 image.
Du musstest schon borg in der kvm laufenlassen und alle kvm in ein und der selben repo backupen dann wurde es etwas bringen.
Hallo wie verhält es sich bei Kompression der Festplatte komplett, bei "Bitkipper" oder wenn ein Sektor / Byte defekt ist, ist dann "alles weg" oder wird das durch "Quersummen" korrigiert. Die Frage betrifft nicht nur das vorgestellte Programm sondern allgemein. Zum Beispiel: eine ZIP-Datei ist dann komplett defekt. Gruß Gast
All das kann ZPAQ bzw. der noch gepflegte Fork zpaqfranz übrigens auch - und zwar mit einer noch wesentlich besseren Kompression. :-)
Wenn es freie Software ist, schreib doch mal einen Artikel darüber bei gnulinux.ch :)
Interessanter Artikel. Borg war mir bisher unbekannt. Ich nutze für mein außer Haus Backup restic (https://restic.net/). Hat jemand Erfahrung wie sich restic gegen Borg "schlägt"?
Mach doch mal ein eigenes Experiment und berichte hier darüber. Wird bestimmt interessant
Wenn ich das richtig verstehe nutzen Borg und auch restic "content-defined chunking" (siehe https://borgbackup.readthedocs.io/en/stable/index.html#main-features). Die Daten werden also zunächst auf Basis von Merkmalen im Inhalt in kleinere Segmente zerteilt. So müssen identische Segmente, die sich dabei ergeben unabhängig aus welcher Datei oder Backup-Durchlauf sie stammen, nicht mehrfach gespeichert werden, was zu der Deduplizierung führt. Ich bin mir nicht sicher, wo genau bei Borg die Kompression ansetzt. Nach der Zerstückelung würde es Sinn ergeben.
Das Problem bei den vorher angewendeten Kompressionsverfahren ist, dass gleiche Datenabschnitte meist auf kleinerer Ebene einerseits zum Teil schon wegkomprimiert und andererseits auch nicht mehr zwangsläufig identisch sind. Im Artikel ging es um das initiale Backup. Aber gerade bei inkrementellen Sicherungen würde die Deduplizierung von nicht komprimierten Daten besser funktionieren. Denn kleine Änderungen in den Ausgangsdaten können je nach Verfahren größere Änderungen in den Komprimierten Daten hervorrufen.
Stark redundante Daten und Daten, die sich über die Zeit teilweise ändern, sollten eher nicht vor dem Backup komprimiert werden, wenn man Platz auf dem Backup-Medium sparen möchte.
Danke für den technischen Hintergrund. Mein Experiment scheint das ja zu bestätigen :)
Toll einmal einen Artikel über Borg zu lesen. Ich benutze Borg seit längerer Zeit um direkt, komprimiert und verschlüsselt in die Cloud zu sichern. Nach etwas längerer erster Backupzeit für ein neues Repository sind anschließende Aktualisierungen gerade im Dokumentenbereich schnell und "schmal" erledigt. Als graphisches Frontend für Borg verwendene ich Vorta was unter Gnome (arch) bei mir gut und stabil funktioniert. Sicherungen in die Cloud matche ich gerne mit RCLONE und fixer Zuordnung in der FSTAB.