Backup, Teil 1: Zweck, Übersicht über Methoden und Technologien

Warum ist es notwendig, Backups zu erstellen? Die Hardware ist äußerst zuverlässig, außerdem gibt es Clouds, die in puncto Zuverlässigkeit physischen Servern überlegen sind: Bei richtiger Konfiguration übersteht ein Cloud-Server problemlos den Ausfall eines physischen Infrastrukturservers. Aus der Perspektive der Benutzer der Dienste wird es lediglich einen kleinen, kaum spürbaren Anstieg der Servicezeit geben. Zudem erfordert die Duplizierung von Informationen oft die Zahlung für „überflüssige“ CPU-Zeit, Speicherbelastung und Netzwerktraffic.

Das perfekte Programm läuft schnell, belagert den Arbeitsspeicher nicht, hat keine Lücken und existiert nicht.

—Unbekannt

Da Programme noch immer von menschlichen Entwicklern geschrieben werden und der Testprozess oft fehlt, und zudem die Bereitstellung von Software höchst selten unter Verwendung von Best Practices erfolgt (die selbst auch Programme sind und folglich nicht perfekt), müssen Systemadministratoren oft Aufgaben lösen, die kurz und prägnant lauten: „Wiederherstellen, wie es war“, „Datenbank zur normalen Funktion zurückbringen“, „läuft langsam – zurücksetzen“ und mein persönlicher Favorit „Ich weiß nicht, was, aber repariere es.“

Neben logischen Fehlern, die aus nachlässiger Arbeit von Entwicklern, durch Zufälle oder durch unvollständiges Wissen bzw. Verständnis kleiner Details beim Programmieren entstehen — einschließlich der Bindungen und Systeme wie Betriebssysteme, Treiber und Firmware — gibt es noch weitere Fehler. Zum Beispiel verlassen sich die meisten Entwickler auf die Runtime und vergessen dabei völlig die physikalischen Gesetze, die man mit Programmen weiterhin nicht umgehen kann. Dazu gehören die angebliche unendliche Zuverlässigkeit von Datenspeichersystemen und überhaupt jeder Speicherkomponente (einschließlich RAM und CPU-Cache!), die Nullverzögerung bei der Verarbeitung auf dem Prozessor und das Fehlen von Fehlern bei der Übertragung über Netzwerke sowie bei der Verarbeitung auf dem Prozessor, und Netzwerkverzögerungen, die gleich 0 sind. Auch den berüchtigten Deadline sollte man nicht vernachlässigen; wenn man es nicht rechtzeitig schafft, ergeben sich Probleme, die komplizierter sind als die Feinheiten der Netzwerk- und Festplattenverarbeitung.

Wie gehen wir mit Problemen um, die drohen, unsere wertvollen Daten zu gefährden? Erfahrene Entwickler sind schwer zu ersetzen, und es ist ungewiss, ob man in naher Zukunft welche finden kann. Andererseits ist es bislang nur wenigen Projekten gelungen zu beweisen, dass ihre Software tatsächlich wie geplant funktioniert. Zudem ist es keineswegs garantiert, dass solche Beweise auf andere, ähnliche Projekte anwendbar sind. Solche Nachweise benötigen zudem viel Zeit und spezielle Fähigkeiten, was die Anwendung unter Berücksichtigung von Deadlines nahezu unmöglich macht. Außerdem haben wir gegenwärtig noch nicht die Fähigkeit, superschnelle, kostengünstige und äußerst zuverlässige Technologien zur Speicherung, Verarbeitung und Übertragung von Informationen zu entwickeln. Solche Technologien existieren vielleicht nur als Konzepte oder sind – normalerweise – nur in fantastischen Büchern und Filmen zu finden.

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

—Pablo Picasso.

Die besten Lösungen und überraschend einfachen Dinge entstehen oft an den Schnittstellen zwischen scheinbar inkompatiblen Begriffen, Technologien, Wissen und Wissenschaftsbereichen.

Zum Beispiel haben Vögel und Flugzeuge Flügel, doch trotz der funktionalen Ähnlichkeit – in bestimmten Betriebsmodi ähneln sich die Funktionsweisen, und technische Probleme werden ähnlich gelöst: hohle Knochen, die Verwendung langlebiger und leichter Materialien usw. – sind die Ergebnisse vollkommen unterschiedlich, obwohl sie sehr ähnlich sind. Die besten Beispiele, die wir in unserer Technik beobachten, sind auch größtenteils von der Natur inspiriert: luftdichte Fächer bei Schiffen und U-Booten – eine direkte Analogie zu ringelwürmern; der Aufbau von RAID-Arrays und die Überprüfung der Datenintegrität – die Duplizierung der DNA-Kette; sowie paarige Organe, die Unabhängigkeit der Funktionsweise verschiedener Organe vom zentralen Nervensystem (automatische Herztätigkeit) und Reflexe – autonome Systeme im Internet. Natürlich kann es problematisch sein, fertige Lösungen „eins zu eins“ zu übernehmen, aber wer weiß, vielleicht gibt es auch keine anderen Lösungen.

