Backup, Teil 6: Vergleichen der Backup-Tools

In diesem Artikel werden Sicherungstools verglichen. Zunächst müssen Sie jedoch herausfinden, wie schnell und gut Daten aus Sicherungen wiederhergestellt werden können.
Zum leichteren Vergleich wird die Wiederherstellung nach einer vollständigen Sicherung in Betracht gezogen, insbesondere da alle Kandidaten diese Betriebsart unterstützen. Der Einfachheit halber werden die Zahlen bereits gemittelt (arithmetischer Durchschnitt mehrerer Starts). Die Ergebnisse werden in einer Tabelle zusammengefasst, die auch Informationen zu den Funktionen enthält: Vorhandensein einer Weboberfläche, einfache Einrichtung und Bedienung, Automatisierungsfähigkeit, Vorhandensein verschiedener zusätzlicher Funktionen (z. B. Überprüfung der Datenintegrität) usw. Die Grafiken zeigen die Serverlast, auf der die Daten verwendet werden (nicht den Server zum Speichern von Sicherungen).

Datenwiederherstellung

Rsync und tar werden als Referenzpunkt verwendet, da auf diesen normalerweise die einfachsten Sicherungsskripte basieren .

Rsync vervollständigte den Testdatensatz in 4 Minuten und 28 Sekunden durch Anzeigen


Der Wiederherstellungsprozess stieß auf eine Einschränkung des Festplattensubsystems des Sicherungsspeicherservers (Sägezahngrafiken). Sie können auch das Laden eines Kerns ohne Probleme deutlich sehen (niedrige iowait und softirq - es gibt keine Probleme mit der Festplatte bzw. dem Netzwerk). Da die beiden anderen Programme, nämlich rdiff-backup und rsnapshot, auf rsync basieren und auch reguläres rsync als Wiederherstellungstool anbieten, haben sie ungefähr das gleiche Ladeprofil und die gleiche Sicherungswiederherstellungszeit.

Tar handelte etwas schneller für


Die volle Systemlast war aufgrund des erhöhten Softirq - erhöhten Overheads während des Betriebs des Netzwerksubsystems - um durchschnittlich 20% höher.

Wird das Archiv zusätzlich komprimiert, erhöht sich die Wiederherstellungszeit mit auf 3 Minuten 19 Sekunden

Der Entpackungsprozess belegt beide Prozessorkerne, da zwei Prozesse funktionieren. Im Allgemeinen das erwartete Ergebnis. Ein vergleichbares Ergebnis (3 Minuten und 20 Sekunden) wurde erzielt, wenn gzip auf der Serverseite mit Backups ausgeführt wurde. Das Lastprofil auf dem Hauptserver war dem Ausführen von tar ohne den gzip-Kompressor sehr ähnlich (siehe vorherige Grafik).

In rdiff-backup können Sie die letzte Sicherung synchronisieren, die mit regulärem rsync erstellt wurde (die Ergebnisse sind ähnlich). Ältere Sicherungen müssen jedoch noch mit dem Programm rdiff-backup wiederhergestellt werden, das in 17 Minuten und 17 Sekunden wiederhergestellt werden konnte


Vielleicht wurde dies auf jeden Fall gedacht, die Autoren schlagen eine solche Lösung vor , um die Geschwindigkeit zu begrenzen. Das Wiederherstellen eines Backups dauert etwas weniger als die Hälfte eines Kerns mit einer proportional vergleichbaren Leistung (d. H. 2-5 mal langsamer) auf einer Festplatte und einem Netzwerk mit rsync.

Rsnapshot für die Wiederherstellung schlägt die Verwendung von regulärem rsync vor, sodass die Ergebnisse ähnlich sind. Im Allgemeinen ist das so passiert.

Burp bewältigte die Aufgabe, ein Backup in 7 Minuten und 2 Sekunden mit wiederherzustellen

Es funktionierte schnell genug und zumindest viel bequemer als reines Rsync: Sie müssen sich keine Flags merken, eine einfache und intuitive Cli-Oberfläche, integrierte Unterstützung für mehrere Kopien - es ist doppelt so langsam. Wenn Sie Daten aus der letzten Sicherung wiederherstellen müssen, können Sie rsync mit einigen Einschränkungen verwenden.

BackupPC zeigte ungefähr die gleiche Geschwindigkeit und Last, wenn der rsync-Übertragungsmodus durch Bereitstellen eines Backups für aktiviert wurde


