Backup, Teil 1: Zielsetzung, Überblick über Methoden und Technologien

Warum sind Backups notwendig? Die Hardware ist doch ziemlich zuverlässig, und es gibt zudem die "Cloud", die in Bezug auf Zuverlässigkeit besser ist als physische Server: Bei richtiger Konfiguration kann ein "Cloud"-Server ganz einfach den Ausfall eines physischen Infrastrukturservers überstehen, und aus Sicht der Nutzer der Dienste gibt es nur einen kleinen, kaum merklichen Anstieg der Wartungszeit. Außerdem erfordert die Duplizierung von Informationen oft, dass man "überflüssige" CPU-Zeit, Festplattenlast und Netzwerktraffic bezahlt.

Ein ideales Programm funktioniert schnell, läuft nicht im RAM aus, hat keine Löcher und existiert nicht.

—Unbekannter

Da Programme noch von menschlichen Entwicklern geschrieben werden und der Testprozess oft fehlt, plus die Bereitstellung von Software extrem selten unter Verwendung von "Best Practices" erfolgt (die selbst auch Programme sind und daher nicht perfekt), müssen Systemadministratoren meist Aufgaben lösen, die kurz und prägnant klingen: "Wiederherstellen, wie es war", "Datenbank in den Normalbetrieb versetzen", "Arbeitet langsam — zurücksetzen", sowie mein Lieblingssatz "Ich weiß nicht, was, aber repariere es".

Neben logischen Fehlern, die durch nachlässige Arbeit der Entwickler oder Zufälle entstehen, sowie unvollständigem Wissen oder Verständnis kleiner Eigenschaften des Programmaufbaus — darunter Bindungen und systemische Komponenten, einschließlich Betriebssysteme, Treiber und Firmware — gibt es noch viele andere Fehler. Viele Entwickler verlassen sich beispielsweise auf die Laufzeit und vergessen dabei völlig die physikalischen Gesetze, die man mit Programmen immer noch nicht umgehen kann. Dazu gehören die unendliche Zuverlässigkeit von Speichersubsystemen und insgesamt jeder Art von Datenspeicherung (einschließlich RAM und CPU-Cache!), sowie null Verarbeitungszeit auf der CPU, keinerlei Fehler bei der Übertragung im Netzwerk und bei der Verarbeitung auf der CPU und eine Netzwerklatenz, die gleich 0 ist. Man sollte auch die berüchtigten Deadlines nicht vernachlässigen, denn wenn man sie nicht einhält — treten Probleme auf, die komplizierter sind als die Feinheiten der Netz- und Festplattenarbeit.

Wie steht es um Probleme, die sich unübersehbar aufdrängen und über wertvolle Daten schweben? Echte Entwickler sind nicht zu ersetzen, und es ist ungewiss, ob dies in naher Zukunft möglich sein wird. Auf der anderen Seite konnte bislang nur bei wenigen Projekten vollständig bewiesen werden, dass ein Programm wie geplant funktioniert, und es ist keineswegs garantiert, dass diese Beweise auf andere, ähnliche Projekte übertragen werden können. Zudem erfordern solche Beweise enorm viel Zeit und spezielle Fähigkeiten und Kenntnisse, was die Möglichkeit ihrer Anwendung unter Berücksichtigung der Fristen praktisch auf ein Minimum reduziert. Darüber hinaus beherrschen wir noch nicht die extrem schnellen, kostengünstigen und unendlich zuverlässigen Technologien zur Speicherung, Verarbeitung und Übertragung von Informationen. Solche Technologien existieren, wenn überhaupt, meist nur als Konzepte oder — häufiger — lediglich in fantastischen Büchern und Filmen.

Gute Künstler kopieren, große Künstler stehlen.

—Pablo Picasso.

Die erfolgreichsten Lösungen und erstaunlich einfachen Dinge entstehen oft dort, wo absolut inkompatible Konzepte, Technologien, Wissen und Fachgebiete aufeinander treffen.