Wenn man wüsste, wo man fällt – hätte man sich ein wenig Polster ausgelegt!

—Belarussisches Sprichwort

Das bedeutet, dass Backups lebenswichtig sind für diejenigen, die:

• Die Möglichkeit haben möchten, ihre Systeme mit minimalen Ausfallzeiten oder sogar ohne sie wiederherzustellen.
• Handeln Sie mutig, denn im Falle eines Fehlers gibt es immer die Möglichkeit zur Rückkehr.
• Die Folgen absichtlicher Datenbeschädigung minimieren.

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 basierend auf Daten, die wir ebenfalls willkürlich wählen.

—Jean Bruyère

Unabhängig von der physikalischen Art der Speicherung kann die logische Datenablage grob in zwei Arten des Zugriffs unterteilt werden: blockbasiert und dateibasiert. Diese Unterteilung ist in letzter Zeit recht verschwommen, da es keine rein blockbasierten oder rein dateibasierten logischen Speicher gibt. Für die Einfachheit nehmen wir jedoch an, dass sie existieren.

Die blockbasierte Datenablage bedeutet, dass es ein physisches Gerät gibt, auf das Daten in festen Portionen, Blöcken, geschrieben werden. Der Zugriff auf die Blöcke erfolgt über eine bestimmte Adresse, und jedem Block ist eine eigene Adresse innerhalb des Geräts zugeordnet.

Ein Backup wird in der Regel durch das Kopieren von Datenblöcken erstellt. Um die Datenintegrität zum Zeitpunkt der Sicherung zu gewährleisten, wird das Schreiben neuer Blöcke sowie die Änderung bestehender Blöcke pausiert. Eine passende Analogie aus der realen Welt wäre ein Schrank mit gleichförmig durchnummerierten Fächern.

Datenspeicherung auf der Basis logischer Geräte steht dem Blockspeicher nahe und wird oft über diesen organisiert. Wichtige Unterschiede sind die Hierarchie der Speicherung und benutzerfreundliche Namen. Hierbei wird eine Abstraktion in Form einer Datei — einem benannten Datenbereich — und eines Verzeichnisses — einer speziellen Datei, die Beschreibungen und Zugriffe auf andere Dateien speichert — hervorgehoben. Dateien können mit zusätzlichen Metadaten versehen werden: Erstellungszeit, Zugriffflags usw. In der Regel wird wie folgt reserviert: Änderungen an Dateien werden gesucht, dann werden diese in einen anderen, strukturell gleichartigen Speicher kopiert. Die Integrität der Daten wird normalerweise durch das Fehlen von Dateien realisiert, in die gerade geschrieben wird. Die Metadaten der Dateien werden ähnlich reserviert. Eine passende Analogie wäre eine Bibliothek mit verschiedenen Abteilungen für Bücher, sowie ein Katalog mit benutzerfreundlichen Buchnamen.

In letzter Zeit wird manchmal eine weitere Variante beschrieben, mit der das Dateispeichern von Daten ursprünglich begann und die dieselben archaischen Merkmale aufweist: objektbasiertes Datenspeichern.

Object Storage unterscheidet sich von Dateispeicherungen dadurch, dass es keine höhere Verschachtelung als eine (flaches Schema) aufweist. Die Dateinamen sind zwar menschenlesbar, aber mehr für die maschinelle Verarbeitung geeignet. Bei der Datensicherung werden Objektspeicher oft ähnlich wie Dateispeicher behandelt, aber gelegentlich gibt es auch andere Optionen.

— Es gibt zwei Arten von Systemadministratoren: diejenigen, die keine Backups erstellen, und diejenigen, die es bereits tun.
— Tatsächlich gibt es drei Arten: Es gibt auch diejenigen, die überprüfen, ob die Backups wiederherstellbar sind.

—Unbekannt

