🥇Backup, Teil 6: Vergleich von Backup-Lösungen

In diesem Artikel wird ein Vergleich der Backup-Tools durchgeführt. Zunächst sollten wir jedoch klären, wie schnell und effizient sie Daten aus Backups wiederherstellen.
Zum Zweck des Vergleichs wird die Wiederherstellung aus einem vollständigen Backup betrachtet, da dieser Betriebsmodus von allen Kandidaten unterstützt wird. Um die Vergleichbarkeit zu erleichtern, wurden die Zahlen bereits gemittelt (Durchschnitt aus mehreren Durchläufen). Die Ergebnisse werden in einer Tabelle zusammengefasst, die auch Informationen zu folgenden Aspekten enthält: Verfügbarkeit einer Web-Oberfläche, Benutzerfreundlichkeit bei Einrichtung und Nutzung, Automatisierungsfähigkeiten sowie verschiedene zusätzliche Funktionen (z. B. Datenintegritätsprüfung) usw. Grafiken zeigen die Serverlast, auf dem die Daten angewendet werden (nicht der Server für Backup-Speicher).

Datenwiederherstellung

Als Referenzpunkte werden rsync und tar verwendet, da sie typischerweise die Grundlage bilden für einfachste Skripte zur Sicherung von Daten.

Rsync bewältigte den Testdatensatz in 4 Minuten und 28 Sekunden und zeigte

eine solche Auslastung

Der Wiederherstellungsprozess stieß auf eine Einschränkung des Speicher-Subsystems des Backup-Servers (sägezahnförmige Grafiken). Außerdem ist die Auslastung eines Kerns ohne größere Probleme deutlich sichtbar (niedriger iowait und softirq – keine Probleme mit der Festplatte und dem Netzwerk). Da die beiden anderen Programme, nämlich rdiff-backup und rsnapshot, auf rsync basieren und ebenfalls rsync als Wiederherstellungswerkzeug anbieten, wird ihr Belastungsprofil und die Wiederherstellungszeit ähnlich sein.

Tar hat etwas schneller funktioniert, in

2 Minuten und 43 Sekunden:

Die Gesamtlast des Systems war im Durchschnitt um 20 % höher aufgrund eines gestiegenen softirq – die Overheadkosten der Netzwerksysteme sind angestiegen.

Wenn das Archiv zusätzlich komprimiert wird, steigt die Wiederherstellungszeit auf 3 Minuten und 19 Sekunden mit
dieser Last auf dem Hauptserver (Entpacken auf der Seite des Hauptservers):

Der Entpackungsprozess beansprucht beide CPU-Kerne, da zwei Prozesse ausgeführt werden. Insgesamt ist das ein erwartetes Ergebnis. Ein ähnliches Ergebnis (3 Minuten und 20 Sekunden) wurde auch erzielt, als gzip auf der Serverseite mit den Backups ausgeführt wurde; die Lastprofil des Hauptservers war dabei sehr ähnlich wie beim Ausführen von tar ohne gzip-Kompression (siehe vorheriges Diagramm).

In rdiff-backup kann das neueste Backup mit dem normalen rsync synchronisiert werden (die Ergebnisse werden ähnlich sein), jedoch müssen ältere Backups weiterhin mit dem rdiff-backup-Programm wiederhergestellt werden, das die Wiederherstellung in 17 Minuten und 17 Sekunden erfolgreich durchgeführt hat und dabei

eine solche Last erzeugt hat:

Möglicherweise war das so beabsichtigt; jedenfalls haben die Autoren eine solche Lösung zur Geschwindigkeitsbegrenzung vorgeschlagen. bieten eine solche Lösung anDer vollständige Wiederherstellungsprozess benötigt etwas weniger als die Hälfte eines Kerns, mit einem proportional vergleichbaren Leistungsprofil (d.h. 2-5 Mal langsamer) hinsichtlich der Disk- und Netzwerkleistung im Vergleich zu rsync.

Rsnapshot empfiehlt zur Wiederherstellung die Verwendung von normalem rsync, daher werden die Ergebnisse ähnlich sein. Insgesamt hat sich das bewahrheitet.

Burp Die Wiederherstellung der Sicherung wurde in 7 Minuten und 2 Sekunden erledigt mit
dieser Last:

Es hat ziemlich schnell funktioniert und war auf jeden Fall viel bequemer als reines rsync: Man muss sich keine Flags merken, die CLI-Schnittstelle ist einfach und intuitiv, mit integrierter Unterstützung für mehrere Kopien, allerdings ist es etwa doppelt so langsam. Wenn die Daten aus dem zuletzt erstellten Backup wiederhergestellt werden müssen, kann man rsync verwenden, mit einigen kleinen Einschränkungen.

Ein ähnliches Tempo und Last zeigte das Programm BackupPC im rsync-Übertragungsmodus und hat das Backup in

7 Minuten und 42 Sekunden wiederhergestellt:

Im tar-Datenübertragungsmodus war BackupPC jedoch langsamer: Die Wiederherstellung dauerte 12 Minuten und 15 Sekunden, wobei die CPU-Auslastung insgesamt etwa anderthalbmal niedriger war.

um die Hälfte:

Duplicity ohne Verschlüsselung zeigte er leicht bessere Ergebnisse und benötigte für die Wiederherstellung eines Backups 10 Minuten und 58 Sekunden. Wenn die Verschlüsselung mit gpg aktiviert wird, steigt die Wiederherstellungszeit auf 15 Minuten und 3 Sekunden. Zudem kann bei der Erstellung eines Repositories zur Speicherung von Kopien die Größe des Archivs angegeben werden, das beim Aufteilen des Datenstroms verwendet wird. Insgesamt gibt es auf herkömmlichen Festplatten, auch aufgrund des einsträngigen Betriebsmodus, keinen wesentlichen Unterschied. Dieser könnte jedoch bei unterschiedlichen Blockgrößen auftreten, insbesondere bei der Verwendung hybrider Speicherlösungen. Die Belastung auf dem Hauptserver während der Wiederherstellung betrug:

ohne Verschlüsselung

mit Verschlüsselung

Duplicati zeigte eine vergleichbare Wiederherstellungsgeschwindigkeit und benötigte 13 Minuten und 45 Sekunden. Rund 5 Minuten benötigte die Überprüfung der Richtigkeit der wiederhergestellten Daten (insgesamt etwa 19 Minuten). Die Belastung lag dabei

recht hoch:

Als die AES-Verschlüsselung intern aktiviert wurde, betrug die Wiederherstellungszeit 21 Minuten und 40 Sekunden, wobei die CPU-Auslastung während des gesamten Wiederherstellungsprozesses maximal war (beide Kerne!). Beim Datenüberprüfungsprozess war nur ein Thread aktiv, der einen CPU-Kern beanspruchte. Die Datenprüfung nach der Wiederherstellung dauerte ebenfalls 5 Minuten, was insgesamt fast 27 Minuten beträgt.

Ergebnis

Ein wenig schneller bewältigte Duplicati die Wiederherstellung mit der externen Verschlüsselungssoftware GPG, doch insgesamt sind die Unterschiede zur vorherigen Methode minimal. Die Arbeitszeit betrug 16 Minuten und 30 Sekunden, einschließlich der Datenprüfung, die 6 Minuten in Anspruch nahm. Die Auslastung war

so:

AMANDA, das mit tar arbeitete, benötigte 2 Minuten und 49 Sekunden, was im Grunde genommen recht nah an einem normalen tar ist. Die Systemauslastung ist insgesamt

gleich:

Bei der Wiederherstellung eines Backups mit zbackup ergaben sich folgende Ergebnisse:

Verschlüsselung, LZMA-Kompression

Arbeitszeit 11 Minuten und 8 Sekunden

Verschlüsselung AES, LZMA-Kompression

Arbeitszeit 14 Minuten

Verschlüsselung AES, LZO-Kompression

Arbeitszeit 6 Minuten und 19 Sekunden

Insgesamt recht gut. Alles hängt von der Geschwindigkeit des Prozessors des Backup-Servers ab, was sich deutlich in der Laufzeit des Programms mit verschiedenen Kompressoren zeigt. Auf der Seite des Backup-Servers wurde das normale tar verwendet, daher läuft die Wiederherstellung im Vergleich dazu dreimal langsamer. Es könnte sinnvoll sein, die Funktion im Multithread-Modus mit mehr als zwei Threads zu prüfen.