Zum Beispiel haben Vögel und Flugzeuge Flügel, aber trotz der funktionalen Ähnlichkeit — das Prinzip des Handelns stimmt in einigen Modi überein, und technische Probleme werden ähnlich gelöst: hohle Knochen, Verwendung von starken und leichten Materialien usw. — sind die Ergebnisse grundverschieden, auch wenn sie sehr ähnlich sind. Die besten Beispiele, die wir in unserer Technik beobachten, sind auch größtenteils der Natur entliehen: dichte Abteile in Schiffen und U-Boote — eine direkte Analogie zu ringelwürfeln; die Konstruktion von RAID-Arrays und die Überprüfung der Integrität von Daten — die Verdopplung der DNA-Kette; sowie paarige Organe, die Unabhängigkeit der Funktionsweise verschiedener Organe vom zentralen Nervensystem (Automatisierung der Herzarbeit) und Reflexe — autonome Systeme im Internet. Natürlich kann es problematisch sein, fertige Lösungen direkt zu übernehmen, aber wer weiß, vielleicht gibt es keine anderen Lösungen.

Wüsste man, wo man fallen wird, hätte man sich mit Stroh ausgelegt!

—Weisheit des belarussischen Volkes

Das bedeutet, dass Backups für diejenigen, die wünschen, unbedingt notwendig sind:

• Die Möglichkeit, die Arbeit ihrer Systeme mit minimalen Ausfallzeiten oder sogar ohne sie wiederherzustellen.
• Handeln Sie mutig, denn im Falle eines Fehlers gibt es immer die Möglichkeit, zurückzukehren.
• Minimieren Sie die Folgen von gezielter Datenbeschädigung.

Hier ist ein wenig Theorie.

Jede Klassifizierung ist willkürlich. Die Natur klassifiziert nicht. Wir klassifizieren, weil es für uns praktischer ist. Und wir klassifizieren nach Daten, die wir ebenfalls willkürlich auswählen.

—Jean Brüller

Unabhängig von der physikalischen Speicherform kann die logische Datenspeicherung grob in zwei Zugriffsarten auf diese Daten unterteilt werden: blockweise und dateibasiert. Diese Unterteilung ist in letzter Zeit ziemlich verschwommen, denn rein blockbasierte und rein dateibasierte logische Speicher existieren nicht. Für die Einfachheit nehmen wir jedoch an, dass sie existieren.

Die blockweise Datenspeicherung bedeutet, dass es ein physikalisches Gerät gibt, auf dem Daten in festen Portionen, Blöcken, gespeichert werden. Der Zugriff auf die Blöcke erfolgt über eine bestimmte Adresse, wobei jeder Block eine eigene Adresse innerhalb des Geräts hat.

Ein Backup erfolgt in der Regel durch das Kopieren von Datenblöcken. Um die Integrität der Daten zum Zeitpunkt des Kopierens zu gewährleisten, wird die Aufzeichnung neuer Blöcke gestoppt, ebenso wie Änderungen an bestehenden. Ein passendes Analogon aus der realen Welt wäre ein Schrank mit gleich nummerierten Fächern.

Die dateibasierte Datenspeicherung funktioniert ähnlich wie die blockweise Speicherung und wird oft darüber organisiert. Wichtige Unterschiede sind das Vorhandensein einer Speicherhierarchie und menschenlesbare Namen. Es wird eine Abstraktion in Form von Dateien – benannten Datenbereichen – sowie von Verzeichnissen – speziellen Dateien, die Beschreibungen und Zugriffe auf andere Dateien speichern – geschaffen. Dateien können mit zusätzlichen Metadaten versehen werden: Erstellungszeit, Zugriffsflags usw. In der Regel wird so gesichert: Es werden Änderungen an Dateien gesucht, die dann in einen anderen, strukturell ähnlichen Datenspeicher kopiert werden. Die Integrität der Daten wird normalerweise durch das Fehlen von Dateien gewährleistet, in die geschrieben wird. Die Metadaten der Dateien werden ähnlich gesichert. Das nächste Analogon ist eine Bibliothek mit Abteilungen für verschiedene Bücher sowie einem Katalog mit menschenlesbaren Buchtiteln.

In letzter Zeit wird manchmal eine weitere Variante beschrieben, mit der im Grunde das dateibasierte Speichern von Daten begann und die die gleichen archaischen Merkmale aufweist: das objektbasierte Speichern von Daten.

