In diesem Artikel wird ein Vergleich von Backup-Tools angestellt, aber zuerst sollten wir verstehen, wie schnell und gut sie Daten aus Backups wiederherstellen können.
Um den Vergleich zu vereinfachen, wird die Wiederherstellung aus einem vollständigen Backup betrachtet, da dieser Betriebsmodus von allen Kandidaten unterstützt wird. Zur Vereinfachung wurden die Zahlen bereits gemittelt (arithmetisches Mittel aus mehreren Durchläufen). Die Ergebnisse werden in einer Tabelle zusammengefasst, die auch Informationen zu den Funktionen enthält: Verfügbarkeit einer Weboberfläche, Einfachheit in der Einrichtung und Nutzung, Automatisierungsfähigkeit, sowie das Vorhandensein verschiedener zusätzlicher Funktionen (z.B. Datenintegritätsprüfung) usw. Grafiken werden die Serverauslastung zeigen, auf denen die Daten angewendet werden (nicht die Server für die Speicherung von Backups).
Datenwiederherstellung
Als Referenzpunkte werden rsync und tar verwendet, da die einfachsten Skripte zur Durchführung von Backups.
Rsync bewältigte den Testdatensatz in 4 Minuten und 28 Sekunden und zeigte
eine solche Auslastung.
Der Wiederherstellungsprozess stieß auf Einschränkungen des Speichersystems des Backup-Servers (sägezahnartige Grafiken). Außerdem ist deutlich zu erkennen, dass ein Kerneinsatz ohne besondere Probleme läuft (niedriger iowait und softirq – keine Probleme mit Disk und Netzwerk). Da die beiden anderen Programme, nämlich rdiff-backup und rsnapshot, auf rsync basieren und ebenfalls rsync als Wiederherstellungsmittel anbieten, werden sie ein ähnliches Lastprofil und Wiederherstellungszeit aufweisen.
Tar schaffte es etwas schneller, in
2 Minuten und 43 Sekunden:
Die Gesamtauslastung des Systems war im Durchschnitt um 20 % höher, bedingt durch einen Anstieg des softirq – die Overheadkosten beim Betrieb des Netzwerkes stiegen.
Falls das Archiv zusätzlich komprimiert wird, steigt die Wiederherstellungszeit auf 3 Minuten und 19 Sekunden mit
einer solchen Belastung auf dem Hauptserver (Entpacken auf der Seite des Hauptservers):
Der Entpackungsprozess beansprucht beide Prozessor-Kerne, da zwei Prozesse arbeiten. Insgesamt ein erwartetes Ergebnis. Ein vergleichbares Ergebnis (3 Minuten und 20 Sekunden) wurde auch erzielt, als gzip auf der Serverseite mit Backup-Kopien ausgeführt wurde; die Lastprofile auf dem Hauptserver waren sehr ähnlich wie beim Ausführen von tar ohne den gzip-Kompressor (siehe vorherige Grafik).
Im rdiff-backup Die letzte erstellte Backup-Kopie kann mit normalem rsync synchronisiert werden (die Ergebnisse werden ähnlich sein), aber ältere Backup-Kopien müssen immer noch mit dem Programm rdiff-backup wiederhergestellt werden, das die Wiederherstellung in 17 Minuten und 17 Sekunden geschafft hat und dabei
eine solche Last erzeugte:
Es könnte so beabsichtigt gewesen sein, jedenfalls schlagen die Autoren . Der gesamte Wiederherstellungsprozess des Backups benötigt etwas weniger als die Hälfte eines Kerns, mit proportional vergleichbarer Leistung (d.h. 2-5 Mal langsamer) über die Disk und das Netz mit rsync.
Rsnapshot empfiehlt für die Wiederherstellung die Verwendung von normalem rsync, weshalb seine Ergebnisse ähnlich sein werden. Insgesamt hat sich das auch so ergeben.
Burp hat die Aufgabe der Wiederherstellung des Backups in 7 Minuten und 2 Sekunden mit
einer solchen Last bewältigt:
Er hat ausreichend schnell gearbeitet und, jedenfalls, viel angenehmer als reines rsync: man muss sich keine Flags merken, ein einfaches und intuitives CLI-Interface, eingebaute Unterstützung mehrerer Kopien, - obwohl es etwa doppelt so langsam ist. Wenn Daten aus der zuletzt erstellten Backup-Kopie wiederhergestellt werden müssen, kann rsync unter bestimmten Vorbehalten verwendet werden.
Ein etwa gleich schnelles Ergebnis und Last zeigte das Programm BackupPC im rsync-Übertragungsmodus, das Backup wurde in
7 Minuten und 42 Sekunden wiederhergestellt:
Im tar-Datenübertragungsmodus kam BackupPC jedoch langsamer vor: in 12 Minuten und 15 Sekunden, die CPU-Last war dabei insgesamt niedriger
um das eineinhalbfache:
Doppelte ohne Verschlüsselung wurden etwas bessere Ergebnisse erzielt, da die Wiederherstellung des Backups in 10 Minuten und 58 Sekunden abgeschlossen wurde. Wenn die Verschlüsselung mit gpg aktiviert wird, steigt die Wiederherstellungszeit auf 15 Minuten und 3 Sekunden. Außerdem kann bei der Erstellung eines Repositories zur Speicherung von Backups die Größe des Archivs angegeben werden, das beim Aufteilen des Datenstroms verwendet wird. Insgesamt gibt es auf herkömmlichen Festplatten, auch aufgrund des einseitigen Betriebsmodus, keinen nennenswerten Unterschied. Dieser könnte jedoch bei unterschiedlichen Blockgrößen auftreten, wenn hybride Speicher verwendet werden. Die Belastung des Hauptservers während der Wiederherstellung war folgende:
ohne Verschlüsselung
mit Verschlüsselung
Duplicati zeigte eine vergleichbare Wiederherstellungsgeschwindigkeit, indem es in 13 Minuten und 45 Sekunden fertig wurde. Die Überprüfung der Richtigkeit der wiederhergestellten Daten dauerte außerdem etwa 5 Minuten (insgesamt also etwa 19 Minuten). Dabei war die Belastung
relativ hoch:
Als die aes-Verschlüsselung durch interne Mittel aktiviert wurde, betrug die Wiederherstellungszeit 21 Minuten und 40 Sekunden, wobei die CPU-Auslastung während der Wiederherstellung maximal war (beide Kerne!). Bei der Überprüfung der Daten war nur ein Thread aktiv, der einen CPU-Kern beanspruchte. Die Datenüberprüfung nach der Wiederherstellung dauerte ebenfalls 5 Minuten (insgesamt fast 27 Minuten).
Ergebnis
Etwas schneller bewältigte duplicati die Wiederherstellung, als eine externe Software gpg zur Verschlüsselung verwendet wurde, aber insgesamt sind die Unterschiede im Vergleich zum vorherigen Modus minimal. Die Arbeitszeit betrug 16 Minuten und 30 Sekunden, mit einer Datenüberprüfung von 6 Minuten. Die Belastung war
folgendermaßen:
AMANDA, das tar verwendet, benötigte 2 Minuten und 49 Sekunden, was im Prinzip sehr nah an dem gewöhnlichen tar liegt. Die Belastung für das System ist im Prinzip
gleich:
Bei der Wiederherstellung des Backups mit Hilfe von zbackup ergaben sich folgende Ergebnisse:
Verschlüsselung, lzma-Kompression
Arbeitszeit 11 Minuten und 8 Sekunden
aes-Verschlüsselung, lzma-Kompression
Arbeitszeit 14 Minuten
aes-Verschlüsselung, lzo-Kompression
Arbeitszeit 6 Minuten, 19 Sekunden
Insgesamt nicht schlecht. Alles hängt von der Geschwindigkeit des Prozessors auf dem Backup-Server ab, was sich ziemlich klar in der Laufzeit des Programms mit verschiedenen Kompressoren zeigt. Auf der Seite des Backup-Servers wurde normales tar gestartet, sodass die Wiederherstellung im Vergleich dazu dreimal langsamer arbeitet. Es könnte sinnvoll sein, die Leistung im Multithread-Modus mit mehr als zwei Threads zu überprüfen.
BorgBackup Im unverschlüsselten Modus war es etwas langsamer als tar und benötigte 2 Minuten und 45 Sekunden. Allerdings gab es im Gegensatz zu tar die Möglichkeit zur Deduplizierung des Repositories. Die Belastung betrug dabei
folgendes:
Wenn man die Verschlüsselung auf der Basis von blake aktiviert, verlangsamt sich die Wiederherstellung geringfügig. Die Wiederherstellungszeit in diesem Modus beträgt 3 Minuten und 19 Sekunden, und die Belastung lag bei
folgendem:
Die aes-Verschlüsselung arbeitet etwas langsamer, die Wiederherstellungszeit beträgt 3 Minuten und 23 Sekunden, die Belastung hat sich dabei nicht wesentlich
verändert:
Da Borg im Multithread-Modus arbeiten kann, wird die Prozessorlast maximiert. Bei Aktivierung zusätzlicher Funktionen steigt einfach die Arbeitszeit. Offensichtlich sollte die Multithread-Leistung ähnlich wie bei zbackup untersucht werden.
Restic schaffte die Wiederherstellung etwas langsamer, die Arbeitszeit betrug 4 Minuten und 28 Sekunden. Die Belastung sah dabei
so:
anscheinend so aus, dass der Wiederherstellungsprozess in mehreren Threads arbeitet, aber die Effizienz nicht so hoch ist wie bei BorgBackup, jedoch vergleichbar in der Zeit mit dem normalen rsync.
Mit Hilfe von UrBackup konnte die Daten in 8 Minuten und 19 Sekunden wiederherstellen, die Belastung war dabei
folgendermaßen:
Immer noch sichtbar eine nicht sehr hohe Belastung, sogar niedriger als bei tar. Stellenweise gab es Spitzen, aber nicht mehr als die Belastung eines Kerns.
Auswahl und Begründung der Vergleichskriterien
Wie in einem der vorhergehenden Artikel gesagt, sollte das Backup-System folgenden Kriterien entsprechen:
- Einfachheit in der Arbeit
- Vielseitigkeit
- Stabilität
- Schnelligkeit
Es lohnt sich, jeden Punkt einzeln näher zu betrachten.
Benutzerfreundlichkeit
Am besten ist es, wenn es einen einzigen Knopf "Alles gut machen" gibt, aber wenn man zu den realen Programmen zurückkehrt, ist ein gewisser gewohnter und standardisierter Arbeitsansatz am angenehmsten.
Die meisten Benutzer werden es wahrscheinlich besser finden, wenn sie sich nicht eine Menge Schlüssel für die CLI merken müssen, eine Vielzahl von oft schwer verständlichen Optionen über Web oder TUI einrichten und Benachrichtigungen über fehlerhafte Vorgänge konfigurieren müssen. Dazu gehört auch die Möglichkeit, eine Backup-Lösung problemlos in die bestehende Infrastruktur zu integrieren sowie den Automatisierungsprozess für Backups. Zudem sollte die Installation über einen Paketmanager oder in ein bis zwei Befehlen wie „herunterladen und entpacken“ möglich sein. curl link | sudo bash — eine komplexe Methode, da überprüft werden muss, was über den Link kommt.
Ein einfaches Beispiel unter den betrachteten Kandidaten sind Burp, rdiff-backup und Restic, die einprägsame Schlüssel für verschiedene Betriebsmodi haben. Etwas komplizierter sind Borg und Duplicity. Die komplexeste Lösung war AMANDA. Die anderen liegen in der Benutzerfreundlichkeit irgendwo dazwischen. In jedem Fall, wenn man mehr als 30 Sekunden für die Anleitung benötigt oder Google oder eine andere Suchmaschine konsultieren muss sowie ein langes Hilfe-Dokument durchlesen muss — ist die Lösung komplex, wie auch immer.
Einige der betrachteten Kandidaten können automatisch Nachrichten per E-Mail/Jabber senden, während andere auf konfigurierte Benachrichtigungen im System angewiesen sind. Dabei haben komplexe Lösungen oft nicht ganz offensichtliche Einstellungen für Benachrichtigungen. In jedem Fall, wenn das Backup-Programm einen anderen Rückgabewert als Null ausgibt, der vom systemskript für wiederkehrende Aufgaben korrekt interpretiert wird (eine Nachricht wird an den Systemadministrator gesendet oder direkt in das Monitoring) — ist die Situation einfach. Wenn das Backup-System, das nicht auf dem Backup-Server läuft, ohne Konfiguration nicht auf offensichtliche Weise ein Problem melden kann — ist die Komplexität bereits übertrieben. In jedem Fall ist es eine schlechte Praxis, Warnungen und andere Nachrichten nur in der Weboberfläche oder im Protokoll auszugeben, da sie oft ignoriert werden.
Was die Automatisierung angeht — ein einfaches Programm kann Umgebungsvariablen lesen, die seinen Betriebsmodus festlegen, oder hat eine ausgeklügelte CLI, die das Verhalten bei der Verwendung der Weboberfläche komplett nachahmt. Dazu gehört auch die Möglichkeit der Streaming-Verarbeitung, die Verfügbarkeit von Erweiterungsmöglichkeiten usw.
Vielseitigkeit
Teilweise überschneidet sich mit dem vorherigen Abschnitt in Bezug auf Automatisierung, es sollte keine besondere Herausforderung sein, den Backup-Prozess in die bestehende Infrastruktur zu integrieren.
Es ist erwähnenswert, dass die Verwendung von nicht standardmäßigen Ports (außer dem Web-Interface) für den Betrieb, 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 weisen diese Merkmale mehr oder weniger aus einem offensichtlichen Grund auf: Einfachheit und Universalität sind normalerweise nicht kompatibel. Eine Ausnahme ist Burp, es gibt auch andere.
Als Indikator — die Möglichkeit, mit regulärem SSH zu arbeiten.
Geschwindigkeit der Arbeit
Der umstrittenste Punkt. Einerseits — der Prozess wurde gestartet, er lief so schnell wie möglich und störte die Hauptaufgaben nicht. Andererseits — ein Anstieg des Verkehrs und der CPU-Auslastung während der Sicherung. Es ist auch zu beachten, dass die schnellsten Kopierprogramme oft die ärmsten Funktionen haben, die für die Benutzer wichtig sind. Wiederum: Wenn man einen einzigen kleinen Textdatei von nur einigen Dutzend Bytes mit einem Passwort abrufen muss, und das ganze System aufgrund dessen steht (ja, ich verstehe, dass der Backup-Prozess in diesen Fällen oft nicht schuld ist), und man alle Dateien im Repository sequentiell lesen oder ein ganzes Archiv entpacken muss — dann ist das Backup-System alles andere als schnell. Ein weiterer Punkt, der oft zum Streit führt — die Geschwindigkeit der Wiederherstellung aus dem Archiv. Hier haben die Programme, die Dateien einfach an den gewünschten Ort kopieren oder verschieben können, ohne große Manipulationen (zum Beispiel rsync), einen klaren Vorteil, aber meistens muss das Problem organisatorisch durch empirische Messungen gelöst werden: Die Zeit für die Wiederherstellung des Backups messen und offen darüber informieren.
Stabilität
Es sollte so verstanden werden: einerseits muss es möglich sein, das Backup auf jeden Fall wiederherzustellen, andererseits muss es widerstandsfähig gegenüber verschiedenen Problemen sein: Netzwerkunterbrechungen, Festplattenausfälle, das Löschen von Teilen des Repositories.
Vergleich der Backup-Tools
Zeit zum Erstellen einer Kopie
Wiederherstellungszeit der Kopie
Einfache Installation
Einfache Einrichtung
Einfache Bedienung
Einfache Automatisierung
Wird ein Client-Server benötigt?
Überprüfung der Integrität des Repositories
Differenzkopien
Arbeiten über Pipe
Vielseitigkeit
Selbstständigkeit
Transparenz des Repositories
Verschlüsselung
Kompression
Deduplication
Weboberfläche
Upload in die Cloud
Windows-Unterstützung
Punkt
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
Rdiff-backup
ja
17m17s
16m26s
11m9s
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
7m2s
Keine Verschlüsselung
ja
nein
ja
ja
ja
ja
ja
nein
ja
ja
nein
nein
ja
nein
ja
nein
ja
10,5
Doppelte
16m48s
10m58s
17m27s
ja
ja
nein
ja
nein
ja
ja
nein
nein
ja
nein
ja
ja
nein
ja
nein
ja
11
gpg
15m3s
13m45s
Duplicati
16m48s
20m28s
aes
nein
ja
nein
nein
nein
ja
ja
nein
nein
ja
nein
ja
ja
ja
ja
ja
ja
11
29m41s
21m40s
26m19s
gpg
Zbackup
16m30s
11m8s
16m48s
40m3s
42m0s
ja
ja
nein
nein
nein
ja
ja
ja
nein
ja
nein
ja
ja
ja
nein
nein
nein
10
29m41s
14m1s
aes+lzo
18m9s
6m19s
4m7s
BorgBackup
16m48s
3m23s
2m45s
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
nein
ja
ja
ja
ja
nein
ja
16
29m41s
4m58s
blake2
4m39s
8m21s
Rdiff-backup
Restic
5m38s
4m28s
ja
ja
ja
ja
nein
ja
ja
ja
ja
ja
nein
ja
nein
ja
nein
ja
ja
15,5
UrBackup
Amanda
8m19s
ja
ja
ja
nein
ja
nein
ja
nein
ja
ja
nein
ja
ja
ja
ja
nein
ja
12
2m49s
9m3s
12m22s
ja
nein
nein
ja
ja
ja
ja
nein
ja
ja
ja
ja
ja
nein
ja
ja
ja
13
BackupPC
rsync
7m42s
12m34s
ja
nein
ja
ja
ja
ja
ja
nein
ja
nein
nein
ja
ja
nein
ja
nein
ja
10,5
tar
12m15s
Legende der Tabelle:
Grün, Arbeitszeit weniger als fünf Minuten oder Antwort "Ja" (außer in der Spalte "Benötigen Sie einen Client-Server?"), 1 Punkt
- Gelb, Arbeitszeit fünf bis zehn Minuten, 0,5 Punkte
- Rot, Arbeitszeit länger als zehn Minuten oder Antwort "Nein" (außer in der Spalte "Benötigen Sie einen Client-Server?"), 0 Punkte
- Laut der obenstehenden Tabelle ist BorgBackup das einfachste, schnellste und gleichzeitig bequemste und leistungsstarke Tool für Backups. Den zweiten Platz belegte Restic, die übrigen in Betracht gezogenen Kandidaten lagen etwa gleich mit einer Punktedifferenz von ein bis zwei Punkten am Ende.
Ich danke allen, die den Zyklus bis zum Ende gelesen haben; ich lade ein, Optionen zu diskutieren und eigene Vorschläge zu machen, falls vorhanden. Während der Diskussion kann die Tabelle erweitert werden.
Das Ergebnis des Zyklus wird ein abschließender Artikel sein, in dem versucht wird, ein ideales, schnelles und verwaltbares Backup-Tool zu entwickeln, das es ermöglicht, eine Kopie in kürzester Zeit zurückzustellen und gleichzeitig Bequemlichkeit und Einfachheit bei der Einrichtung und Wartung zu bieten.
In diesem Artikel.
Ankündigung
Backup, Teil 6: Vergleich von Backup-Tools
Backup, Teil 7: Zusammenfassungen
Quelle: habr.com