Es ist auch wichtig zu verstehen, dass der Prozess der Datensicherung durch Software erfolgt, und somit die gleichen Nachteile wie bei anderen Programmen aufweist. Um (nicht auszuschließen!) die Abhängigkeit vom menschlichen Faktor sowie spezifische Merkmale zu minimieren — die einzeln nicht stark ins Gewicht fallen, aber zusammen einen spürbaren Effekt haben können — wird die sogenannte 3-2-1-Regel angewendet. Es gibt viele Möglichkeiten, diese Regel zu interpretieren, aber mir gefällt folgende Auffassung am besten: Man sollte 3 Kopien der gleichen Daten in 2 verschiedenen Formaten speichern und 1 Kopie in einem geografisch getrennten Speicherort aufbewahren.

Mit dem Speicherformat ist Folgendes gemeint:

• Wenn eine Abhängigkeit vom physischen Speicherweg besteht, ändern wir den physischen Speicherweg.
• Wenn eine Abhängigkeit vom logischen Speicherweg besteht, ändern wir den logischen Speicherweg.

Um den maximalen Effekt der 3-2-1-Regel zu erreichen, wird empfohlen, das Speicherformat auf beiden Wegen zu ändern.

In Bezug auf die Einsatzbereitschaft von Backups zur Wiederherstellung der Funktionalität unterscheidet man zwischen "hot" und "cold" Backups. Der einzige Unterschied besteht darin, dass heiße Backups sofort einsatzbereit sind, während kalte Backups für die Wiederherstellung zusätzliche Schritte wie Entschlüsselung oder Wiederherstellung aus einem Archiv erfordern.

Verwechseln Sie heiße und kalte Backups nicht mit Online- und Offline-Backups, die eine physische Isolation der Daten implizieren und im Wesentlichen ein anderes Klassifikationsmerkmal von Backup-Methoden darstellen. So kann ein Offline-Backup, das nicht direkt mit dem System verbunden ist, in dem es wiederhergestellt werden muss, sowohl heiß als auch kalt (hinsichtlich der Wiederherstellungsbereitschaft) sein. Ein Online-Backup kann direkt dort verfügbar sein, wo es wiederhergestellt werden muss, und ist meist heiß, es gibt jedoch auch kalte Backups.

Außerdem sollte man nicht vergessen, dass der Prozess der Datensicherung normalerweise nicht mit der Erstellung eines einzelnen Backups endet. Es können durchaus zahlreiche Kopien erforderlich sein. Daher ist es wichtig, zwischen vollständigen Backups, das heißt, solchen, die unabhängig von anderen Backups wiederhergestellt werden können, und differenziellen (inkrementellen, dekrementalen usw.) Kopien zu unterscheiden — letztere können nicht unabhängig wiederhergestellt werden und erfordern die Wiederherstellung einer oder mehrerer anderer Backups im Voraus.

Differenzielle inkrementelle Backups — ein Versuch, Speicherplatz für Backups zu sparen. Dabei werden nur die seit dem letzten Backup geänderten Daten gesichert.

Differenzielle dekrementale Backups werden mit demselben Ziel erstellt, jedoch auf etwas andere Weise: Es wird ein vollständiges Backup gemacht, tatsächlich gespeichert wird jedoch nur der Unterschied zwischen der neuen Kopie und der vorherigen.

Es ist wichtig, den Backup-Prozess über einen Speicher zu betrachten, der keine Duplikatspeicherung unterstützt. So werden, wenn vollständige Backups darüber geschrieben werden, tatsächlich nur die Unterschiede zwischen den Backups gespeichert. Der Wiederherstellungsprozess wird jedoch wie bei einer vollständigen Kopie ablaufen und völlig transparent sein.

Quis custodiet ipsos custodes?

(Wer bewacht die Wächter selbst? — lateinisch)

Es ist äußerst ungünstig, wenn es keine Backups gibt. Doch es ist noch schlimmer, wenn ein Backup scheinbar erstellt wurde, sich aber bei der Wiederherstellung herausstellt, dass es nicht wiederhergestellt werden kann, weil:

• Die Integrität der Originaldaten wurde verletzt.
• Der Backup-Speicher ist beschädigt.
• Die Wiederherstellung erfolgt sehr langsam, und die teilweise wiederhergestellten Daten können nicht verwendet werden.

Ein ordnungsgemäß gestalteter Backup-Prozess muss solche Hinweise berücksichtigen, insbesondere die ersten beiden.

Die Integrität der Quelldaten kann auf verschiedene Weise gewährleistet werden. Am häufigsten kommen folgende Methoden zur Anwendung: a) Erstellen von Snapshots des Dateisystems auf Blockebene, b) „Einfrieren“ des Zustands des Dateisystems, c) spezielle Blockgeräte mit Versionsspeicherung, d) sequentielles Schreiben von Dateien oder Blöcken. Zudem werden Prüfziffern verwendet, um die Daten während der Wiederherstellung zu überprüfen.

