{"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":"Sicherung, Teil 4: \u00dcberblick und Test von zbackup, restic, borgbackup","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Sicherung,<\/p>\n

<\/p>\n

In diesem Artikel werden Softwarel\u00f6sungen f\u00fcr die Datensicherung betrachtet, die durch das Aufteilen von Datenstr\u00f6men in separate Komponenten (Chunks) ein Repository bilden.<\/p>\n

<\/p>\n

Die Komponenten des Repositories k\u00f6nnen zus\u00e4tzlich komprimiert und verschl\u00fcsselt werden und, das Wichtigste - bei wiederholten Sicherungsprozessen - erneut wiederverwendet werden.<\/p>\n

<\/p>\n

Ein Backup in einem solchen Repository ist eine benannte Kette miteinander verbundener Komponenten, beispielsweise basierend auf verschiedenen Hash-Funktionen.<\/p>\n

<\/p>\n

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

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

Erwartete Ergebnisse<\/h3>\n

<\/p>\n

Da alle Bewerber mehr oder weniger die Erstellung eines Repositories erfordern, wird eine der wichtigsten Faktoren die Bewertung der Repository-Gr\u00f6\u00dfe sein. Im Idealfall sollte seine Gr\u00f6\u00dfe 13 GB gem\u00e4\u00df der anerkannten Methode nicht \u00fcberschreiten, oder sogar kleiner sein - vorausgesetzt, es gibt eine gute Optimierung.<\/p>\n

<\/p>\n

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

<\/p>\n

Verhalten bei der Erstellung von Backups:<\/strong><\/p>\n

<\/p>\n

    \n
  1. Die Gr\u00f6\u00dfe des Repositories wird der Gr\u00f6\u00dfe der \u00c4nderungen entsprechen oder kleiner sein.<\/li>\n
  2. Es wird mit einer hohen CPU-Belastung beim Einsatz von Kompression und\/oder Verschl\u00fcsselung gerechnet, und zudem ist eine erhebliche Belastung f\u00fcr das Netzwerk und das Speichersystem wahrscheinlich, wenn der Prozess der Archivierung und\/oder Verschl\u00fcsselung auf dem Backup-Server ausgef\u00fchrt wird.<\/li>\n
  3. Falls das Repository besch\u00e4digt wird, ist eine verz\u00f6gerte Fehleranmeldung sowohl bei der Erstellung neuer Backups als auch bei dem Versuch der Wiederherstellung wahrscheinlich. Es sollten zus\u00e4tzliche Ma\u00dfnahmen zur Gew\u00e4hrleistung der Integrit\u00e4t des Repositories eingeplant werden oder eingebaute Mittel zur \u00dcberpr\u00fcfung seiner Integrit\u00e4t verwendet werden.<\/li>\n<\/ol>\n

    <\/p>\n

    Als Referenzwert wurde die Arbeit mit tar angenommen, wie in einem der vorherigen Artikel gezeigt.<\/p>\n

    <\/p>\n

    Testing zbackup<\/h3>\n

    <\/p>\n

    Der allgemeine Mechanismus von zbackup besteht darin, dass das Programm in dem Datenstrom, der an den Eingang gegeben wird, Bereiche identifiziert, die identische Daten enthalten, und diese dann optional komprimiert, verschl\u00fcsselt und jede Region nur einmal speichert.<\/p>\n

    <\/p>\n

    Zur Deduplication wird eine 64-Bit-Ring-Hash-Funktion mit gleitendem Fenster f\u00fcr eine Byte-f\u00fcr-Byte-\u00dcberpr\u00fcfung verwendet, um \u00dcbereinstimmungen mit bereits vorhandenen Datenbl\u00f6cken zu erkennen (\u00e4hnlich wie es in rsync implementiert ist).<\/p>\n

    <\/p>\n

    F\u00fcr die Kompression werden lzma und lzo in multithreaded Ausf\u00fchrung eingesetzt, und f\u00fcr die Verschl\u00fcsselung kommt aes zum Einsatz. In den neuesten Versionen besteht die M\u00f6glichkeit, \u00e4ltere Daten zuk\u00fcnftig aus dem Repository zu entfernen.
    \nDas Programm ist in C++ mit minimalen Abh\u00e4ngigkeiten geschrieben. Der Autor scheint sich vom Unix-Weg inspirieren lassen zu haben, daher nimmt das Programm Daten \u00fcber stdin beim Erstellen von Backups entgegen und gibt einen \u00e4hnlichen Datenstrom an stdout beim Wiederherstellen aus. Auf diese Weise kann zbackup als ein recht brauchbarer \"Baustein\" f\u00fcr die Erstellung eigener Backup-L\u00f6sungen verwendet werden. Zum Beispiel ist dieses Programm f\u00fcr den Autor des Artikels seit etwa 2014 das Hauptwerkzeug zur Datensicherung f\u00fcr Heimcomputer.<\/p>\n

    <\/p>\n

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

    \nLassen Sie uns sehen, welche Ergebnisse erzielt wurden:<\/b><\/p>\n

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

    <\/p>\n

      \n
    1. Ein Repository wird erstellt und zbackup wird auf dem Server mit den Quelldaten gestartet, anschlie\u00dfend wird der Inhalt des Repositories auf den Backup-Speicher-Server \u00fcbertragen.<\/li>\n
    2. Ein Repository wird auf dem Backup-Speicher-Server erstellt, zbackup wird \u00fcber ssh auf dem Backup-Speicher-Server gestartet, die Daten werden ihm \u00fcber eine Pipe bereitgestellt.<\/li>\n<\/ol>\n

      <\/p>\n

      Die Ergebnisse der ersten Variante waren: 43m11s \u2014 bei Verwendung eines unverschl\u00fcsselten Repositories und des Kompressors lzma, 19m13s \u2014 bei Austausch des Kompressors gegen lzo.<\/p>\n

      <\/p>\n

      Die Belastung des Servers mit den Quelldaten war wie folgt (beispielhaft dargestellt mit lzma; mit lzo war das Bild ungef\u00e4hr \u00e4hnlich, aber der Anteil von rsync betrug etwa ein Viertel der Zeit):<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Es ist offensichtlich, dass ein solcher Backup-Prozess nur bei relativ seltenen und kleinen \u00c4nderungen geeignet ist. Es ist auch dringend ratsam, die Arbeit von zbackup auf einen Thread zu beschr\u00e4nken, da sonst die CPU-Auslastung sehr hoch ist, da das Programm ziemlich gut in mehreren Threads arbeiten kann. Die Belastung der Festplatte war gering, was in der heutigen Festplattensubsystem auf SSD-Basis insgesamt unauff\u00e4llig ist. Auch der Start des Daten-Synchronisationsprozesses des Repositories auf dem Remote-Server ist deutlich sichtbar; die Geschwindigkeit ist vergleichbar mit der von rsync und wird durch die Leistung des Speichersystems des Backup-Servers limitiert. Nachteil dieses Ansatzes ist die Speicherung des lokalen Repositories und somit die Duplizierung der Daten.<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Zu Beginn wird die Funktion ohne die Verwendung von Verschl\u00fcsselung mit dem Komprimierungsalgorithmus lzma \u00fcberpr\u00fcft:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Die Laufzeit jeder Testausf\u00fchrung:<\/p>\n

      <\/p>\n

      Ausf\u00fchrung 1
      \nAusf\u00fchrung 2
      \nAusf\u00fchrung 3<\/p>\n

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

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

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

      <\/p>\n

      Wenn die Verschl\u00fcsselung mit aes aktiviert wird, sind die Ergebnisse recht \u00e4hnlich:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Die Laufzeit mit denselben Daten, jedoch mit Verschl\u00fcsselung:<\/p>\n

      <\/p>\n

      Ausf\u00fchrung 1
      \nAusf\u00fchrung 2
      \nAusf\u00fchrung 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 lzo-Kompression kombiniert wird, ergeben sich folgende Ergebnisse:<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Die Laufzeit:<\/p>\n

      <\/p>\n

      Ausf\u00fchrung 1
      \nAusf\u00fchrung 2
      \nAusf\u00fchrung 3<\/p>\n

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

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

      8m48s
      \n9m3s
      \nDie Gr\u00f6\u00dfe des resultierenden Repositories war relativ gleich und betrug 13 GB. Das bedeutet, dass die Deduplizierung korrekt funktioniert. Au\u00dferdem hat die Anwendung von lzo auf bereits komprimierten Daten einen merklichen Effekt; die Gesamtlaufzeit von zbackup n\u00e4hert sich stark an die von duplicity\/duplicati an, bleibt jedoch 2-5 mal hinter denen zur\u00fcck, die auf librsync basieren.<\/p>\n

      <\/p>\n

      Die Vorteile sind offensichtlich \u2013 Einsparungen beim Speicherplatz auf dem Backup-Speicherserver. Was die Tools zur \u00dcberpr\u00fcfung des Repositories betrifft, so sind diese von dem Autor von zbackup nicht vorgesehen, es wird empfohlen, ein fehlerresistentes RAID-System oder einen Cloud-Anbieter zu verwenden.<\/p>\n

      <\/p>\n

      Insgesamt ein sehr positiver Eindruck, obwohl das Projekt seit etwa 3 Jahren stillsteht (die letzte Feature-Anfrage war vor etwa einem Jahr, blieb jedoch unbeantwortet).<\/p>\n

      <\/p>\n

      Testen von borgbackup<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Borgbackup ist ein Fork von attic, einem weiteren, \u00e4hnlichen System wie zbackup. Es ist in Python geschrieben und bietet eine \u00e4hnliche Funktionalit\u00e4t wie zbackup, kann aber zus\u00e4tzlich:<\/p>\n

      <\/p>\n