BorgBackup Im unverschlüsselten Modus war es etwas langsamer als tar und benötigte 2 Minuten und 45 Sekunden. Allerdings bietet es im Gegensatz zu tar die Möglichkeit zur Deduplizierung des Repositories. Die dabei erzeugte Last war

folgendes:

Wenn die Verschlüsselung auf Basis von Blake aktiviert wird, verlangsamt sich die Wiederherstellung leicht. Die Wiederherstellungszeit in diesem Modus beträgt 3 Minuten und 19 Sekunden, und die Last betrug

so:

Die AES-Verschlüsselung arbeitet etwas langsamer, die Wiederherstellungszeit beträgt 3 Minuten und 23 Sekunden, die Last hat sich dabei nicht wesentlich verändert:

hat sich nicht geändert:

Da Borg im Multithread-Modus arbeiten kann, ist die CPU-Auslastung hoch, während sich die Laufzeit einfach erhöht, wenn zusätzliche Funktionen aktiviert werden. Offensichtlich lohnt es sich, die Multithread-Funktionalität ähnlich wie bei zbackup zu untersuchen.

Restic hat die Wiederherstellung etwas langsamer bewältigt, die Laufzeit betrug 4 Minuten und 28 Sekunden. Die Auslastung sah dabei

so aus:

Offensichtlich arbeitet der Wiederherstellungsprozess in mehreren Threads, die Effizienz ist jedoch nicht so hoch wie bei BorgBackup, aber zeitlich vergleichbar mit herkömmlichem rsync.

Mit UrBackup konnten die Daten in 8 Minuten und 19 Sekunden wiederhergestellt werden, die Auslastung betrug dabei

so:

Nach wie vor ist die Auslastung nicht sehr hoch, sogar niedriger als bei tar. An einigen Stellen gibt es Spitzen, aber nicht mehr als die Auslastung eines Kerns.

Auswahl und Begründung der Kriterien für den Vergleich

Wie in einem der vorherigen Artikel erwähnt, sollte das Backup-System die folgenden Kriterien erfüllen:

Einfachheit in der Nutzung
Universalisierung
Stabilität
Geschwindigkeit

Es lohnt sich, jeden Punkt einzeln detaillierter zu betrachten.

Benutzerfreundlichkeit

Es wäre ideal, wenn es eine einzige Schaltfläche gäbe, um alles gut zu machen. In der Realität sind jedoch gewohnte und standardisierte Arbeitsweisen oft am bequemsten.
Die meisten Benutzer profitieren wahrscheinlich davon, nicht eine Vielzahl von CLI-Schlüsseln merken zu müssen, verschiedene, oft schwer verständliche Optionen über Web oder TUI einzustellen und Benachrichtigungen über fehlgeschlagene Vorgänge zu konfigurieren. Dazu gehört auch die einfache Integration von Backup-Lösungen in bestehende Infrastrukturen sowie die Automatisierung des Backup-Prozesses. Zudem sollte die Installation über einen Paketmanager oder mit ein bis zwei Befehlen wie «herunterladen und entpacken» möglich sein. curl link | sudo bash — ein komplexer Ansatz, da überprüft werden muss, was unter dem Link erreichbar ist.

Beispielsweise sind unter den betrachteten Kandidaten burp, rdiff-backup und restic einfache Lösungen, da sie sich durch einprägsame Schlüssel für verschiedene Betriebsmodi auszeichnen. Etwas komplexer sind borg und duplicity. Die anspruchsvollste Lösung war AMANDA. Die anderen liegen in Bezug auf die Benutzerfreundlichkeit irgendwo dazwischen. In jedem Fall gilt: Wenn man mehr als 30 Sekunden für die Lektüre des Benutzerhandbuchs benötigt oder Google oder eine andere Suchmaschine konsultieren und ein langes Hilfedokument durchblättern muss, ist die Lösung kompliziert, wie auch immer man es betrachtet.