Es unterscheidet sich vom dateibasierten Speichern dadurch, dass es keine mehr als eine Ebene von Verschachtelung hat (flache Struktur), und die Dateinamen sind zwar leserlich, jedoch eher für die Verarbeitung durch Maschinen ausgelegt. Bei der Sicherung werden Objekt-Speicher häufig ähnlich wie dateibasierte Speicher behandelt, es gibt aber gelegentlich auch andere Varianten.

— Es gibt zwei Arten von Systemadministratoren: Diejenigen, die keine Backups erstellen, und diejenigen, die es SCHON tun.
— Tatsächlich gibt es drei Arten: Es gibt auch jene, die überprüfen, ob die Backups wiederhergestellt werden können.

—Unbekannter

Es ist auch wichtig zu verstehen, dass der Prozess des Datensicherungs durch Programme durchgeführt wird. Daher hat er die gleichen Nachteile wie andere Programme. Um die Abhängigkeit vom menschlichen Faktor sowie von Merkmalen, die einzeln nicht stark ins Gewicht fallen, aber zusammen einen spürbaren Effekt haben können, zu reduzieren (nicht auszuschließen!), wird die sogenannte 3-2-1-Regel angewandt. Es gibt viele Möglichkeiten, sie zu interpretieren, aber mir gefällt folgende Auslegung am besten: Man sollte 3 Sätze derselben Daten speichern, 2 Sätze sollten in unterschiedlichen Formaten gespeichert werden, und 1 Satz sollte in einem geografisch entfernten Speicher vorhanden sein.

Unter dem Speicherformat ist Folgendes zu verstehen:

• Wenn es eine Abhängigkeit von der physischen Speicherweise gibt, ändern wir die physische Speicherweise.
• Wenn es eine Abhängigkeit von der logischen Speicherweise gibt, ändern wir die logische Speicherweise.

Um den maximalen Effekt der 3-2-1-Regel zu erzielen, wird empfohlen, das Speicherformat auf beide Arten zu ändern.

Bezüglich der Bereitstellung des Backups für den vorgesehenen Zweck — der Wiederherstellung der Funktionsfähigkeit — unterscheidet man zwischen „heißen“ und „kalten“ Backups. Heiße Backups unterscheiden sich von kalten nur darin, dass sie sofort einsatzbereit sind, während kalte Backups für die Wiederherstellung einige zusätzliche Aktionen erfordern: Entschlüsselung, Extraktion aus dem Archiv usw.

Es ist wichtig, heiße und kalte Kopien nicht mit Online- und Offline-Kopien zu verwechseln, die eine physische Isolation der Daten implizieren und im Grunde eine andere Klassifizierungsmethode für Backup-Strategien darstellen. So kann eine Offline-Kopie, die nicht direkt mit dem System verbunden ist, von dem aus sie wiederhergestellt werden soll, sowohl heiß als auch kalt sein (in Bezug auf die Wiederherstellungsbereitschaft). Eine Online-Kopie kann direkt dort verfügbar sein, wo sie wiederhergestellt werden muss, und ist meistens heiß, es gibt aber auch kalte Kopien.

Zudem sollte man nicht vergessen, dass der Prozess der Erstellung von Backups normalerweise nicht mit der Erstellung einer einzelnen Sicherung endet und es durchaus eine große Anzahl von Kopien geben kann. Folglich ist es wichtig, zwischen vollständigen Sicherungen zu unterscheiden, d.h. solchen, die unabhängig von anderen Sicherungen wiederhergestellt werden können, sowie zwischen differentiellen (inkrementellen, differenziellen, dekrementalen usw.) Kopien - solchen, die nicht eigenständig wiederhergestellt werden können und die vorherige Wiederherstellung einer oder mehrerer anderer Sicherungen erfordern.

Differenzielle inkrementelle Kopien sind ein Versuch, den Speicherplatz für Sicherungen zu sparen. So werden in das Backup nur die seit der letzten Sicherung geänderten Daten geschrieben.

Differenzielle dekrementale Kopien werden aus demselben Grund erstellt, aber auf etwas andere Weise: Es wird ein vollständiges Backup erstellt, aber tatsächlich wird nur die Differenz zwischen der neuen Kopie und der vorherigen gespeichert.

