{"id":35003,"date":"2019-10-31T22:01:46","date_gmt":"2019-10-31T19:01:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup\/"},"modified":"2019-10-31T22:01:46","modified_gmt":"2019-10-31T19:01:46","slug":"rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-4-obzor-i-testirovanie-zbackup-restic-borgbackup","title":{"rendered":"Backup, Teil 4: \u00dcberblick und Test von zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,<\/p>\n

<\/p>\n

In diesem Artikel werden Softwarel\u00f6sungen f\u00fcr die Datensicherung behandelt, die durch die Aufteilung des Datenstroms in einzelne Komponenten (Chunks) ein Repository bilden.<\/p>\n

<\/p>\n

Die Repository-Komponenten k\u00f6nnen zus\u00e4tzlich komprimiert und verschl\u00fcsselt werden, und das Wichtigste ist, dass sie bei wiederholten Sicherungsprozessen wiederverwendet werden k\u00f6nnen.<\/p>\n

<\/p>\n

Eine Sicherung in einem solchen Repository ist eine benannte Kette von miteinander verbundenen Komponenten, beispielsweise basierend auf verschiedenen Hash-Funktionen.<\/p>\n

<\/p>\n

Es gibt mehrere solche L\u00f6sungen; ich werde auf drei eingehen: zbackup, borgbackup und restic.<\/p>\n

<\/a><\/noindex><\/p>\n

Erwartete Ergebnisse<\/h3>\n

<\/p>\n

Da alle Kandidaten auf die eine oder andere Weise die Erstellung eines Repositories erfordern, wird eine der wichtigsten Bewertungen die Gr\u00f6\u00dfe des Repositories sein. Im Idealfall sollte seine Gr\u00f6\u00dfe gem\u00e4\u00df der angenommenen Methodik 13 GB nicht \u00fcberschreiten, m\u00f6glicherweise sogar weniger \u2013 vorausgesetzt, es erfolgt eine gute Optimierung.<\/p>\n

<\/p>\n

Es ist auch \u00e4u\u00dferst w\u00fcnschenswert, die M\u00f6glichkeit zu haben, Sicherungen von Dateien direkt zu erstellen, ohne Archivierungsprogramme wie tar zu verwenden, sowie die Arbeit mit ssh\/sftp ohne zus\u00e4tzliche Hilfsmittel wie rsync und sshfs.<\/p>\n

<\/p>\n

Verhalten beim Erstellen von Backups:<\/strong><\/p>\n

<\/p>\n

    \n
  1. Die Gr\u00f6\u00dfe des Repositories entspricht der Gr\u00f6\u00dfe der \u00c4nderungen oder ist sogar kleiner.<\/li>\n
  2. Bei der Verwendung von Kompression und\/oder Verschl\u00fcsselung ist mit einer hohen CPU-Auslastung zu rechnen, und es kann auch eine erhebliche Belastung f\u00fcr das Netzwerk und das Speichersystem auftreten, falls der Archivierungs- und\/oder Verschl\u00fcsselungsprozess auf dem Backup-Server l\u00e4uft.<\/li>\n
  3. Wenn das Repository besch\u00e4digt wird, kann sowohl bei der Erstellung neuer Backups als auch beim Versuch der Wiederherstellung ein verz\u00f6gertes Fehler auftreten. Es sind zus\u00e4tzliche Ma\u00dfnahmen zur Gew\u00e4hrleistung der Integrit\u00e4t des Repositories zu planen oder integrierte Integrit\u00e4tspr\u00fcfungen zu nutzen.<\/li>\n<\/ol>\n

    <\/p>\n

    Als Referenzwert wird die Arbeit mit tar verwendet, wie in einem fr\u00fcheren Artikel gezeigt.<\/p>\n

    <\/p>\n

    Testen von zbackup<\/h3>\n

    <\/p>\n

    Die grundlegende Funktionsweise von zbackup besteht darin, dass das Programm in dem gegebenen Datenstrom Bereiche identifiziert, die identische Daten enthalten, diese optional komprimiert, verschl\u00fcsselt und jeden Bereich nur einmal speichert.<\/p>\n

    <\/p>\n

    F\u00fcr die Deduplizierung wird eine 64-Bit-Ring-Hash-Funktion mit gleitendem Fenster verwendet, um byteweise auf \u00dcbereinstimmungen mit bereits vorhandenen Datenbl\u00f6cken zu \u00fcberpr\u00fcfen (\u00e4hnlich wie es in rsync implementiert ist).<\/p>\n

    <\/p>\n

    F\u00fcr die Komprimierung werden lzma und lzo in multithreaded Ausf\u00fchrung verwendet, und f\u00fcr die Verschl\u00fcsselung kommt aes zum Einsatz. In den neuesten Versionen gibt es die M\u00f6glichkeit, k\u00fcnftig alte Daten aus dem Repository zu entfernen.
    \nDas Programm ist in C++ mit minimalen Abh\u00e4ngigkeiten geschrieben. Der Autor scheint sich vom Unix-Prinzip inspirieren lassen zu haben, denn das Programm akzeptiert Daten \u00fcber stdin beim Erstellen von Sicherungskopien und gibt einen \u00e4hnlichen Datenstrom \u00fcber stdout beim Wiederherstellen aus. So kann zbackup als sehr n\u00fctzliches \u201eBausteinchen\u201c beim Erstellen eigener Backup-L\u00f6sungen verwendet werden. Beispielsweise ist dieses Programm seit etwa 2014 das Hauptmittel zur Datensicherung f\u00fcr Heimcomputer des Autors des Artikels.<\/p>\n

    <\/p>\n

    Als Datenstrom wird standardm\u00e4\u00dfig tar verwendet, sofern nicht anders angegeben.<\/p>\n

    \nSehen wir uns die Ergebnisse an:<\/b><\/p>\n

    Die Funktionspr\u00fcfung wurde in 2 Varianten durchgef\u00fchrt:<\/p>\n

    <\/p>\n

      \n
    1. Ein Repository wird erstellt und zbackup auf dem Server mit den Ausgangsdaten gestartet, dann wird der Inhalt des Repositories auf den Backup-Server \u00fcbertragen.<\/li>\n
    2. Ein Repository wird auf dem Backup-Server erstellt, zbackup wird \u00fcber ssh auf dem Backup-Server gestartet und erh\u00e4lt die Daten \u00fcber eine Pipe.<\/li>\n<\/ol>\n

      <\/p>\n

      Die Ergebnisse der ersten Variante waren wie folgt: 43m11s \u2013 unter Verwendung eines unverschl\u00fcsselten Repositories und eines lzma-Kompressors, 19m13s \u2013 bei Ersetzung des Kompressors durch lzo.<\/p>\n

      <\/p>\n

      Die Serverlast mit den Ausgangsdaten war wie folgt (hier ein Beispiel mit lzma, mit lzo war es \u00e4hnlich, aber der Anteil von rsync betrug etwa ein Viertel der Zeit):<\/p>\n

      <\/p>\n

      \"Backup,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Es ist offensichtlich, dass ein solcher Backup-Prozess nur bei relativ seltenen und geringen \u00c4nderungen geeignet ist. Zudem ist es dringend empfehlenswert, die Arbeit von zbackup auf einen Thread zu beschr\u00e4nken, da die CPU-Auslastung sonst sehr hoch sein wird, da das Programm sehr gut mit mehreren Threads arbeiten kann. Die Disklast war gering, was insgesamt bei modernen SSD-basierten Speichersystemen kaum bemerkbar sein wird. Auch wird deutlich, dass der Prozess der Datensynchronisation des Repositories auf den Remote-Server gestartet wird, die Arbeitsgeschwindigkeit ist vergleichbar mit dem \u00fcblichen rsync und st\u00f6\u00dft an die Leistungsgrenzen des Speicher-Backup-Systems. Ein Nachteil dieses Ansatzes ist die Speicherung des lokalen Repositories und damit verbunden die Daten-Duplizierung.<\/p>\n

      <\/p>\n

      Die zweite Option, das zbackup direkt auf dem Backup-Speicherserver zu starten, ist interessanter und praktischer.<\/p>\n

      <\/p>\n

      Zun\u00e4chst wird die Funktionalit\u00e4t ohne die Verwendung von Verschl\u00fcsselung mit dem lzma-Kompressor gepr\u00fcft:<\/p>\n

      <\/p>\n

      \"Backup,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Die Laufzeit jedes Testdurchlaufs:<\/p>\n

      <\/p>\n

      Start 1
      \nStart 2
      \nStart 3<\/p>\n

      39m45s
      \n40m20s
      \n40m3s<\/p>\n

      7m36s
      \n8m3s
      \n7m48s<\/p>\n

      15m35s
      \n15m48s
      \n15m38s<\/p>\n

      <\/p>\n

      Wenn die AES-Verschl\u00fcsselung aktiviert wird, sind die Ergebnisse ausreichend nah:<\/p>\n

      <\/p>\n

      \"Backup,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Ben\u00f6tigte Zeit mit denselben Daten und Verschl\u00fcsselung:<\/p>\n

      <\/p>\n

      Start 1
      \nStart 2
      \nStart 3<\/p>\n

      43m40s
      \n44m12s
      \n44m3s<\/p>\n

      8m3s
      \n8m15s
      \n8m12s<\/p>\n

      15m0s
      \n15m40s
      \n15m25s<\/p>\n

      <\/p>\n

      Wenn die Verschl\u00fcsselung mit der Kompression mit lzo kombiniert wird, ergibt sich Folgendes:<\/p>\n

      <\/p>\n

      \"Backup,<\/a><\/noindex><\/p>\n

      <\/p>\n

      Laufzeit:<\/p>\n

      <\/p>\n

      Start 1
      \nStart 2
      \nStart 3<\/p>\n

      18m2s
      \n18m15s
      \n18m12s<\/p>\n

      5m13s
      \n5m24s
      \n5m20s<\/p>\n

      8m48s
      \n9m3s
      \n8m51s<\/p>\n

      <\/p>\n

      Die Gr\u00f6\u00dfe des resultierenden Repositories war relativ konstant und betrug 13 GB. Dies bedeutet, dass die Deduplication korrekt funktioniert. Auch bei bereits komprimierten Daten zeigt die Anwendung von lzo einen sp\u00fcrbaren Effekt. Insgesamt kommt zbackup hinsichtlich der Gesamtzeit f\u00fcr die Verarbeitung nahe an duplicity\/duplicati heran, bleibt aber um das 2- bis 5-fache hinter den auf librsync basierenden L\u00f6sungen zur\u00fcck.<\/p>\n

      <\/p>\n

      Die Vorteile sind offensichtlich \u2014 Einsparungen beim Speicherplatz auf dem Backup-Speicherserver. Was die \u00dcberpr\u00fcfung des Repositories betrifft, so sind daf\u00fcr keine Werkzeuge vorgesehen. Es wird empfohlen, ein ausfallsicheres RAID-System oder einen Cloud-Anbieter zu verwenden.<\/p>\n

      <\/p>\n

      Insgesamt ein recht guter Eindruck, trotz der Tatsache, dass das Projekt seit etwa 3 Jahren stagniert (die letzte Funktionenanfrage war vor etwa einem Jahr, jedoch ohne Antwort).<\/p>\n

      <\/p>\n

      Borgbackup testen<\/h3>\n

      <\/p>\n

      Borgbackup ist ein Fork von attic, einem \u00e4hnlichen System wie zbackup. Es ist in Python geschrieben und hat eine \u00e4hnliche Liste von Funktionen wie zbackup, kann jedoch zus\u00e4tzlich:<\/p>\n

      <\/p>\n