Einige der betrachteten Kandidaten können automatisch eine Nachricht per E-Mail an Jabber senden, während andere auf die in der Systemkonfiguration eingerichteten Benachrichtigungen angewiesen sind. In der Regel bringen komplexe Lösungen jedoch nicht immer offensichtlich konfigurierbare Benachrichtigungen mit sich. Wenn das Backup-Programm einen von null abweichenden Rückgabewert liefert, der vom Systemdienst der geplanten Aufgaben korrekt interpretiert wird (und die Nachricht an den Systemadministrator oder direkt an das Monitoring gesendet wird), ist die Situation einfach. Wenn jedoch das Backup-System, das nicht auf dem Backup-Server läuft, keine klaren Möglichkeiten bietet, um auf das Problem hinzuweisen, wird es kompliziert. In jedem Fall ist es schlechte Praxis, Warnungen und andere Nachrichten ausschließlich im Web-Interface oder im Protokoll auszugeben, da diese meist ignoriert werden.

Was die Automatisierung betrifft – ein einfaches Programm kann Umgebungsvariablen lesen, die seinen Betriebsmodus bestimmen, oder es verfügt über eine umfangreiche CLI, die das Verhalten der Webschnittstelle vollständig nachahmt. Dazu gehört auch die Möglichkeit der Stream-Verarbeitung, Erweiterungsmöglichkeiten und mehr.

Universalisierung

Dieser Punkt überschneidet sich teilweise mit dem vorherigen Abschnitt zur Automatisierung und es sollte kein großes Problem sein, den Backup-Prozess in die bestehende Infrastruktur zu integrieren.
Es ist erwähnenswert, dass die Verwendung ungewöhnlicher Ports (außer für die Webschnittstelle), die Implementierung von Verschlüsselung auf nicht-standardisierte Weise und der Datenaustausch über nicht-standardisierte Protokolle Anzeichen für eine nicht universelle Lösung sind. Die meisten Kandidaten haben diese Eigenschaften aus offensichtlichen Gründen: Einfachheit und Universalisierbarkeit sind oft nicht kompatibel. Eine Ausnahme ist burp, und es gibt auch andere.

Ein Indikator dafür ist die Möglichkeit, mit gewöhnlichem SSH zu arbeiten.

Geschwindigkeit

Ein sehr umstrittener und diskussionswürdiger Punkt. Auf der einen Seite wird der Prozess gestartet, er läuft so schnell wie möglich und stört nicht die Hauptaufgaben. Auf der anderen Seite verursacht er einen Verkehrsspitzen und eine hohe CPU-Auslastung während der Sicherung. Es ist auch zu beachten, dass die schnellsten Sicherungsprogramme oft die schwächsten Funktionen bieten, die für die Benutzer wichtig sind. Wieder einmal: Wenn man nur eine kleine Textdatei mit einem Passwort abrufen möchte, und aufgrund dieser Datei der gesamte Dienst betroffen ist (ja, ja, ich verstehe, dass hier der Sicherungsprozess meist nicht schuld ist), und man alle Dateien im Repository nacheinander lesen oder ein ganzes Archiv entpacken muss – dann ist das Sicherungssystem alles andere als schnell. Ein weiterer Punkt, der oft zum Streitpunkt wird, ist die Geschwindigkeit beim Wiederherstellen einer Sicherung aus einem Archiv. Hier haben die, die einfach Dateien an den richtigen Ort kopieren oder verschieben können, ohne besondere Manipulationen (zum Beispiel mit rsync), einen klaren Vorteil, aber meist muss das Problem organisatorisch und empirisch gelöst werden: Die Wiederherstellungszeit der Sicherung messen und offen an die Benutzer kommunizieren.

Stabilität

Es sollte so verstanden werden: Einerseits muss die Möglichkeit bestehen, ein Backup jederzeit wiederherzustellen, andererseits ist die Widerstandsfähigkeit gegenüber verschiedenen Problemen wichtig: Netzwerkunterbrechung, Festplattenausfall, Löschung eines Teils des Repositories.

Vergleich der Backup-Tools

Erstellungszeit des Backups
Wiederherstellungszeit des Backups
Einfache Installation
Einfache Einrichtung
Einfache Nutzung
Einfache Automatisierung
Wird ein Client-Server benötigt?
Integritätsprüfung des Repositories
Differenzielle Backups
Arbeiten über Pipe
Universalisierung
Unabhängigkeit
Transparenz des Repositories
Verschlüsselung
Kompression
Deduplication
Web-Interface
Upload in die Cloud
Unterstützung für Windows
Punktzahl