Der Prozess des Backups über einem Speicher, der keine Duplikate speichert, sollte besonders betrachtet werden. Wenn dort vollständige Sicherungen geschrieben werden, wird tatsächlich nur die Differenz zwischen den Sicherungen aufgezeichnet, der Wiederherstellungsprozess wird jedoch ähnlich der Wiederherstellung von einer vollständigen Sicherung durchgeführt und ist vollständig transparent.

Quis custodiet ipsos custodes?

(Wer bewacht die Wächter selbst? — lat.)

Es ist äußerst unangenehm, wenn keine Sicherungen vorhanden sind, aber es ist viel schlimmer, wenn eine Sicherung zwar erstellt wurde, sich bei der Wiederherstellung jedoch herausstellt, dass sie nicht wiederhergestellt werden kann, weil:

• Die Integrität der ursprünglichen Daten wurde verletzt.
• Der Speicher mit den Sicherungen ist beschädigt.
• Die Wiederherstellung funktioniert sehr langsam, es ist nicht möglich, auf teilweise wiederhergestellte Daten zuzugreifen.

Ein richtig gestalteter Backup-Prozess muss solche Anmerkungen berücksichtigen, insbesondere die ersten beiden.

Die Integrität der Originaldaten kann durch verschiedene Methoden garantiert werden. Am häufigsten werden folgende Methoden verwendet: a) Erstellung von Snapshots des Dateisystems auf Blockebene, b) "Einfrieren" des Zustands des Dateisystems, c) spezielles Blockgerät mit Versionsspeicherung, d) sequenzielle Aufzeichnung von Dateien oder Blöcken. Auch Prüfziffern werden verwendet, um die Daten während der Wiederherstellung zu überprüfen.

Speicherschäden können ebenfalls mithilfe von Prüfziffern erkannt werden. Eine zusätzliche Methode ist der Einsatz spezialisierter Geräte oder Dateisysteme, in denen bereits aufgezeichnete Daten nicht mehr geändert werden können, aber neue hinzugefügt werden können.

Um die Wiederherstellung zu beschleunigen, wird die Datenwiederherstellung mit mehreren Prozessen durchgeführt, vorausgesetzt, dass es kein "Engpass" in Form eines langsamen Netzwerks oder eines nicht schnellen Speichersystems gibt. Um das Problem mit teilweise wiederhergestellten Daten zu umgehen, kann der Backup-Prozess in relativ kleine Teilaufgaben unterteilt werden, von denen jede separat ausgeführt wird. So wird die Möglichkeit geschaffen, die Funktionalität sequenziell wiederherzustellen und die Wiederherstellungszeit vorherzusagen. Dieses Problem liegt häufig im organisatorischen Bereich (SLA), daher werden wir nicht näher darauf eingehen.

Es versteht sich von selbst, dass es nicht derjenige ist, der Gewürze zu jedem Gericht hinzufügt, der sich damit auskennt, sondern derjenige, der niemals etwas Überflüssiges hinzufügt.

—W. Sinjawski

Die Erfahrung im verwendeten Softwarebereich kann bei Systemadministratoren variieren, aber die allgemeinen Prinzipien bleiben dennoch die gleichen, insbesondere:

• Es wird dringend empfohlen, fertige Lösungen zu verwenden.
• Programme sollten vorhersehbar arbeiten, d.h. es sollten keine undocumented features oder Engpässe vorhanden sein.
• Die Konfiguration jedes Programms sollte so einfach sein, dass man nicht jedes Mal das Handbuch oder ein Spickzettel lesen muss.
• Die Lösung sollte möglichst universell sein, da sich die Hardwaremerkmale der Server erheblich unterscheiden können.

Zum Erstellen von Sicherungskopien von Blockgeräten gibt es folgende verbreitete Programme:

• dd, bekannt bei erfahrenen Systemadministratoren, sowie ähnliche Programme (zum Beispiel dd_rescue).
• In einige Dateisysteme integrierte Dienstprogramme (Utilities), die ein Abbild (Dump) des Dateisystems erstellen.
• Alleskönner-Utilities; zum Beispiel, partclone.
• Eigene, oft proprietäre Lösungen; zum Beispiel, NortonGhost und spätere Versionen.

Für Dateisysteme wird die Aufgabe der Sicherung teilweise mit Methoden gelöst, die für Blockgeräte anwendbar sind; das Problem kann jedoch auch effektiver gelöst werden, indem man beispielsweise Folgendes verwendet:

