{"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 der Backup-Tools durchgef\u00fchrt. Zun\u00e4chst sollten wir jedoch kl\u00e4ren, wie schnell und effizient sie Daten aus Backups wiederherstellen.
\nZum Zweck des Vergleichs wird die Wiederherstellung aus einem vollst\u00e4ndigen Backup betrachtet, da dieser Betriebsmodus von allen Kandidaten unterst\u00fctzt wird. Um die Vergleichbarkeit zu erleichtern, wurden die Zahlen bereits gemittelt (Durchschnitt aus mehreren Durchl\u00e4ufen). Die Ergebnisse werden in einer Tabelle zusammengefasst, die auch Informationen zu folgenden Aspekten enth\u00e4lt: Verf\u00fcgbarkeit einer Web-Oberfl\u00e4che, Benutzerfreundlichkeit bei Einrichtung und Nutzung, Automatisierungsf\u00e4higkeiten sowie verschiedene zus\u00e4tzliche Funktionen (z. B. Datenintegrit\u00e4tspr\u00fcfung) usw. Grafiken zeigen die Serverlast, auf dem die Daten angewendet werden (nicht der Server f\u00fcr Backup-Speicher).
\n<\/a><\/noindex><\/p>\n

Datenwiederherstellung<\/h2>\n

\nAls Referenzpunkte werden rsync und tar verwendet, da sie typischerweise die Grundlage bilden f\u00fcr<\/a><\/noindex> einfachste Skripte zur Sicherung von Daten.<\/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 eine Einschr\u00e4nkung des Speicher-Subsystems des Backup-Servers (s\u00e4gezahnf\u00f6rmige Grafiken). Au\u00dferdem ist die Auslastung eines Kerns ohne gr\u00f6\u00dfere Probleme deutlich sichtbar (niedriger iowait und softirq \u2013 keine Probleme mit der Festplatte und dem Netzwerk). Da die beiden anderen Programme, n\u00e4mlich rdiff-backup und rsnapshot, auf rsync basieren und ebenfalls rsync als Wiederherstellungswerkzeug anbieten, wird ihr Belastungsprofil und die Wiederherstellungszeit \u00e4hnlich sein.<\/p>\n

Tar<\/i> hat etwas schneller funktioniert, in <\/p>\n

2 Minuten und 43 Sekunden:<\/b>\"Backup,
\n
\nDie Gesamtlast des Systems war im Durchschnitt um 20 % h\u00f6her aufgrund eines gestiegenen softirq \u2013 die Overheadkosten der Netzwerksysteme sind angestiegen.<\/p>\n

Wenn das Archiv zus\u00e4tzlich komprimiert wird, steigt die Wiederherstellungszeit auf 3 Minuten und 19 Sekunden mit
\ndieser Last auf dem Hauptserver (Entpacken auf der Seite des Hauptservers):<\/b>\"Backup,
\n
\nDer Entpackungsprozess beansprucht beide CPU-Kerne, da zwei Prozesse ausgef\u00fchrt werden. Insgesamt ist das ein erwartetes Ergebnis. Ein \u00e4hnliches Ergebnis (3 Minuten und 20 Sekunden) wurde auch erzielt, als gzip auf der Serverseite mit den Backups ausgef\u00fchrt wurde; die Lastprofil des Hauptservers war dabei sehr \u00e4hnlich wie beim Ausf\u00fchren von tar ohne gzip-Kompression (siehe vorheriges Diagramm).<\/p>\n

In rdiff-backup<\/i> kann das neueste Backup mit dem normalen rsync synchronisiert werden (die Ergebnisse werden \u00e4hnlich sein), jedoch m\u00fcssen \u00e4ltere Backups weiterhin mit dem rdiff-backup-Programm wiederhergestellt werden, das die Wiederherstellung in 17 Minuten und 17 Sekunden erfolgreich durchgef\u00fchrt hat und dabei <\/p>\n

eine solche Last erzeugt hat:<\/b>\"Backup,
\n
\nM\u00f6glicherweise war das so beabsichtigt; jedenfalls haben die Autoren eine solche L\u00f6sung zur Geschwindigkeitsbegrenzung vorgeschlagen. bieten eine solche L\u00f6sung an<\/a><\/noindex>Der vollst\u00e4ndige Wiederherstellungsprozess ben\u00f6tigt etwas weniger als die H\u00e4lfte eines Kerns, mit einem proportional vergleichbaren Leistungsprofil (d.h. 2-5 Mal langsamer) hinsichtlich der Disk- und Netzwerkleistung im Vergleich zu rsync.<\/p>\n

Rsnapshot<\/i> empfiehlt zur Wiederherstellung die Verwendung von normalem rsync, daher werden die Ergebnisse \u00e4hnlich sein. Insgesamt hat sich das bewahrheitet.<\/p>\n

Burp<\/i> Die Wiederherstellung der Sicherung wurde in 7 Minuten und 2 Sekunden erledigt mit
\ndieser Last:<\/b>\"Backup,
\n
\nEs 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\u00fctzung f\u00fcr mehrere Kopien, allerdings ist es etwa doppelt so langsam. Wenn die Daten aus dem zuletzt erstellten Backup wiederhergestellt werden m\u00fcssen, kann man rsync verwenden, mit einigen kleinen Einschr\u00e4nkungen.<\/p>\n

Ein \u00e4hnliches Tempo und Last zeigte das Programm BackupPC<\/i> im rsync-\u00dcbertragungsmodus und hat das Backup in <\/p>\n

7 Minuten und 42 Sekunden wiederhergestellt:<\/b>\"Backup,
\n
\nIm tar-Daten\u00fcbertragungsmodus war BackupPC jedoch langsamer: Die Wiederherstellung dauerte 12 Minuten und 15 Sekunden, wobei die CPU-Auslastung insgesamt etwa anderthalbmal niedriger war. <\/p>\n

um die H\u00e4lfte:<\/b>\"Backup,
\n
\nDuplicity<\/i> ohne Verschl\u00fcsselung zeigte er leicht bessere Ergebnisse und ben\u00f6tigte f\u00fcr die Wiederherstellung eines Backups 10 Minuten und 58 Sekunden. Wenn die Verschl\u00fcsselung 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\u00f6\u00dfe des Archivs angegeben werden, das beim Aufteilen des Datenstroms verwendet wird. Insgesamt gibt es auf herk\u00f6mmlichen Festplatten, auch aufgrund des einstr\u00e4ngigen Betriebsmodus, keinen wesentlichen Unterschied. Dieser k\u00f6nnte jedoch bei unterschiedlichen Blockgr\u00f6\u00dfen auftreten, insbesondere bei der Verwendung hybrider Speicherl\u00f6sungen. Die Belastung auf dem Hauptserver w\u00e4hrend der Wiederherstellung betrug:<\/p>\n

ohne Verschl\u00fcsselung<\/b>\"Backup,
\n
\nmit Verschl\u00fcsselung<\/b>\"Backup,
\n
\nDuplicati<\/i> zeigte eine vergleichbare Wiederherstellungsgeschwindigkeit und ben\u00f6tigte 13 Minuten und 45 Sekunden. Rund 5 Minuten ben\u00f6tigte die \u00dcberpr\u00fcfung der Richtigkeit der wiederhergestellten Daten (insgesamt etwa 19 Minuten). Die Belastung lag dabei <\/p>\n

recht hoch:<\/b>\"Backup,
\n
\nAls die AES-Verschl\u00fcsselung intern aktiviert wurde, betrug die Wiederherstellungszeit 21 Minuten und 40 Sekunden, wobei die CPU-Auslastung w\u00e4hrend des gesamten Wiederherstellungsprozesses maximal war (beide Kerne!). Beim Daten\u00fcberpr\u00fcfungsprozess war nur ein Thread aktiv, der einen CPU-Kern beanspruchte. Die Datenpr\u00fcfung nach der Wiederherstellung dauerte ebenfalls 5 Minuten, was insgesamt fast 27 Minuten betr\u00e4gt.<\/p>\n

Ergebnis<\/b>\"Backup,
\n
\nEin wenig schneller bew\u00e4ltigte Duplicati die Wiederherstellung mit der externen Verschl\u00fcsselungssoftware GPG, doch insgesamt sind die Unterschiede zur vorherigen Methode minimal. Die Arbeitszeit betrug 16 Minuten und 30 Sekunden, einschlie\u00dflich der Datenpr\u00fcfung, die 6 Minuten in Anspruch nahm. Die Auslastung war <\/p>\n

so:<\/b>\"Backup,
\n
\nAMANDA<\/i>, das mit tar arbeitete, ben\u00f6tigte 2 Minuten und 49 Sekunden, was im Grunde genommen recht nah an einem normalen tar ist. Die Systemauslastung ist insgesamt <\/p>\n

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

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

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

Verschl\u00fcsselung AES, LZO-Kompression<\/b>\"Backup,
\n
\nArbeitszeit 6 Minuten und 19 Sekunden<\/p>\n

Insgesamt recht gut. Alles h\u00e4ngt 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\u00e4uft die Wiederherstellung im Vergleich dazu dreimal langsamer. Es k\u00f6nnte sinnvoll sein, die Funktion im Multithread-Modus mit mehr als zwei Threads zu pr\u00fcfen.<\/p>\n

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

folgendes:<\/b>\"Backup,
\n
\nWenn die Verschl\u00fcsselung auf Basis von Blake aktiviert wird, verlangsamt sich die Wiederherstellung leicht. Die Wiederherstellungszeit in diesem Modus betr\u00e4gt 3 Minuten und 19 Sekunden, und die Last betrug <\/p>\n

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

hat sich nicht ge\u00e4ndert:<\/b>\"Backup,
\n
\nDa Borg im Multithread-Modus arbeiten kann, ist die CPU-Auslastung hoch, w\u00e4hrend sich die Laufzeit einfach erh\u00f6ht, wenn zus\u00e4tzliche Funktionen aktiviert werden. Offensichtlich lohnt es sich, die Multithread-Funktionalit\u00e4t \u00e4hnlich wie bei zbackup zu untersuchen.<\/p>\n

Restic<\/i> hat die Wiederherstellung etwas langsamer bew\u00e4ltigt, die Laufzeit betrug 4 Minuten und 28 Sekunden. Die Auslastung sah dabei <\/p>\n

so aus:<\/b>\"Backup,
\n
\nOffensichtlich arbeitet der Wiederherstellungsprozess in mehreren Threads, die Effizienz ist jedoch nicht so hoch wie bei BorgBackup, aber zeitlich vergleichbar mit herk\u00f6mmlichem rsync.<\/p>\n

Mit UrBackup<\/i> konnten die Daten in 8 Minuten und 19 Sekunden wiederhergestellt werden, die Auslastung betrug dabei <\/p>\n

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

Auswahl und Begr\u00fcndung der Kriterien f\u00fcr den Vergleich<\/h2>\n

\nWie in einem der vorherigen Artikel erw\u00e4hnt, sollte das Backup-System die folgenden Kriterien erf\u00fcllen:<\/p>\n