Rsync
4m15s
4m28s
ja
nein
nein
nein
ja
nein
nein
ja
nein
ja
ja
nein
nein
nein
nein
nein
ja
6

Tar
pure
3m12s
2m43s
ja
nein
nein
nein
nein
nein
ja
ja
nein
ja
nein
nein
nein
nein
nein
nein
ja
8,5

gzip
9m37s
3m19s
ja

Rdiff-backup
16m26s
17m17s
ja
ja
ja
ja
ja
nein
ja
nein
ja
nein
ja
nein
ja
ja
ja
nein
ja
11

Rsnapshot
4m19s
4m28s
ja
ja
ja
ja
nein
nein
ja
nein
ja
nein
ja
nein
nein
ja
ja
nein
ja
12,5

Burp
11m9s
7m2s
ja
nein
ja
ja
ja
ja
ja
nein
ja
ja
nein
nein
ja
nein
ja
nein
ja
10,5

Duplicity
keine Verschlüsselung
16m48s
10m58s
ja
ja
nein
ja
nein
ja
ja
nein
nein
ja
nein
ja
ja
nein
ja
nein
ja
11

gpg
17m27s
15m3s

Duplicati
keine Verschlüsselung
20m28s
13m45s
nein
ja
nein
nein
nein
ja
ja
nein
nein
ja
nein
ja
ja
ja
ja
ja
ja
11

aes
29m41s
21m40s

gpg
26m19s
16m30s

Zbackup
keine Verschlüsselung
40m3s
11m8s
ja
ja
nein
nein
nein
ja
ja
ja
nein
ja
nein
ja
ja
ja
nein
nein
nein
10

aes
42m0s
14m1s

aes+lzo
18m9s
6m19s

BorgBackup
keine Verschlüsselung
4m7s
2m45s
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
nein
ja
ja
ja
ja
nein
ja
16

aes
4m58s
3m23s

blake2
4m39s
3m19s

Restic
5m38s
4m28s
ja
ja
ja
ja
nein
ja
ja
ja
ja
ja
nein
ja
nein
ja
nein
ja
ja
15,5

UrBackup
8m21s
8m19s
ja
ja
ja
nein
ja
nein
ja
nein
ja
ja
nein
ja
ja
ja
ja
nein
ja
12

Amanda
9m3s
2m49s
ja
nein
nein
ja
ja
ja
ja
nein
ja
ja
ja
ja
ja
nein
ja
ja
ja
13

BackupPC
rsync
12m22s
7m42s
ja
nein
ja
ja
ja
ja
ja
nein
ja
nein
nein
ja
ja
nein
ja
nein
ja
10,5

,
12m34s
12m15s

Legende der Tabelle:

Grün, Betriebsdauer weniger als fünf Minuten oder Antwort "Ja" (außer in der Spalte "Wird ein Client-Server benötigt?"), 1 Punkt
Gelb, Betriebsdauer fünf bis zehn Minuten, 0,5 Punkte
Rot, Betriebsdauer mehr als zehn Minuten oder Antwort "Nein" (außer in der Spalte "Wird ein Client-Server benötigt?"), 0 Punkte

Laut der obenstehenden Tabelle ist BorgBackup das einfachste, schnellste und zugleich benutzerfreundlichste sowie leistungsstärkste Werkzeug für Backups. An zweiter Stelle steht Restic, während die anderen in Betracht gezogenen Kandidaten ungefähr gleichwertig abschneiden, mit einer Punktedifferenz von ein bis zwei Zählern am Ende.

Ich danke allen, die die Reihe bis zum Ende gelesen haben, und lade ein, Optionen zu besprechen oder eigene Vorschläge zu machen, falls vorhanden. Im Laufe der Diskussion kann die Tabelle ergänzt werden.

Das Ergebnis dieser Reihe wird ein abschließender Artikel sein, in dem der Versuch unternommen wird, das ideale, schnelle und verwaltbare Mittel für Backups zu ermitteln, das es ermöglicht, ein Backup in kürzester Zeit wiederherzustellen und gleichzeitig Komfort und Einfachheit bei der Einrichtung und Wartung zu bieten.