Schäden am Speicher können ebenfalls durch Prüfziffern erkannt werden. Eine zusätzliche Methode ist der Einsatz spezialisierter Geräte oder von Dateisystemen, in denen bereits geschriebene Daten nicht mehr verändert werden können, aber neue hinzugefügt werden dürfen.

Um die Wiederherstellung zu beschleunigen, wird eine Wiederherstellung mit mehreren Prozessen verwendet, vorausgesetzt, es gibt keinen Engpass durch ein langsames Netzwerk oder ein ineffizientes Speichersystem. Um das Problem teilweise wiederhergestellter Daten zu umgehen, kann der Backup-Prozess in relativ kleine Unteraufgaben aufgeteilt werden, die jeweils separat ausgeführt werden. So wird die Möglichkeit geschaffen, die Betriebsfähigkeit schrittweise mit einer Prognose der Wiederherstellungszeit wiederherzustellen. Dieses Problem liegt häufig im organisatorischen Bereich (SLA), weshalb wir nicht näher darauf eingehen werden.

Ein echter Kenner von Gewürzen ist nicht der, der sie in jedes Gericht gibt, sondern der, der niemals etwas Überflüssiges hinzufügt.

—W. Sinjawski

Die Praxis bei der verwendeten Software kann bei Systemadministratoren variieren, aber die allgemeinen Prinzipien bleiben dennoch gleich, insbesondere:

• Es wird dringend empfohlen, fertige Lösungen zu verwenden.
• Programme müssen vorhersehbar arbeiten, d.h. es sollten keine undocumented Besonderheiten oder Engpässe auftreten.
• Die Konfiguration jedes Programms sollte so einfach sein, dass man nicht ständig das Handbuch oder Spickzettel lesen muss.
• Die Lösung sollte, wenn möglich, universell sein, da die Server in ihren Hardwaremerkmalen stark variieren können.

Für die Sicherung von Blockgeräten gibt es folgende gängige Programme:

• dd, bekannt bei Veteranen der Systemadministration; dazu gehören ähnliche Programme (wie zum Beispiel dd_rescue).
• In einige Dateisysteme integrierte Dienstprogramme (Utilities), die einen Dump des Dateisystems erstellen.
• Universelle Dienstprogramme; beispielsweise partclone.
• Eigene, oft proprietäre Lösungen; wie NortonGhost und spätere Versionen.

Für Dateisysteme wird die Backup-Aufgabe teilweise mit Methoden gelöst, die für Blockgeräte anwendbar sind, jedoch kann die Aufgabe auch effizienter gelöst werden, etwa mit:

• Rsync, einem universellen Programm und Protokoll zur Synchronisierung des Zustands von Dateisystemen.
• Integrierte Backup-Lösungen (ZFS).
• Drittanbieter-Backup-Tools; der bekannteste Vertreter ist tar. Es gibt auch andere wie dar – eine modernisierte Alternative zu tar.

Besonders erwähnenswert sind Softwarelösungen zur Gewährleistung der Datenkonsistenz beim Erstellen von Backups. Zu den häufigsten Optionen gehören:

• Das Einhängen des Dateisystems im Nur-Lese-Modus (ReadOnly) oder das Einfrieren des Dateisystems (freeze) – diese Methode ist nur eingeschränkt anwendbar.
• Erstellung von Snapshots des Zustands von Dateisystemen oder Blockgeräten (LVM, ZFS).
• Einsatz von Drittanbieter-Tools zur Erstellung von Snapshots, selbst in Fällen, in denen die vorherigen Punkte aus bestimmten Gründen nicht umgesetzt werden können (Programme wie hotcopy).
• Copy-on-Write-Technik, die jedoch meist an das verwendete Dateisystem gebunden ist (BTRFS, ZFS).

Für einen kleinen Server sollte ein Backup-Schema entwickelt werden, das die folgenden Anforderungen erfüllt:

• Einfache Handhabung – es sind keine besonderen zusätzlichen Maßnahmen erforderlich, minimaler Aufwand bei der Erstellung und Wiederherstellung von Kopien.
• Universal — funktioniert sowohl auf großen als auch auf kleinen Servern; das ist wichtig beim Anstieg der Nutzerzahlen Server oder bei der Skalierung.
• Es wird mit einem Paketmanager installiert oder in ein bis zwei Befehlen wie „herunterladen und entpacken“.
• Stabil — verwendet ein standardmäßiges oder seit langem etabliertes Speicherformat.
• Schnell in der Ausführung.

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 (basierend auf XenServer) mit den folgenden Eigenschaften verwendet:

• 4 Kerne, 2,5 GHz,
• 16 GB RAM,
• 50 GB Hybrid-Speicher (Storage mit 20 % SSD-Cache im Verhältnis zur Größe der virtuellen Festplatte) als separate virtuelle Festplatte ohne Partitionierung,
• 200 Mbit/s Internetverbindung.

Als Server zur Annahme von Sicherungskopien wird praktisch dieselbe Maschine verwendet, jedoch mit einer Festplatte von 500 GB.

Betriebssystem — Centos 7 x64: Standardaufteilung, zusätzliche Partition wird als Datenquelle genutzt.

Als Ausgangsdaten nehmen wir eine WordPress-Website mit Mediendateien von 40 GB und einer MySQL-Datenbank. Da virtuellen Server unterscheiden sich erheblich in ihren Eigenschaften, und zur besseren Reproduzierbarkeit gibt es hier

Testergebnisse des Servers mit sysbench.sysbench —threads=4 —time=30 —cpu-max-prime=20000 cpu ausführen
sysbench 1.1.0-18a9f86 (unter Verwendung von LuaJIT 2.1.0-beta3)
Der Test wird mit den folgenden Optionen ausgeführt:
Anzahl der Threads: 4
Zufallszahlengenerator wird mit der aktuellen Zeit initialisiert

Grenze der Primzahlen: 20000

Arbeiter-Threads werden initialisiert…

Threads gestartet!

CPU-Geschwindigkeit:
Ereignisse pro Sekunde: 836,69

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

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

Fairness der Threads:
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 speichert testen
sysbench 1.1.0-18a9f86 (unter Verwendung von LuaJIT 2.1.0-beta3)
Der Test wird mit den folgenden Optionen ausgeführt:
Anzahl der Threads: 4
Zufallszahlengenerator wird mit der aktuellen Zeit initialisiert

Speichergeschwindigkeitstest mit den folgenden Optionen wird ausgeführt:
Blockgröße: 1KiB
Gesamtgröße: 102400MiB
Operation: lesen
Bereich: global

Arbeiter-Threads werden initialisiert…

Threads gestartet!

Gesamtoperationen: 50900446 (1696677,10 pro Sekunde)

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

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

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

Fairness der Threads:
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 speichert testen
sysbench 1.1.0-18a9f86 (unter Verwendung von LuaJIT 2.1.0-beta3)
Der Test wird mit den folgenden Optionen ausgeführt:
Anzahl der Threads: 4
Zufallszahlengenerator wird mit der aktuellen Zeit initialisiert

Speichergeschwindigkeitstest mit den folgenden Optionen wird ausgeführt:
Blockgröße: 1KiB
Gesamtgröße: 102400MiB
Operation: schreiben
Bereich: global

Arbeiter-Threads werden initialisiert…

Threads gestartet!

Gesamtoperationen: 35910413 (1197008,62 pro Sekunde)

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

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

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

Fairness der Threads:
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 LuaJIT 2.1.0-beta3)
Der Test wird mit den folgenden Optionen ausgeführt:
Anzahl der Threads: 4
Zufallszahlengenerator wird mit der aktuellen Zeit initialisiert

Zusätzliche Dateifenster-Flags: (keine)
128 Dateien, jeweils 8MiB
1GiB Gesamtdatengröße
Blockgröße 4KiB
Anzahl der IO-Anforderungen: 0
Lese-/Schreibverhältnis für den kombinierten zufälligen IO-Test: 1,50
Periodisches FSYNC aktiviert, fsync() wird alle 100 Anforderungen aufgerufen.
fsync() wird am Ende des Tests aufgerufen, aktiviert.
Synchroner I/O-Modus wird verwendet
Durchführung des zufälligen r/w-Tests
Arbeiter-Threads werden initialisiert…

Threads gestartet!

Throughput:
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
avg: 0,27
max: 18,01
95. Perzentil: 1,08
Summe: 238469,45

Mit diesem Artikel beginnt eine große

Serie von Artikeln über Backups

1. Backup, Teil 1: Warum Backup notwendig ist, Überblick über Methoden und Technologien
2. Backup, Teil 2: Überblick und Test von rsync-basierten Backup-Tools
3. Backup, Teil 3: Überblick und Test von duplicity, duplicaty, deja dup
4. Backup, Teil 4: Überblick und Test von zbackup, restic, borgbackup
5. Backup, Teil 5: Test von Bacula und Veeam Backup für Linux
6. Backup, Teil 6: Vergleich von Backup-Tools.
7. Backup, Teil 7: Fazit

Quelle: habr.com