{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Backup, Teil 6: Vergleich von Backup-Tools","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,
\nIn diesem Artikel wird ein Vergleich von Backup-Tools angestellt, aber zuerst sollten wir verstehen, wie schnell und gut sie Daten aus Backups wiederherstellen k\u00f6nnen.
\nUm den Vergleich zu vereinfachen, wird die Wiederherstellung aus einem vollst\u00e4ndigen Backup betrachtet, da dieser Betriebsmodus von allen Kandidaten unterst\u00fctzt wird. Zur Vereinfachung wurden die Zahlen bereits gemittelt (arithmetisches Mittel aus mehreren Durchl\u00e4ufen). Die Ergebnisse werden in einer Tabelle zusammengefasst, die auch Informationen zu den Funktionen enth\u00e4lt: Verf\u00fcgbarkeit einer Weboberfl\u00e4che, Einfachheit in der Einrichtung und Nutzung, Automatisierungsf\u00e4higkeit, sowie das Vorhandensein verschiedener zus\u00e4tzlicher Funktionen (z.B. Datenintegrit\u00e4tspr\u00fcfung) usw. Grafiken werden die Serverauslastung zeigen, auf denen die Daten angewendet werden (nicht die Server f\u00fcr die Speicherung von Backups).
\n<\/a><\/noindex><\/p>\n

Datenwiederherstellung<\/h2>\n

\nAls Referenzpunkte werden rsync und tar verwendet, da sie normalerweise die Basis bilden f\u00fcr<\/a><\/noindex> die einfachsten Skripte zur Durchf\u00fchrung von Backups.<\/p>\n

Rsync<\/i> bew\u00e4ltigte den Testdatensatz in 4 Minuten und 28 Sekunden und zeigte <\/p>\n

eine solche Auslastung.<\/b>\"Backup,
\n
\nDer Wiederherstellungsprozess stie\u00df auf Einschr\u00e4nkungen des Speichersystems des Backup-Servers (s\u00e4gezahnartige Grafiken). Au\u00dferdem ist deutlich zu erkennen, dass ein Kerneinsatz ohne besondere Probleme l\u00e4uft (niedriger iowait und softirq \u2013 keine Probleme mit Disk und Netzwerk). Da die beiden anderen Programme, n\u00e4mlich rdiff-backup und rsnapshot, auf rsync basieren und ebenfalls rsync als Wiederherstellungsmittel anbieten, werden sie ein \u00e4hnliches Lastprofil und Wiederherstellungszeit aufweisen.<\/p>\n

Tar<\/i> schaffte es etwas schneller, in <\/p>\n

2 Minuten und 43 Sekunden:<\/b>\"Backup,
\n
\nDie Gesamtauslastung des Systems war im Durchschnitt um 20 % h\u00f6her, bedingt durch einen Anstieg des softirq \u2013 die Overheadkosten beim Betrieb des Netzwerkes stiegen.<\/p>\n

Falls das Archiv zus\u00e4tzlich komprimiert wird, steigt die Wiederherstellungszeit auf 3 Minuten und 19 Sekunden mit
\neiner solchen Belastung auf dem Hauptserver (Entpacken auf der Seite des Hauptservers):<\/b>\"Backup,
\n
\nDer 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\u00fchrt wurde; die Lastprofile auf dem Hauptserver waren sehr \u00e4hnlich wie beim Ausf\u00fchren von tar ohne den gzip-Kompressor (siehe vorherige Grafik).<\/p>\n

Im rdiff-backup<\/i> Die letzte erstellte Backup-Kopie kann mit normalem rsync synchronisiert werden (die Ergebnisse werden \u00e4hnlich sein), aber \u00e4ltere Backup-Kopien m\u00fcssen immer noch mit dem Programm rdiff-backup wiederhergestellt werden, das die Wiederherstellung in 17 Minuten und 17 Sekunden geschafft hat und dabei <\/p>\n

eine solche Last erzeugte:<\/b>\"Backup,
\n
\nEs k\u00f6nnte so beabsichtigt gewesen sein, jedenfalls schlagen die Autoren diese L\u00f6sung vor<\/a><\/noindex>. Der gesamte Wiederherstellungsprozess des Backups ben\u00f6tigt etwas weniger als die H\u00e4lfte eines Kerns, mit proportional vergleichbarer Leistung (d.h. 2-5 Mal langsamer) \u00fcber die Disk und das Netz mit rsync.<\/p>\n

Rsnapshot<\/i> empfiehlt f\u00fcr die Wiederherstellung die Verwendung von normalem rsync, weshalb seine Ergebnisse \u00e4hnlich sein werden. Insgesamt hat sich das auch so ergeben.<\/p>\n

Burp<\/i> hat die Aufgabe der Wiederherstellung des Backups in 7 Minuten und 2 Sekunden mit
\neiner solchen Last bew\u00e4ltigt:<\/b>\"Backup,
\n
\nEr 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\u00fctzung mehrerer Kopien, - obwohl es etwa doppelt so langsam ist. Wenn Daten aus der zuletzt erstellten Backup-Kopie wiederhergestellt werden m\u00fcssen, kann rsync unter bestimmten Vorbehalten verwendet werden.<\/p>\n

Ein etwa gleich schnelles Ergebnis und Last zeigte das Programm BackupPC<\/i> im rsync-\u00dcbertragungsmodus, das Backup wurde in <\/p>\n

7 Minuten und 42 Sekunden wiederhergestellt:<\/b>\"Backup,
\n
\nIm tar-Daten\u00fcbertragungsmodus kam BackupPC jedoch langsamer vor: in 12 Minuten und 15 Sekunden, die CPU-Last war dabei insgesamt niedriger <\/p>\n

um das eineinhalbfache:<\/b>\"Backup,
\n
\nDoppelte<\/i> ohne Verschl\u00fcsselung wurden etwas bessere Ergebnisse erzielt, da die Wiederherstellung des Backups in 10 Minuten und 58 Sekunden abgeschlossen wurde. Wenn die Verschl\u00fcsselung mit gpg aktiviert wird, steigt die Wiederherstellungszeit auf 15 Minuten und 3 Sekunden. Au\u00dferdem kann bei der Erstellung eines Repositories zur Speicherung von Backups die Gr\u00f6\u00dfe des Archivs angegeben werden, das beim Aufteilen des Datenstroms verwendet wird. Insgesamt gibt es auf herk\u00f6mmlichen Festplatten, auch aufgrund des einseitigen Betriebsmodus, keinen nennenswerten Unterschied. Dieser k\u00f6nnte jedoch bei unterschiedlichen Blockgr\u00f6\u00dfen auftreten, wenn hybride Speicher verwendet werden. Die Belastung des Hauptservers w\u00e4hrend der Wiederherstellung war folgende:<\/p>\n

ohne Verschl\u00fcsselung<\/b>\"Backup,
\n
\nmit Verschl\u00fcsselung<\/b>\"Backup,
\n
\nDuplicati<\/i> zeigte eine vergleichbare Wiederherstellungsgeschwindigkeit, indem es in 13 Minuten und 45 Sekunden fertig wurde. Die \u00dcberpr\u00fcfung der Richtigkeit der wiederhergestellten Daten dauerte au\u00dferdem etwa 5 Minuten (insgesamt also etwa 19 Minuten). Dabei war die Belastung <\/p>\n

relativ hoch:<\/b>\"Backup,
\n
\nAls die aes-Verschl\u00fcsselung durch interne Mittel aktiviert wurde, betrug die Wiederherstellungszeit 21 Minuten und 40 Sekunden, wobei die CPU-Auslastung w\u00e4hrend der Wiederherstellung maximal war (beide Kerne!). Bei der \u00dcberpr\u00fcfung der Daten war nur ein Thread aktiv, der einen CPU-Kern beanspruchte. Die Daten\u00fcberpr\u00fcfung nach der Wiederherstellung dauerte ebenfalls 5 Minuten (insgesamt fast 27 Minuten).<\/p>\n

Ergebnis<\/b>\"Backup,
\n
\nEtwas schneller bew\u00e4ltigte duplicati die Wiederherstellung, als eine externe Software gpg zur Verschl\u00fcsselung verwendet wurde, aber insgesamt sind die Unterschiede im Vergleich zum vorherigen Modus minimal. Die Arbeitszeit betrug 16 Minuten und 30 Sekunden, mit einer Daten\u00fcberpr\u00fcfung von 6 Minuten. Die Belastung war <\/p>\n

folgenderma\u00dfen:<\/b>\"Backup,
\n
\nAMANDA<\/i>, das tar verwendet, ben\u00f6tigte 2 Minuten und 49 Sekunden, was im Prinzip sehr nah an dem gew\u00f6hnlichen tar liegt. Die Belastung f\u00fcr das System ist im Prinzip <\/p>\n

gleich:<\/b>\"Backup,
\n
\nBei der Wiederherstellung des Backups mit Hilfe von zbackup<\/i> ergaben sich folgende Ergebnisse:<\/p>\n

Verschl\u00fcsselung, lzma-Kompression<\/b>\"Backup,
\n
\nArbeitszeit 11 Minuten und 8 Sekunden<\/p>\n

aes-Verschl\u00fcsselung, lzma-Kompression<\/b>\"Backup,
\n
\nArbeitszeit 14 Minuten<\/p>\n

aes-Verschl\u00fcsselung, lzo-Kompression<\/b>\"Backup,
\n
\nArbeitszeit 6 Minuten, 19 Sekunden<\/p>\n

Insgesamt nicht schlecht. Alles h\u00e4ngt 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\u00f6nnte sinnvoll sein, die Leistung im Multithread-Modus mit mehr als zwei Threads zu \u00fcberpr\u00fcfen.<\/p>\n

BorgBackup<\/i> Im unverschl\u00fcsselten Modus war es etwas langsamer als tar und ben\u00f6tigte 2 Minuten und 45 Sekunden. Allerdings gab es im Gegensatz zu tar die M\u00f6glichkeit zur Deduplizierung des Repositories. Die Belastung betrug dabei <\/p>\n

folgendes:<\/b>\"Backup,
\n
\nWenn man die Verschl\u00fcsselung auf der Basis von blake aktiviert, verlangsamt sich die Wiederherstellung geringf\u00fcgig. Die Wiederherstellungszeit in diesem Modus betr\u00e4gt 3 Minuten und 19 Sekunden, und die Belastung lag bei <\/p>\n

folgendem:<\/b>\"Backup,
\n
\nDie aes-Verschl\u00fcsselung arbeitet etwas langsamer, die Wiederherstellungszeit betr\u00e4gt 3 Minuten und 23 Sekunden, die Belastung hat sich dabei nicht wesentlich <\/p>\n

ver\u00e4ndert:<\/b>\"Backup,
\n
\nDa Borg im Multithread-Modus arbeiten kann, wird die Prozessorlast maximiert. Bei Aktivierung zus\u00e4tzlicher Funktionen steigt einfach die Arbeitszeit. Offensichtlich sollte die Multithread-Leistung \u00e4hnlich wie bei zbackup untersucht werden.<\/p>\n

Restic<\/i> schaffte die Wiederherstellung etwas langsamer, die Arbeitszeit betrug 4 Minuten und 28 Sekunden. Die Belastung sah dabei <\/p>\n

so:<\/b>\"Backup,
\n
\nanscheinend 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.<\/p>\n

Mit Hilfe von UrBackup<\/i> konnte die Daten in 8 Minuten und 19 Sekunden wiederherstellen, die Belastung war dabei <\/p>\n

folgenderma\u00dfen:<\/b>\"Backup,
\n
\nImmer noch sichtbar eine nicht sehr hohe Belastung, sogar niedriger als bei tar. Stellenweise gab es Spitzen, aber nicht mehr als die Belastung eines Kerns.<\/p>\n

Auswahl und Begr\u00fcndung der Vergleichskriterien<\/h2>\n

\nWie in einem der vorhergehenden Artikel gesagt, sollte das Backup-System folgenden Kriterien entsprechen:<\/p>\n