• Rsync, ein universelles Programm und Protokoll zur Synchronisation des Zustands von Dateisystemen.
• Integrierte Archive-Tools (ZFS).
• Drittanbieter-Tools zum Archivieren; das bekannteste Beispiel ist tar. Es gibt auch andere, beispielsweise dar – ein Ersatz für tar, der auf moderne Systeme ausgerichtet ist.

Besonders erwähnenswert sind Softwarelösungen zur Gewährleistung der Konsistenz von Daten beim Erstellen von Sicherungskopien. Die häufigsten Optionen sind:

• Das Einhängen des Dateisystems im Nur-Lese-Modus (ReadOnly) oder das Einfrieren des Dateisystems (Freeze) – diese Methode ist nur eingeschränkt anwendbar.
• Das Erstellen von Abbilden des Zustands von Dateisystemen oder Blockgeräten (LVM, ZFS).
• Die Verwendung von Drittanbieter-Tools zur Organisation von Abbilden, selbst in den Fällen, in denen die vorherigen Punkte aus bestimmten Gründen nicht umsetzbar sind (Programme wie hotcopy).
• Die Technik des Kopierens bei Änderungen (CopyOnWrite), die jedoch meistens an das verwendete Dateisystem (BTRFS, ZFS) gebunden ist.

Für einen kleinen Server muss also ein Sicherungsschema eingerichtet werden, das folgenden Anforderungen entspricht:

• Einfach in der Handhabung – es sind keine besonderen zusätzlichen Maßnahmen erforderlich; es sind minimale Maßnahmen zum Erstellen und Wiederherstellen von Kopien erforderlich.
• Universell – funktioniert sowohl auf großen als auch auf kleinen Servern; dies ist wichtig beim Anstieg der Anzahl Server oder beim Scaling.
• Wird über den Paketmanager installiert oder in ein bis zwei Befehlen wie "Herunterladen und Entpacken".
• Stabil — es wird ein standardmäßiges oder bereits lange etabliertes Format für die Speicherung verwendet.
• Schnell in der Anwendung.

Kandidaten, die mehr oder weniger den Anforderungen entsprechen:

• rdiff-backup
• rsnapshot
• burp
• duplicati
• duplicity
• deja dup
• dar
• zbackup
• restic
• borgbackup

Als Testumgebung wird eine virtuelle Maschine (auf Basis von XenServer) mit den folgenden Eigenschaften verwendet:

• 4 Kerne 2,5 GHz,
• 16 GB RAM,
• 50 GB Hybrid-Speicher (SAN mit 20 % SSD-Caching des virtuellen Festplattengröße) als separate virtuelle Festplatte ohne Partitionierung,
• 200 Mbit/s Internetanschluss.

Als Server für den Empfang der Sicherungskopien wird nahezu dieselbe Maschine verwendet, jedoch mit einer Festplatte mit 500 GB.

Betriebssystem — Centos 7 x64: Standardpartitionierung, ein zusätzlicher Teil wird als Datenquelle verwendet.

Als Ausgangsdaten nehmen wir eine WordPress-Website mit Mediendateien von 40 GB und einer MySQL-Datenbank. Da virtuelle Server die Anforderungen stark variieren und um eine bessere Reproduzierbarkeit zu erreichen, sind hier

Ergebnisse der Server-Testung mit Hilfe von sysbench.sysbench —threads=4 —time=30 —cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (unter Verwendung von gebündeltem LuaJIT 2.1.0-beta3)
Den Test mit den folgenden Optionen ausführen:
Anzahl der Threads: 4
Zufallszahlengenerator von der aktuellen Zeit initialisieren

Grenze der Primzahlen: 20000

Arbeiterthreads werden initialisiert …

Threads gestartet!

CPU-Geschwindigkeit:
Ereignisse pro Sekunde: 836,69

Durchsatz:
Ereignisse/s (eps): 836,6908
vergangene Zeit: 30,0039 s
Gesamtanzahl der Ereignisse: 25104

Latenz (ms):
min: 2,38
avg: 4,78
max: 22,39
95. Perzentil: 10,46
Summe: 119923,64

Threads Fairness:
Ereignisse (avg/stddev): 6276,0000/13,91
Ausführungszeit (avg/stddev): 29,9809/0,01

sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=read memory run
sysbench 1.1.0-18a9f86 (unter Verwendung von gebündeltem LuaJIT 2.1.0-beta3)
Den Test mit den folgenden Optionen ausführen:
Anzahl der Threads: 4
Zufallszahlengenerator von der aktuellen Zeit initialisieren

Durchführung des Speichertests mit den folgenden Optionen:
Blockgröße: 1 KiB
Gesamtgröße: 102400 MiB
Operation: lesen
Bereich: global

Arbeiterthreads werden initialisiert …

Threads gestartet!

Gesamtoperationen: 50900446 (1696677,10 pro Sekunde)

49707,47 MiB übertragen (1656,91 MiB/s)

Durchsatz:
Ereignisse/s (eps): 1696677,1017
vergangene Zeit: 30,0001 s
Gesamtanzahl der Ereignisse: 50900446

Latenz (ms):
min: 0,00
avg: 0,00
max: 24,01
95. Perzentil: 0,00
Summe: 39106,74

Threads Fairness:
Ereignisse (avg/stddev): 12725111,5000/137775,15
Ausführungszeit (avg/stddev): 9,7767/0,10

sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=write memory run
sysbench 1.1.0-18a9f86 (unter Verwendung von gebündeltem LuaJIT 2.1.0-beta3)
Den Test mit den folgenden Optionen ausführen:
Anzahl der Threads: 4
Zufallszahlengenerator von der aktuellen Zeit initialisieren

Durchführung des Speichertests mit den folgenden Optionen:
Blockgröße: 1 KiB
Gesamtgröße: 102400 MiB
Operation: schreiben
Bereich: global

Arbeiterthreads werden initialisiert …

Threads gestartet!

Gesamtoperationen: 35910413 (1197008,62 pro Sekunde)

35068,76 MiB übertragen (1168,95 MiB/s)

Durchsatz:
Ereignisse/s (eps): 1197008,6179
vergangene Zeit: 30,0001 s
Gesamtanzahl der Ereignisse: 35910413

Latenz (ms):
min: 0,00
avg: 0,00
max: 16,90
95. Perzentil: 0,00
Summe: 43604,83

Threads Fairness:
Ereignisse (avg/stddev): 8977603,2500/233905,84
Ausführungszeit (avg/stddev): 10,9012/0,41

sysbench —threads=4 —file-test-mode=rndrw —time=60 —file-block-size=4K —file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (unter Verwendung von gebündeltem LuaJIT 2.1.0-beta3)
Den Test mit den folgenden Optionen ausführen:
Anzahl der Threads: 4
Zufallszahlengenerator von der aktuellen Zeit initialisieren

Zusätzliche Dateiflags: (keine)
128 Dateien, jeweils 8 MiB
1 GiB Gesamtdateigröße
Blockgröße 4 KiB
Anzahl der IO-Anfragen: 0
Lese-/Schreibverhältnis für kombinierten Zufalls-I/O-Test: 1,50
Periodisches FSYNC aktiviert, fsync() wird alle 100 Anfragen aufgerufen.
fsync() am Ende des Tests aufgerufen, aktiviert.
Verwendung des synchronen I/O-Modus
Durchführung des zufälligen r/w-Tests
Arbeiterthreads werden initialisiert …

Threads gestartet!

Durchsatz:
lesen: IOPS=3868,21 15,11 MiB/s (15,84 MB/s)
schreiben: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

Latenz (ms):
min: 0,00
durchschnittlich: 0.27
max: 18.01
95. Perzentile: 1.08
summe: 238469.45

Mit dieser Notiz beginnt eine große

Artikelreihe über Backups

1. Sicherung, Teil 1: Warum Backups nötig sind, Überblick über Methoden und Technologien
2. Sicherung, Teil 2: Überblick und Test von rsync-basierten Sicherungswerkzeugen
3. Datensicherung, Teil 3: Überblick und Tests von duplicity, duplicaty, deja dup
4. Sicherung, Teil 4: Überblick und Test von zbackup, restic, borgbackup
5. Backup, Teil 5: Tests von Bacula und Veeam Backup für Linux
6. Backup, Teil 6: Vergleich von Backup-Tools
7. Backup, Teil 7: Zusammenfassungen

Quelle: habr.com