Im Datenübertragungsmodus mit tar wurde BackupPC jedoch langsamer bewältigt: In 12 Minuten und 15 Sekunden war die Prozessorlast im Allgemeinen geringer


Duplizität ohne Verschlüsselung zeigte etwas bessere Ergebnisse, nachdem die Wiederherstellung eines Backups in 10 Minuten und 58 Sekunden bewältigt wurde. Wenn Sie die Verschlüsselung mit gpg aktivieren, erhöht sich die Wiederherstellungszeit auf 15 Minuten und 3 Sekunden. Wenn Sie ein Repository zum Speichern von Kopien erstellen, können Sie auch die Größe des Archivs angeben, das beim Aufteilen des eingehenden Datenstroms verwendet wird. Im Allgemeinen gibt es auf normalen Festplatten, auch aufgrund des Single-Threaded-Betriebsmodus, keinen großen Unterschied. Bei Verwendung von Hybridspeicher kann es mit unterschiedlichen Blockgrößen auftreten. Die Belastung des Hauptservers während der Wiederherstellung war wie folgt:



Duplicati zeigte eine vergleichbare Erholungsgeschwindigkeit, die in 13 Minuten und 45 Sekunden bewältigt wurde. Weitere 5 Minuten erforderten die Überprüfung der Richtigkeit der wiederhergestellten Daten (insgesamt ca. 19 Minuten). Die Ladung war


Wenn die aes-Verschlüsselung intern aktiviert wurde, betrug die Wiederherstellungszeit 21 Minuten und 40 Sekunden, und die Prozessorlast war maximal (beide Kerne!) Während der Wiederherstellung. Beim Überprüfen der Daten war nur ein Thread aktiv, der einen Prozessorkern belegte. Die Datenüberprüfung nach der Wiederherstellung dauerte dieselben 5 Minuten (insgesamt fast 27 Minuten).


Duplicati handhabte die Wiederherstellung etwas schneller, wenn ein externes GPG-Programm zur Verschlüsselung verwendet wurde, aber im Allgemeinen sind die Unterschiede zum vorherigen Modus minimal. Die Betriebszeit betrug 16 Minuten 30 Sekunden, mit einer Datenüberprüfung in 6 Minuten. Die Ladung war


AMANDA mit Teer schaffte es in 2 Minuten und 49 Sekunden, was im Prinzip dem normalen Teer sehr nahe kommt. Systemlast im Prinzip


Beim Wiederherstellen eines Backups mit zbackup wurden die folgenden Ergebnisse erzielt:




Alles in allem nicht schlecht. Alles hängt von der Prozessorgeschwindigkeit auf dem Sicherungsserver ab, die deutlich sichtbar ist, wenn das Programm mit verschiedenen Kompressoren ausgeführt wird. Auf der Seite des Sicherungsservers wurde ein regulärer Tar gestartet. Wenn Sie also damit vergleichen, funktioniert die Wiederherstellung dreimal langsamer. Es kann sich lohnen, die Arbeit im Multithread-Modus mit mehr als zwei Threads zu überprüfen.

BorgBackup im unverschlüsselten Modus wurde etwas langsamer als tar verwaltet. In 2 Minuten und 45 Sekunden wurde es jedoch möglich, das Repository zu deduplizieren , im Gegensatz zu demselben tar. Die Ladung stellte sich gleichzeitig heraus


Wenn Sie die Blake-basierte Verschlüsselung aktivieren, verlangsamt sich die Geschwindigkeit der Wiederherstellung eines Backups etwas. Die Wiederherstellungszeit in diesem Modus beträgt 3 Minuten und 19 Sekunden, und die Last wird freigegeben


Die AES-Verschlüsselung arbeitet etwas langsamer, die Wiederherstellungszeit 3 ​​Minuten 23 Sekunden, insbesondere beim Laden


Da Borg im Multithread-Modus arbeiten kann, ist die Prozessorlast maximal, während sich die Betriebszeit einfach erhöht, wenn Sie zusätzliche Funktionen aktivieren. Anscheinend lohnt es sich, die Multithreading-Arbeit ähnlich wie bei Zbackup zu untersuchen.

Restic kam mit der Erholung etwas langsamer zurecht , die Betriebszeit betrug 4 Minuten 28 Sekunden. Die Ladung sah aus


Anscheinend funktioniert der Wiederherstellungsprozess in mehreren Threads, aber die Effizienz ist nicht so hoch wie die von BorgBackup, aber zeitlich vergleichbar mit regulärem rsync.

