Seit einigen Wochen experimentiere ich mit Borg Backup als mögliche Lösung für mein neues, privates, Backup Konzept. Die Ziele dieses Konzeptes würden den geplanten Umfang dieses Artikels sprengen, ich möchte an dieser Stelle daher nur auf einen älteren Artikel von mir zum Thema Datensicherung verweisen.
Im Zuge der Planung für dieses neue Konzept habe ich verschiedene Backup Programme getestet und anschließend rein subjektiv bewertet. Neben einer möglichst einfachen Benutzbarkeit war es mir auch wichtig, möglichst effektiv an meine gesicherten Daten zu kommen und gleichzeitig gut mit inkrementellen Sicherungen arbeiten zu können.
Ohne die Alternativen zu erwähnen, war Borg Backup das Resultat meiner "Forschungsarbeit", es vereint die Möglichkeiten der Kompression, Deduplizierung als auch Verschlüsselung in einem Tool, zusätzlich ist es möglich, ältere Datenstände per FUSE Dateisystem direkt verfügbar zu machen.
Sobald man sich für ein Backup Programm/Tool entschieden hat, geht es jedoch schon an dessen Konfiguration. Ein wesentlicher Aspekt, ist hierbei das verdichten von Daten mittels Kompression, und der sich daraus ergebende Gewinn an Speicherplatz unter Einsatz wertvoller CPU Zyklen. CPU Zyklen kosten Geld, bedingt durch die dafür nötige Energie. Je nach verbautem Prozessor, im für die Datensicherung notwendigen Rechner, wird Wärme erzeugt und Energie beim Energieversorger verrechnet.
Doch nicht nur die ökologischen und wirtschaftlichen Gesichtspunkte sollte man beachten, sondern auch das ein größerer Zeitverbrauch auch bedeutet das die Sicherungszyklen länger werden müssen. Als Referenz dient hierbei die Zeit, welche erforderlich ist, eine inkrementelle Sicherung zu erzeugen. Dauert es 2 Stunden die 500 GiB zu sichernden Daten auf Änderungen zu prüfen, diese zu komprimieren und anschließend zu sichern, dann kann minimal alle 2 Stunden eine neue Sicherung erzeugt werden.
Lange Sicherungszyklen führen dabei automatisch zu einem Zeitfenster in welchem ungesicherte Änderungen im Schadensfall verloren gehen. Die beiden Ziele, eine möglichst gute Kompression zu erreichen, und gleichzeitig möglichst schnell zu sichern, stehen also im Widerspruch. Bei den heute erzielbaren Preisen für zusätzlichen Speicherplatz (€/TB) ist es eine Überlegung wert nicht bestmöglich, sondern stattdessen so gut wie nötig, zu komprimieren.
Zuletzt bestehen unsere heute verfügbaren und sehr großzügig bemessenen Datenmengen auch primär aus Daten, die sich schlecht bis kaum komprimieren lassen. Wer eine große Musik und Filme Sammlung sein eigen nennt, kann hiervon sicherlich ein Lied singen.
Nach all diesen, hier zumindest grob dargestellten Überlegungen, stellte sich mir die Frage aller Fragen: Wie groß ist der Zeit und Platz Unterschied für die von Borg Backup unterstützten Kompressionsmöglichkeiten? Aktuell bietet Borg Backup folgende Möglichkeiten:
Da es sich bei meinem Testsystem um den Homeserver handelt, schwankte die zu sichernde Datenmenge mit jeweils +/- 10 GiB pro Testlauf. Der Einfluss hiervon auf das Gesamtergebnis ist aber deutlich niedriger als erwartet. Hier kurz und schmerzlos die Ergebnisse im Überblick:
Name: 2016-11-02_17:17:43
Fingerprint: e1a2cf764b5e8f1f024507ec1a9149ffa547583c72e56e0ff0c47c95304be368
Hostname: server
Username: root
Time (start): Wed, 2016-11-02 17:17:43
Time (end): Wed, 2016-11-02 21:54:29
Command line: /usr/bin/borg create --lock-wait 3600 -s -C none /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 244822
Original size Compressed size Deduplicated size
This archive: 532.15 GB 532.15 GB 501.53 GB
All archives: 532.15 GB 532.15 GB 501.53 GB
Unique chunks Total chunks
Chunk index: 407311 442322Name: 2016-10-29_20:22:10
Fingerprint: 19e4c5ada051047065cefad817022a72fe6e3dc24bde1ead47c4080fe41749c8
Hostname: server
Username: root
Time (start): Sat, 2016-10-29 20:22:10
Time (end): Sun, 2016-10-30 01:03:44
Command line: /usr/bin/borg create -s -C lz4 /mnt/backup/weekly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 249949
Original size Compressed size Deduplicated size
This archive: 540.24 GB 533.61 GB 503.59 GB
All archives: 540.24 GB 533.61 GB 503.59 GB
Unique chunks Total chunks
Chunk index: 414894 450402Name: 2016-10-30_13:00:22
Fingerprint: da644b0301e9bcc76ecafa5b221ff3382d0525725a6a502b951d466eb433fadb
Hostname: server
Username: root
Time (start): Sun, 2016-10-30 13:00:22
Time (end): Sun, 2016-10-30 22:58:35
Command line: /usr/bin/borg create --lock-wait 3600 -s -C zlib,9 /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 249302
Original size Compressed size Deduplicated size
This archive: 530.58 GB 515.89 GB 486.54 GB
All archives: 530.58 GB 515.89 GB 486.54 GB
Unique chunks Total chunks
Chunk index: 410586 446084Name: 2016-10-31_18:00:11
Fingerprint: 4e0678501bf551fa57458f9762aacb1c2ee13380a18f1612cf930e786fb93061
Hostname: server
Username: root
Time (start): Mon, 2016-10-31 18:00:11
Time (end): Wed, 2016-11-02 13:28:34
Command line: /usr/bin/borg create --lock-wait 3600 -s -C lzma,9 /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 244775
Original size Compressed size Deduplicated size
This archive: 532.14 GB 514.07 GB 485.11 GB
All archives: 532.14 GB 514.07 GB 485.11 GB
Unique chunks Total chunks
Chunk index: 407571 442572Lässt man diese Ergebnisse etwas auf sich wirken, kommt man auf folgendes Ergebnis:
- Keine Kompression dauert ca. 16606 Sekunden bei 532.15GB zu 501.53GB
- LZ4 Kompression dauert ca. 16894 Sekunden bei 540.24GB zu 503.59GB
- ZLIB Kompression dauert ca. 35893 Sekunden bei 530.58GB zu 486.54GB
- LZMA Kompression dauert ca. 70103 Sekunden bei 532.14GB zu 485.11GB
Die Zeiten hier noch als Tabelle, für den schnellen Vergleich:
| Kompression | Zeit (Sekunden/Minuten/Stunden) | Zeit (Differenz) | Original vs. Compressed Size |
|---|---|---|---|
| Keine | 16606 / 276 / 4.61 | - | - |
| LZ4 | 16894 / 281 / 4.69 | +1.73% | -1.23% |
| ZLIB | 35893 / 598 / 9.97 | +116.14% | -2.77% |
| LZMA | 70103 / 1168 / 19.47 | +322.16% | -3.4% |
Zu beachten ist, dass ich in der zuerst aufgeführten Liste die Größe inkl. Deduplizierung als Referenz genommen habe, in der Tabelle aber tatsächlich nur die Kompression als solches. Deduplizierung brachte unabhängig von der Kompression ca. 6% an Platz ein, was jede der getesteten Kompressionsmöglichkeiten schlägt.
Meine Empfehlung lautet daher LZ4 als Kompression zu benutzen und sich mit dem Rest erst nicht zu beschäftigen, eine Ausnahme dürften Personen sein, deren Daten weitgehend aus komprimierbaren Inhalten bestehen, also z.B. lokale Kopien der Wikipedia oder Quelltext von Programmen. Beim durchschnittlichen Anwender dürfen jedoch Mediendaten der größte Teil der genutzten Datenmenge sein, welche sich eben nur sehr schlecht weiter komprimieren lassen.