Mit UrBackup konnte ich Daten in 8 Minuten und 19 Sekunden wiederherstellen, während die Last war


Es ist immer noch keine sehr hohe Belastung sichtbar, sogar eine geringere als die von Teer. Stellenweise platzt es, aber nicht mehr als einen einzelnen Kern zu laden.

Auswahl und Begründung von Vergleichskriterien

Wie in einem vorherigen Artikel erwähnt, muss das Sicherungssystem die folgenden Kriterien erfüllen:

• Einfachheit in der Arbeit
• Vielseitigkeit
• Stabilität
• Geschwindigkeit

Es lohnt sich, jeden Artikel einzeln genauer zu betrachten.

Einfachheit der Arbeit

Es ist am besten, wenn es eine Schaltfläche "Alles gut machen" gibt. Wenn Sie jedoch zu echten Programmen zurückkehren, ist es am bequemsten, ein vertrautes und standardmäßiges Funktionsprinzip zu haben.
Die meisten Benutzer sind höchstwahrscheinlich besser dran, wenn sie sich nicht eine Reihe von Schlüsseln für cli merken, eine Reihe verschiedener, oft undurchsichtiger Optionen über das Web oder tui konfigurieren und Warnungen über fehlgeschlagene Vorgänge einrichten müssen. Dies umfasst auch die Möglichkeit, eine Sicherungslösung einfach in eine vorhandene Infrastruktur zu integrieren und den Sicherungsprozess zu automatisieren. Sofort die Möglichkeit, einen Paketmanager oder in einem oder zwei Befehlen vom Typ "Herunterladen und Entpacken" zu installieren. curl | sudo bash curl | sudo bash ist eine komplizierte Methode, da Sie überprüfen müssen, ob sie als Referenz eintrifft.

Eine der in Betracht gezogenen Kandidaten ist beispielsweise Burp, Rdiff-Backup und Restic, bei denen Schlüssel für verschiedene Betriebsarten mnemonisch gespeichert wurden. Etwas komplizierter sind Borg und Duplizität. Am schwierigsten war AMANDA. Der Rest der Benutzerfreundlichkeit liegt irgendwo dazwischen. In jedem Fall ist die Lösung auf die eine oder andere Weise kompliziert, wenn Sie mehr als 30 Sekunden benötigen, um das Benutzerhandbuch zu lesen, oder wenn Sie zu Google oder einer anderen Suchmaschine gehen und auch durch das lange Hilfeblatt scrollen müssen.

Einige der in Betracht gezogenen Kandidaten können automatisch eine Nachricht per E-Mail \ jabber senden, während andere auf konfigurierte Warnungen im System angewiesen sind. Darüber hinaus haben komplexe Entscheidungen meist keine ganz offensichtlichen Benachrichtigungseinstellungen. In jedem Fall ist die Situation einfach, wenn das Sicherungsprogramm einen Rückkehrcode ungleich Null ausgibt, der vom Systemdienst für regelmäßige Aufgaben korrekt verstanden wird (die Nachricht wird an den Systemadministrator oder sofort an die Überwachung weitergeleitet). Wenn das Sicherungssystem, das auf dem Sicherungsserver nicht funktioniert, nicht auf offensichtliche Weise eingerichtet werden kann, ist die Komplexität bereits zu hoch. In jedem Fall ist es eine schlechte Praxis, Warnungen und andere Nachrichten nur an die Weboberfläche und / oder an das Protokoll zu senden, da diese meistens ignoriert werden.

In Bezug auf die Automatisierung kann ein einfaches Programm Umgebungsvariablen lesen, die seinen Betriebsmodus angeben, oder es verfügt über eine entwickelte CLI, die beispielsweise das Verhalten beim Arbeiten über eine Weboberfläche vollständig duplizieren kann. Dies schließt auch die Möglichkeit der kontinuierlichen Arbeit, die Verfügbarkeit von Expansionsmöglichkeiten usw. ein.

Vielseitigkeit

In Bezug auf die Automatisierung wird der vorherige Unterabschnitt teilweise wiederholt. Es sollte kein besonderes Problem sein, den Sicherungsprozess in die vorhandene Infrastruktur zu „integrieren“.
Es ist anzumerken, dass die Verwendung von nicht standardmäßigen Ports (mit Ausnahme der Weboberfläche) für die Arbeit, die nicht standardmäßige Implementierung der Verschlüsselung und der Datenaustausch mit einem nicht standardmäßigen Protokoll Zeichen einer nicht universellen Lösung sind. Zum größten Teil haben alle Kandidaten aus dem offensichtlichen Grund die eine oder andere Möglichkeit: Einfachheit und Vielseitigkeit sind normalerweise nicht kompatibel. Rülpsen ist eine Ausnahme, es gibt andere.

Als Zeichen - die Fähigkeit, mit normalem SSH zu arbeiten.

Arbeitsgeschwindigkeit

Der umstrittenste und umstrittenste Punkt. Einerseits haben sie den Prozess gestartet, er hat so schnell wie möglich funktioniert und die Hauptaufgaben nicht beeinträchtigt. Auf der anderen Seite steigt der Datenverkehr und die CPU-Auslastung während der Sicherung. Es ist auch erwähnenswert, dass die schnellsten Kopierprogramme normalerweise die schlechtesten Funktionen aufweisen, die für Benutzer wichtig sind. Nochmals: Wenn Sie eine unglückliche Textdatei in der Größe von mehreren zehn Bytes mit einem Kennwort und damit die gesamten Servicekosten erhalten möchten (ja, ich verstehe, dass hier der Sicherungsprozess meistens nicht schuldig ist), müssen Sie erneut lesen sequentiell alle Dateien im Repository oder das gesamte Archiv bereitstellen - das Backup-System ist nie schnell. Ein weiterer Punkt, der häufig zum Stolperstein wird, ist die Geschwindigkeit, mit der ein Backup aus dem Archiv bereitgestellt wird. Es gibt einen klaren Vorteil für diejenigen, die Dateien ohne spezielle Manipulationen (z. B. rsync) einfach kopieren oder an den richtigen Ort verschieben können. Meistens muss das Problem jedoch empirisch auf organisatorische Weise gelöst werden: Messen Sie die Wiederherstellungszeit der Sicherung und informieren Sie die Benutzer offen darüber.

Stabilität

Es sollte wie folgt verstanden werden: Einerseits sollte es möglich sein, das Backup auf irgendeine Weise wieder bereitzustellen, andererseits Widerstand gegen verschiedene Probleme: Netzwerkausfall, Festplattenfehler, Löschen eines Teils des Repositorys.

Vergleich der Backup-Tools

Tischlegende:

• Grün, die Betriebszeit beträgt weniger als fünf Minuten oder die Antwort lautet "Ja" (mit Ausnahme der Spalte "Benötigen Sie einen Client \ Server?"), 1 Punkt
• Gelb, Betriebszeit fünf bis zehn Minuten, 0,5 Punkte
• Rot, die Betriebszeit beträgt mehr als zehn Minuten oder die Antwort lautet "Nein" (mit Ausnahme der Spalte "Benötigen Sie einen Client \ Server?"), 0 Punkte

Gemäß der obigen Tabelle ist BorgBackup das einfachste, schnellste und gleichzeitig bequemste und leistungsstärkste Backup-Tool. Restic belegte den zweiten Platz, der Rest der betrachteten Kandidaten wurde mit einer Streuung von ein oder zwei Punkten am Ende ungefähr gleich platziert.

Ich danke allen, die den Zyklus bis zum Ende gelesen haben. Ich schlage vor, Optionen zu besprechen und gegebenenfalls Ihre eigenen vorzuschlagen. Im Verlauf der Diskussion kann die Tabelle ergänzt werden.

Das Ergebnis des Zyklus wird der letzte Artikel sein, in dem versucht wird, ein ideales, schnelles und verwaltbares Backup-Tool herauszubringen, mit dem Sie eine Kopie schnell wieder bereitstellen und gleichzeitig die Bequemlichkeit und Einfachheit der Konfiguration und Wartung gewährleisten können.

Ankündigung

Backup, Teil 1: Warum benötigen Sie ein Backup, einen Überblick über Methoden und Technologien?
Backup, Teil 2: Übersicht und Testen von rsync-basierten Backup-Tools
Backup, Teil 3: Übersicht und Testen der Duplizität, Duplikate
Backup, Teil 4: Übersicht und Testen von zbackup, restic, borgbackup
Backup, Teil 5: Testen von Bacula- und Veeam-Backups für Linux
Backup: Teil von Lesern angefordert: AMANDA Review, UrBackup, BackupPC
Backup, Teil 6: Vergleichen der Backup-Tools
Backup Teil 7: Schlussfolgerungen