Kapitel 4. Grundlagen der Sicherung und Wiederherstellung
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Nachdem ich nun definiert habe, was Backup und Archivierung sind und wie man sie sicher aufbewahrt, müssen wir uns mit einigen grundlegenden Backup- und Wiederherstellungskonzepten auseinandersetzen. Ich beginne mit dem wichtigen Konzept der Wiederherstellungstests, gefolgt von dem Konzept der Sicherungsstufen. Dann gehe ich auf viele Metriken von Backup-Systemen ein, insbesondere auf die Konzepte RTO und RPO und wie sie (mehr als alles andere) das Backup-Design bestimmen. Dann spreche ich über Backups auf Image- und Dateiebene und darüber, wie die Inhalte von Backups ausgewählt werden. Das erste und vielleicht wichtigste Grundkonzept der Datensicherung ist jedoch, dass alle Sicherungen getestet werden müssen.
Wiederherstellungstests
Es gibt kein grundlegenderes Konzept für Datensicherung und -wiederherstellung, als zu verstehen, dass der einzige Grund, warum wir Dinge sichern, der ist, sie wiederherstellen zu können. Und der einzige Weg, um herauszufinden, ob du die Dinge, die du schützen willst, wiederherstellen kannst, ist, deine Fähigkeit dazu zu testen. Regelmäßige Wiederherstellungstests sollten ein wesentlicher Bestandteil deines Sicherungssystems sein.
Regelmäßige Tests dienen nicht nur dazu, die Gültigkeit des Sicherungssystems und seiner Dokumentation zu überprüfen, sondern auch dazu, dein Personal zu schulen. Wenn sie zum ersten Mal eine große Wiederherstellung in der Produktion durchführen, ist eine solche Wiederherstellung eine viel stressigere Situation und fehleranfälliger. Wenn sie eine solche Wiederherstellung schon mehrfach durchgeführt haben, sollten sie einfach ihrer üblichen Vorgehensweise folgen können.
Du solltest regelmäßig die Wiederbeschaffung von allem und jedem, für das du verantwortlich bist, testen. Dazu gehören kleine und sehr große Dinge. Die Häufigkeit der Tests sollte sich daran orientieren, wie oft eine Wiederherstellung einer Sache stattfindet. Ein paar Mal pro Jahr mag für einen großen DR-Test angemessen sein, aber du solltest einzelne Dateien und VMs mindestens einmal pro Woche pro Person wiederherstellen.
Die Cloud hat all das viel einfacher gemacht, denn du musst nicht um die Ressourcen kämpfen, die du für die Wiederherstellung verwenden willst. Du musst nur die entsprechenden Ressourcen in der Cloud konfigurieren und dann auf diesen Ressourcen wiederherstellen. Das gilt besonders für große DR-Ressourcen; es sollte sehr einfach sein, alles, was du für einen vollständigen DR-Test brauchst, in der Cloud zu konfigurieren. Wenn du dies regelmäßig tust, wird die Durchführung in der Produktion viel einfacher. Die Tests sollten auch die Wiederherstellung gängiger Dinge in SaaS-Diensten umfassen, wie z. B. Benutzer, Ordner und einzelne Dateien oder E-Mails.
Hinweis
Ein Backup ist erst dann ein Backup, wenn es getestet wurde!
-Ben Patridge
Sicherungsebenen
In der Backup-Branche gibt es im Wesentlichen zwei große Kategorien von Backup-Levels: Entweder wird alles gesichert (Vollbackup) oder nur das, was sich geändert hat (inkrementelles Backup). Für jede dieser beiden Arten gibt es Variationen, die sich leicht unterschiedlich verhalten. Die meisten Sicherungsebenen stammen aus einer vergangenen Ära, als es noch Bänder gab, aber es lohnt sich trotzdem, ihre Definitionen durchzugehen. Anschließend erkläre ich die Ebenen, die immer noch relevant sind, in "Sind Sicherungsebenen wichtig?".
Traditionelle Vollsicherung
Ein herkömmliches vollständiges Backup kopiert alles von dem zu sichernden System auf den Backup-Server (außer allem, was du ausdrücklich ausschließen möchtest). Das bedeutet alle Dateien in einem Dateisystem (unstrukturierte Daten) oder alle Datensätze in einer Datenbank (strukturierte Daten).
Sie erfordert eine beträchtliche Menge an Ein- und Ausgaben (E/A), was sich erheblich auf die Leistung deiner Anwendung auswirken kann. Das gilt vor allem dann, wenn du so tust, als wären deine VMs physische Maschinen, und du gleichzeitig mehrere vollständige traditionelle Backups auf mehreren VMs auf demselben Hypervisor-Knoten durchführst.
Abbildung 4-1 zeigt ein typisches wöchentliches Vollbackup mit drei Arten von inkrementellen Backups, die ich im Folgenden erläutern werde.
Abbildung 4-1. Vollständige und inkrementelle Backups
Traditionelle inkrementelle Sicherung
Bei einem herkömmlichen inkrementellen Backup werden alle Dateisystemdateien oder Datenbankeinträge gesichert, die sich seit einem vorherigen Backup geändert haben. Es gibt verschiedene Arten von inkrementellen Backups und verschiedene Produkte verwenden unterschiedliche Bezeichnungen für die verschiedenen Arten. Im Folgenden versuche ich, die verschiedenen Arten zusammenzufassen.
Wenn nicht anders angegeben, handelt es sich bei inkrementellen Backups um inkrementelle Backups der gesamten Datei, d.h. das System sichert eine Datei, wenn sich die Änderungszeit geändert hat oder ihr Archivierungsbit in Windows gesetzt wurde. Auch wenn der Benutzer nur einen Block in der Datei geändert hat, wird die komplette (d. h. vollständige) Datei gesichert. Inkrementelle Backups auf Blockebene und quellseitige Deduplizierung (beide werden später in diesem Kapitel behandelt) sind die einzigen inkrementellen Backups, die sich nicht so verhalten.
Typische inkrementelle Sicherung
Ein typisches inkrementelles Backup ( ) sichert alle Daten, die sich seit dem vorherigen Backup geändert haben, unabhängig davon, um welche Art von Backup es sich dabei gehandelt hat. Unabhängig davon, ob es sich bei der vorherigen Sicherung um eine Vollsicherung oder eine andere inkrementelle Sicherung handelte, werden bei der nächsten inkrementellen Sicherung nur die Daten gesichert, die sich seit der letzten Sicherung geändert haben. Dies ist die häufigste Art der inkrementellen Sicherung. Du kannst dieses Verhalten in Abbildung 4-1 sehen.
Kumulative inkrementelle Sicherung
Eine kumulative inkrementelle Sicherung sichert alle Daten, die sich seit der letzten Vollsicherung geändert haben. Dies erfordert mehr E/A des Backup-Clients als ein typisches inkrementelles Backup und erfordert mehr Bandbreite für die Übertragung und mehr Speicherung (vorausgesetzt, du verwendest keine Deduplizierung). Der Vorteil dieser Art der Sicherung ist, dass du nur von der Vollsicherung und der letzten kumulativen inkrementellen Sicherung wiederherstellen musst. Im Vergleich dazu musst du bei der typischen inkrementellen Sicherung von der vollständigen Sicherung und jeder nachfolgenden inkrementellen Sicherung wiederherstellen. Der Vorteil dieser Art der inkrementellen Sicherung geht jedoch verloren, wenn du die Festplatte als Sicherungsziel verwendest.
In Abbildung 4-1 siehst du, dass am Samstagabend eine kumulative inkrementelle Sicherung durchgeführt wird. Dabei wird alles gesichert, was sich seit der Vollsicherung am Sonntag geändert hat. Dies geschieht unabhängig davon, in welcher Nacht sie ausgeführt wird.
Diese Art der Sicherung wird oft als differenzielle Sicherung bezeichnet, aber ich ziehe es vor, diesen Begriff nicht zu verwenden, weil einige Sicherungssoftwareprodukte diesen Begriff für etwas ganz anderes verwenden. Deshalb verwende ich den Begriff kumulative inkrementelle Sicherung.
Inkrementelle Sicherung mit Ebenen
Diese Art der inkrementellen Sicherung verwendet das Konzept der Ebenen, die jeweils durch eine Zahl angegeben werden, wobei 0 für eine Vollsicherung und 1-9 für andere inkrementelle Sicherungsebenen steht. Ein inkrementelles Backup mit einer bestimmten Nummer sichert alles, was sich seit einem vorherigen Backup eine Stufe tiefer geändert hat. Wenn du zum Beispiel ein Level 2 Backup durchführst, wird alles gesichert, was sich seit dem letzten Level 1 Backup geändert hat. Du kannst diese Stufen mischen, um verschiedene Ergebnisse zu erzielen.
Du könntest zum Beispiel am Sonntag ein Level 0 (d.h. ein vollständiges Backup) und dann jeden Tag ein Level 1 machen. Jede Level 1-Sicherung würde alle Daten enthalten, die sich seit der Level 0-Sicherung am Sonntag geändert haben. Du könntest auch am ersten Tag des Monats ein Level 0-Backup machen, jeden Sonntag ein Level 1-Backup und den Rest der Woche eine Reihe von Backups mit steigenden Leveln (z.B. 2, 3, 4, 5, 6, 7). Jede Sonntagssicherung wäre eine kumulative inkrementelle Sicherung (d.h. alle Daten, die seit der Stufe 0 geändert wurden), und die restlichen Sicherungen würden sich wie typische inkrementelle Sicherungen verhalten, genau wie in der oberen Hälfte von Abbildung 4-1.
Eine interessante Idee, die mit Ebenen arbeitet, ist der Tower of Hanoi (TOH) Sicherungsplan, der in der unteren Hälfte von Abbildung 4-1 dargestellt ist. Er basiert auf einem uralten mathematischen Progressionsrätsel mit demselben Namen. Wenn du immer noch auf Band sicherst und dir Sorgen machst, dass ein einziges Stück des Mediums die Wiederherstellung ruiniert, kann TOH dir dabei helfen.
Das Spiel besteht aus drei Pflöcken und einer Anzahl unterschiedlich großer Ringe, die auf diese Pflöcke gesteckt werden. Ein Ring darf nicht auf einen Ring mit einem kleineren Radius gesteckt werden. Ziel des Spiels ist es, alle Ringe vom ersten zum dritten Stift zu bringen und den zweiten Stift bei Bedarf als vorübergehende Speicherung zu nutzen.1
Eines der Ziele der meisten Zeitpläne für die Datensicherung ist es, geänderte Dateien auf mehr als ein Volume zu bekommen und gleichzeitig den Gesamtverbrauch des Volumes zu reduzieren. Der TOH erreicht dies besser als jeder andere Zeitplan. Wenn du eine TOH-Progression für deine Sicherungsstufen verwendest, werden die meisten geänderten Dateien zweimal gesichert - aber nur zweimal. Hier sind zwei Versionen der Progression. (Sie hängen übrigens mit der Anzahl der Ringe auf den drei Pflöcken zusammen.)
0 3 2 5 4 7 6 9 8 9
0 3 2 4 3 5 4 6 5 7 6 8 7 9 8
Diese mathematischen Progressionen sind eigentlich ziemlich einfach. Jede besteht aus zwei verschachtelten Zahlenreihen (z. B. 2 3 4 5 6 7 8 9 verschachtelt mit 3 4 5 6 7 8 9). In Tabelle 4-1 siehst du, wie das funktionieren würde.
| Sonntag | Montag | Dienstag | Mittwoch | Donnerstag | Freitag | Samstag |
|---|---|---|---|---|---|---|
| 0 | 3 | 2 | 5 | 4 | 7 | 6 |
Wie du in Tabelle 4-1 sehen kannst, beginnt sie am Sonntag mit einem Level 0 (voll). Angenommen, eine Datei wird am Montag geändert. Der Level 3 am Montag würde alles seit dem Level 0 sichern, so dass die geänderte Datei im Backup vom Montag enthalten wäre. Nehmen wir an, dass wir am Dienstag eine weitere Datei ändern. Dann muss das Level 2 Backup am Dienstagabend nach einem niedrigeren Level suchen, richtig? Der Level 3 am Montag ist nicht niedriger, also wird er auch auf den Level 0 verweisen. Die Datei, die am Montag geändert wurde, wird also ebenso wie die Datei, die am Dienstag geändert wurde, erneut gesichert. Am Mittwoch wird die Ebene 5 nur das sichern, was an diesem Tag geändert wurde, da sie auf die Ebene 2 vom Dienstag verweist. Aber am Donnerstag verweist die Ebene 4 nicht auf die Ebene 5 vom Mittwoch, sondern auf die Ebene 2 vom Dienstag.
Beachte, dass die Datei, die sich am Dienstag geändert hat, nur einmal gesichert wurde. Um dieses Problem zu umgehen, verwenden wir eine modifizierte TOH-Progression, bei der wir jede Woche auf ein Level-1-Backup zurückgehen, wie in Tabelle 4-2 dargestellt.
|
|
|
|
Wenn es dich und deine Backup-Methode nicht verwirrt,2 kann der in Tabelle 4-2 dargestellte Zeitplan sehr hilfreich sein. Jeden Sonntag erhältst du eine vollständige inkrementelle Sicherung aller Dateien, die sich seit der monatlichen Vollsicherung geändert haben. Während des Rests der Woche wird jede geänderte Datei zweimal gesichert - mit Ausnahme der Dateien vom Mittwoch. Dies schützt dich besser vor Medienausfällen als die zuvor genannten Zeitpläne. Für eine vollständige Wiederherstellung brauchst du natürlich mehr als ein Volume, aber das ist kein Problem, wenn du ein ausgeklügeltes Sicherungsprogramm mit Volume Management hast.
Inkrementelle Sicherung auf Blockebene
Bei einer inkrementellen Sicherung auf Blockebene werden nur die Bytes oder Blöcke gesichert, die sich seit der letzten Sicherung geändert haben. In diesem Zusammenhang ist ein Block ein zusammenhängender Abschnitt von Bytes, der kleiner als eine Datei ist. Der entscheidende Unterschied besteht darin, dass nachverfolgt wird, welche Bytes oder Blöcke sich geändert haben, und dieser Nachverfolgungsmechanismus bestimmt, welche dieser Blöcke, Bytes oder Bytesegmente bei einem inkrementellen Backup gesendet werden.
Dies erfordert deutlich weniger E/A und Bandbreite als der inkrementelle Ansatz mit vollständigen Dateien. Sie ist mit dem Aufkommen von Festplatten im Backup-System viel beliebter geworden, weil sie viele kleinere Backups erstellt, die bei einer Wiederherstellung alle gelesen werden müssen. In der Welt der Bänder wäre das sehr problematisch, aber wenn deine Backups auf Festplatten gespeichert sind, ist das kein großes Problem.
Der häufigste Ort, an dem heutzutage inkrementelle Backups auf Blockebene durchgeführt werden, ist die Sicherung von Hypervisoren. Der Hypervisor und seine nachfolgenden VMs unterhalten eine Bitmap, die eine Übersicht über alle Bits enthält, die sich seit einem bestimmten Zeitpunkt geändert haben. Die Sicherungssoftware kann die Bitmap einfach nach allen Bytes abfragen, die sich seit einem bestimmten Datum geändert haben, und der Hypervisor antwortet mit den Ergebnissen, nachdem er die Bitmap abgefragt hat.
Quellenseitige Deduplizierung
Quellenseitige Deduplizierung (oder nur Quellendeduplizierung, um sie von der Zieldeduplizierung zu unterscheiden) wird in Kapitel 5 ausführlicher behandelt, ist aber technisch gesehen eine Art der inkrementellen Sicherung. Genauer gesagt handelt es sich um eine Erweiterung des inkrementellen Backup-Ansatzes auf Blockebene, mit dem Unterschied, dass die neuen oder geänderten Blöcke zusätzlich verarbeitet werden, bevor sie an den Backup-Server gesendet werden. Der Deduplizierungsprozess an der Quelle versucht festzustellen, ob die "neuen" Blöcke bereits vom Backup-System gesehen wurden. Wenn ein neuer Block zum Beispiel bereits an anderer Stelle gesichert wurde, muss er nicht noch einmal gesichert werden. Das kann passieren, wenn du eine Datei sicherst, die von vielen Personen gemeinsam genutzt wird, oder wenn du das Betriebssystem sicherst, das viele Dateien mit anderen Systemen teilt. Das spart noch mehr Zeit und Bandbreite als die inkrementelle Sicherung auf Blockebene.
Synthetische Voll-Backups
Der traditionelle Grund für regelmäßige Vollsicherungen ist, dass eine typische Wiederherstellung schneller geht. Wenn du nur eine Vollsicherung (mit einem herkömmlichen Backup-Produkt) durchführen würdest, gefolgt von inkrementellen Sicherungen, würde eine Wiederherstellung sehr lange dauern. Herkömmliche Sicherungssoftware würde alle Daten aus der Vollsicherung wiederherstellen, selbst wenn einige der Daten auf dem Band durch neuere Versionen aus inkrementellen Sicherungen ersetzt worden wären. Der Wiederherstellungsprozess würde dann damit beginnen, neue oder aktualisierte Dateien aus den verschiedenen inkrementellen Backups in der Reihenfolge ihrer Erstellung wiederherzustellen.
Dieser Prozess, bei dem mehrere Wiederherstellungen durchgeführt werden, von denen einige Daten wiederherstellen, die überschrieben werden, ist gelinde gesagt ineffizient. Da die traditionellen Wiederherstellungen von Bändern erfolgten, musste auch die Zeit hinzugerechnet werden, die benötigt wurde, um jedes Band einzulegen und zu laden, die entsprechende Stelle auf dem Band zu suchen und das Band auszuwerfen, sobald es nicht mehr benötigt wurde. Dieser Vorgang kann über fünf Minuten pro Band dauern.
Das bedeutet, dass bei dieser Art von Konfiguration die Wiederherstellung umso schneller geht, je häufiger du Vollsicherungen durchführst, weil sie weniger Zeit in Anspruch nimmt. (Nur aus Sicht der Wiederherstellung wäre eine Vollsicherung jede Nacht ideal.) Deshalb war es früher üblich, einmal pro Woche eine Vollsicherung aller Systeme durchzuführen. Als die Systeme immer mehr automatisiert wurden, gingen einige Praktiker zu monatlichen oder vierteljährlichen Vollsicherungen über.
Die Durchführung eines vollständigen Backups auf einem aktiven Server oder einer VM stellt jedoch eine erhebliche Belastung für diesen Server dar. Das ist ein Anreiz für den Backup-Administrator, die Häufigkeit von Voll-Backups so weit wie möglich zu verringern, auch wenn dadurch die Wiederherstellung länger dauert. Dieses Spannungsfeld zwischen Backup- und Wiederherstellungseffizienz ist der Hauptgrund dafür, dass es synthetische Voll-Backups gibt. Eine synthetische Vollsicherung ist eine Sicherung, die sich bei der Wiederherstellung wie eine Vollsicherung verhält, aber nicht über eine typische Vollsicherung erstellt wird. Es gibt drei Hauptmethoden, um eine synthetische Vollsicherung zu erstellen.
Synthetisch voll durch Kopieren
Die erste und gängigste Methode zur Erstellung eines synthetischen Voll-Backups ist das Kopieren von verfügbaren Backups von einem Gerät auf ein anderes. Das Sicherungssystem speichert einen Katalog aller Daten, die es bei jeder Sicherung findet. Es kennt also zu jedem Zeitpunkt alle Dateien oder Blöcke - und die Versionen dieser Dateien oder Blöcke -, die sich auf einer Vollsicherung befinden würden, wenn es sie auf herkömmliche Weise erstellen würde. Es kopiert einfach jede dieser Dateien von einem Medium auf ein anderes. Diese Methode funktioniert sowohl auf Band als auch auf Festplatte, solange mehrere Geräte verfügbar sind.
Der große Vorteil dieser Methode zur Erstellung eines synthetischen Voll-Backups ist, dass dieser Prozess zu jeder Tageszeit durchgeführt werden kann, ohne dass die Backup-Clients davon betroffen sind, da die Server oder VMs, für die du das synthetische Voll-Backup erstellst, völlig unbeteiligt sind. Nach der Fertigstellung sieht das Ergebnis in der Regel genauso aus wie ein herkömmliches Voll-Backup, und nachfolgende inkrementelle Backups können auf diesem Voll-Backup basieren.
Diese Methode hat zwei Nachteile: Der erste ist, dass das Kopieren der Daten ziemlich viel Zeit in Anspruch nehmen kann, aber, wie bereits erwähnt, kannst du es jederzeit machen, sogar mitten am Tag. Der andere Nachteil ist, dass die Festplattensysteme, die als Quelle und Ziel für das Backup verwendet werden, ziemlich stark ausgelastet werden können. In der Welt der Bänder war das kein so großes Problem, weil die Quell- und Zielgeräte natürlich getrennte Geräte waren. Wenn du aber eine Appliance mit nur einem Ziel hast, ist eine synthetische Vollsicherung, die mit dieser Methode erstellt wird, das E/A-Äquivalent einer Vollwiederherstellung und einer Vollsicherung zur gleichen Zeit. Wie stark sich dies auf deine Appliance auswirkt, hängt von der Appliance ab.
Virtuell synthetisch voll
Es gibt noch einen anderen Ansatz für synthetische Vollbackups, der nur mit Ziel-Deduplizierungssystemen möglich ist (ausführlicher erklärt in Kapitel 5 und 12). In einem Ziel-Deduplizierungssystem werden alle Backups in kleine Chunks unterteilt, um zu erkennen, welche Chunks redundant sind.3 Jeder Chunk wird dann als separates Objekt in der Speicherung der Ziel-Deduplizierungs-Appliance gespeichert, was dazu führt, dass jede geänderte Datei oder jeder geänderte Block durch viele kleine Chunks repräsentiert wird, die im Ziel-Deduplizierungssystem gespeichert werden. Das bedeutet, dass die Appliance ein vollständiges Backup vortäuschen kann, indem sie ein neues Backup erstellt, das einfach auf Blöcke aus anderen Backups verweist.
Diese Methode erfordert eine Integration mit dem Backup-Produkt. Auch wenn das Deduplizierungssystem in der Lage wäre, ohne das Backup-Produkt eine Vollsicherung zu erstellen, wüsste das Backup-Produkt nichts davon und könnte es nicht für Wiederherstellungen oder als Grundlage für inkrementelle Backups verwenden. Das Backup-Produkt weist also das Ziel-Deduplizierungssystem an, ein virtuelles synthetisches Voll-Backup zu erstellen, woraufhin es fast augenblicklich ein solches erstellt. Da es keine Datenbewegungen gibt, ist diese Methode sehr effizient, aber sie kann auf bestimmte Backup-Typen beschränkt sein, z. B. VMs, Dateisystem-Backups und bestimmte unterstützte Datenbanken .
Inkrementell für immer
Die Idee einer synthetischen Vollsicherung ist es, verschiedene Möglichkeiten zu nutzen, um etwas zu erstellen, das sich wie eine Vollsicherung verhält, ohne dass tatsächlich eine weitere Vollsicherung durchgeführt werden muss. Neuere Sicherungssysteme wurden von Grund auf so entwickelt, dass sie nie wieder eine Vollsicherung benötigen, egal ob synthetisch oder nicht. Obwohl diese Idee schon früh in der Bandwelt umgesetzt wurde, hat sich die Idee der inkrementellen Sicherung für immer (auch forever incremental genannt) in der Welt der Plattensicherung durchgesetzt.
Eine echte inkrementelle Sicherung ist nur möglich, wenn du die Festplatte als primäres Ziel verwendest, da das Sicherungssystem auf alle Sicherungen gleichzeitig zugreifen muss, damit sie funktioniert. Eine weitere Änderung ist, dass Backups nicht wie bei den meisten Backup-Produkten in einem undurchsichtigen Container gespeichert werden können (z. B. tar oder ein proprietäres Backup-Format). (Bitte verwechsle den Begriff Container nicht mit Docker-Containern. Mir fällt einfach kein besseres Wort ein.) Stattdessen speichert das Sicherungssystem jeden geänderten Artikel der letzten inkrementellen Sicherung als separates Objekt, normalerweise in einem Objektspeichersystem.
Das funktioniert unabhängig davon, ob deine inkrementelle Sicherungssoftware ganze Dateien, Teile von Dateien oder Datenblöcke sichert (wie unter "Inkrementelle Sicherung auf Blockebene" beschrieben ). Deine Sicherungssoftware speichert jedes Objekt separat - auch das kleinste Objekt (z. B. eine Datei, eine Unterdatei, einen Block oder einen Chunk) - und kann so auf alle Sicherungen als eine große Sammlung zugreifen.
Bei jedem inkrementellen Backup sieht das Backup-System auch den aktuellen Status jedes Servers, jeder VM oder Anwendung, die es sichert, und weiß, wo sich alle Blöcke befinden, die den aktuellen Stand repräsentieren (d.h. das vollständige Backup). Er muss nichts weiter tun, als diese Informationen zu speichern. Wenn es Zeit für eine Wiederherstellung ist, muss er nur wissen, wo sich alle Objekte befinden, die ein vollständiges Backup darstellen, und sie an den Wiederherstellungsprozess übergeben. Das bedeutet, dass alle Backups inkrementelle Backups sind, aber jedes Backup verhält sich aus Sicht der Wiederherstellung wie ein Vollbackup, ohne dass Daten verschoben werden müssen, um das Vollbackup zu erstellen.
Bei dieser Backup-Methode wird jeden Tag ein vollständiges Backup erstellt, ohne die Nachteile eines synthetischen Vollbackups. Der einzige wirkliche Nachteil dieser Methode ist, dass sie von Anfang an in das Sicherungssystem eingebaut werden muss. Sie funktioniert nur, wenn das Backup-System von Anfang an so aufgebaut ist, dass es nie wieder nach einer Vollsicherung sucht, egal ob synthetisch oder nicht. .
Ist die Höhe der Sicherung wichtig?
Backup-Levels sind wirklich ein Rückschritt in eine vergangene Ära, und sie sind viel weniger wichtig als früher. Als ich in den frühen 90er Jahren mit der Datensicherung anfing, waren Backup-Levels sehr wichtig. Du wolltest jede Woche eine Vollsicherung und jeden Tag eine kumulative inkrementelle Sicherung (alle Änderungen seit der Vollsicherung) machen, wenn du damit durchkamst. Das bedeutete, dass man für eine Wiederherstellung zwei Bänder brauchte. Das bedeutete auch, dass sich viele der geänderten Daten auf mehreren Bändern befanden, da jede kumulative inkrementelle Sicherung oft viele der Dateien sicherte, die auf der vorherigen kumulativen inkrementellen Sicherung waren. Diese Methode war beliebt, als ich die Bänder buchstäblich von Hand in ein Laufwerk einlegen musste, wenn ich eine Wiederherstellung durchführen wollte. Du wolltest also die Anzahl der Bänder, die du aus der Bandschublade holen musstest (oder von Iron Mountain mitbringen musstest), so gering wie möglich halten, weil du sie in das Laufwerk ein- und auslagern musstest, bis die Wiederherstellung abgeschlossen war. Wer wollte das schon mit 30 Bändern tun (was du tun müsstest, wenn du monatliche Vollsicherungen machen würdest)?
Ein paar Jahre später übernahmen kommerzielle Sicherungssoftware und robotische Bandbibliotheken das Ruder. Ich musste für eine Wiederherstellung keine Bänder wechseln, aber es gab einen Nachteil bei einer Wiederherstellung, für die viele Bänder benötigt wurden. Wenn der Roboter für eine Wiederherstellung 30 Bänder ein- und auswechseln musste, verlängerte das den Prozess um etwa 45 Minuten. Das lag daran, dass es im Durchschnitt 90 Sekunden dauerte, das Band zu laden und das erste Byte der Daten zu erreichen. Ich änderte mein typisches Setup, um eine monatliche Sicherung, tägliche typische inkrementelle Sicherungen und eine wöchentliche kumulative inkrementelle Sicherung zu verwenden. Das bedeutete, dass ich im schlimmsten Fall acht Bänder für die Wiederherstellung benötigte, was etwa 12 Minuten statt 45 Minuten dauerte. Und so lief es eine ganze Zeit lang.
Für diejenigen, die nicht mehr auf Bändern sichern, sind die meisten Gründe, warum wir Backups auf verschiedenen Ebenen durchgeführt haben, nicht mehr gültig. Selbst wenn du jeden Tag eine Vollsicherung machst, verschwendest du keine Speicherung, wenn du ein gutes Deduplizierungssystem verwendest. Es müssen auch keine 30 inkrementellen Sicherungsbänder geladen werden, wenn alle Sicherungen auf der Festplatte gespeichert sind. Und schließlich gibt es neuere Sicherungssysteme, die wirklich nur eine Sicherungsstufe durchführen: die inkrementelle Sicherung auf Blockebene. Je mehr du mit Festplatten und anderen modernen Technologien arbeitest, desto weniger sollte dir der vorherige Abschnitt wichtig sein.
Metriken
Bei der Entwicklung und Wartung eines Datensicherungssystems musst du eine Reihe von Kennzahlen ermitteln und überwachen. Sie entscheiden darüber, wie du das System konzipierst und wie du feststellen kannst, ob das System das tut, was es tun soll. Die Kennzahlen bestimmen auch, wie viel Rechen- und Speicherkapazität du verbrauchst und wie viel du noch übrig hast, bevor du zusätzliche Kapazitäten kaufen musst.
Erholungsmetriken
Es gibt keine wichtigeren Kennzahlen als die, die mit der Wiederherstellung zu tun haben. Niemand interessiert sich dafür, wie lange du für die Sicherung brauchst, sondern nur dafür, wie lange die Wiederherstellung dauert. Es gibt eigentlich nur zwei Messgrößen, die darüber entscheiden, ob dein Sicherungssystem seine Aufgabe erfüllt: wie schnell du wiederherstellen kannst und wie viele Daten du bei der Wiederherstellung verlierst. Dieser Abschnitt erklärt, wie diese Kennzahlen ermittelt und gemessen werden.
Ziel für die Wiederherstellungszeit (RTO)
Das Wiederherstellungszeitziel (RTO) ist die von allen Parteien vereinbarte Zeitspanne, die eine Wiederherstellung nach einem Vorfall, der eine Wiederherstellung erfordert, dauern sollte. Die Länge einer akzeptablen RTO für ein bestimmtes Unternehmen richtet sich in der Regel nach dem Geldbetrag, den es verliert, wenn die Systeme ausfallen.
Wenn ein Unternehmen feststellt, dass es während einer Ausfallzeit pro Stunde Millionen von Dollar an Umsatz verliert, wird es in der Regel eine sehr enge RTO anstreben. Unternehmen wie z.B. Finanzdienstleister streben eine RTO an, die so nahe wie möglich bei Null liegt. Unternehmen, die längere Computerausfallzeiten tolerieren können, haben vielleicht eine RTO, die in Wochen gemessen wird. Wichtig ist, dass die RTO den Bedürfnissen des Unternehmens entspricht.
Die Berechnung einer RTO für eine staatliche Organisation oder ein gemeinnütziges Unternehmen kann etwas problematischer sein. Sie werden höchstwahrscheinlich keine Einnahmen verlieren, wenn sie für eine gewisse Zeit ausfallen. Eine Sache, die sie jedoch berechnen müssen, ist die Anzahl der Überstunden, die sie bei einem längeren Ausfall bezahlen müssen.
Es gibt keinen Grund, eine einzige RTO für das gesamte Unternehmen zu haben. Es ist völlig normal und vernünftig, ein strengeres RTO für kritischere Anwendungen und ein lockereres RTO für den Rest des Rechenzentrums zu haben.
Bei der Berechnung der RTO ist es wichtig zu verstehen, dass die Uhr beginnt, wenn der Vorfall eintritt, und endet, wenn die Anwendung vollständig online ist und der Betrieb wieder normal läuft. Zu viele Leute, die sich auf die Datensicherung konzentrieren, denken, dass die RTO die Zeit ist, die sie für die Wiederherstellung der Daten haben, aber das ist definitiv nicht der Fall. Der eigentliche Prozess des Kopierens von Daten aus den Backups in das wiederhergestellte System ist nur ein kleiner Teil der Aktivitäten, die stattfinden müssen, um eine Anwendung wiederherzustellen, die durch einen Ausfall beschädigt wurde. Es kann sein, dass eine Hardware-Bestellung aufgegeben werden muss oder dass andere vertragliche oder logistische Fragen geklärt werden müssen, bevor du mit der Wiederherstellung beginnen kannst. Außerdem kann es sein, dass nach der Wiederherstellung noch weitere Dinge passieren müssen, bevor die Anwendung wieder für die Öffentlichkeit zur Verfügung steht. Erinnere dich also bei der Festlegung deiner RTO daran, dass du dir nicht nur für die Wiederherstellung Zeit nehmen musst.
Erinnere dich daran, dass die RTO das Ziel ist. Ob du dieses Ziel erreichen kannst, ist eine andere Frage, die in "Recovery time actual und recovery point actual" erklärt wird . Aber zuerst müssen wir über das RPO, das Recovery Point Objective, sprechen.
Wiederherstellungspunkt-Ziel (RPO)
RPO ist die Menge des akzeptablen Datenverlusts nach einem großen Vorfall, gemessen in Zeit. Wenn wir uns zum Beispiel darauf einigen, dass wir Daten im Wert von einer Stunde verlieren können, haben wir uns auf einen einstündigen RPO geeinigt. Wie bei der RTO ist es völlig normal, dass es im Unternehmen mehrere RPOs gibt, je nachdem, wie kritisch die einzelnen Datensätze sind.
Die meisten Unternehmen legen sich jedoch auf Werte fest, die viel höher als eine Stunde sind, z. B. 24 Stunden oder mehr. Das liegt vor allem daran, dass du dein Sicherungssystem umso häufiger einsetzen musst, je kleiner dein RPO ist. Es hat wenig Sinn, sich auf einen RPO von einer Stunde zu einigen und dann nur einmal am Tag zu sichern. Das Beste, was du mit einem solchen System erreichen kannst, ist ein RPO von 24 Stunden, und das ist schon sehr optimistisch.
Verhandlung deines RPO und RTO
Viele Organisationen wollen vielleicht eine sehr enge RTO und RPO. Tatsächlich begann fast jedes RTO- und RPO-Gespräch, an dem ich teilgenommen habe, mit der Frage, was die Organisation für diese Werte will. Die Antwort war fast immer ein RTO und RPO von Null. Das bedeutet, dass die Geschäfts-/Betriebseinheit im Falle einer Katastrophe möchte, dass du den Betrieb ohne Ausfallzeit und ohne Datenverlust wieder aufnimmst. Das ist nicht nur technisch nicht möglich, selbst mit den besten Systemen, es wäre auch unglaublich teuer.
Daher sollte eine Antwort auf eine solche Anfrage die vorgeschlagenen Kosten für das System sein, das erforderlich ist, um diese Anfrage zu erfüllen. Wenn das Unternehmen einen RTO und RPO von 0 - oder etwas in der Nähe dieser Werte - rechtfertigen kann, sollte es in der Lage sein, dies mit einer Kalkulationstabelle zu belegen, die die potenziellen Kosten eines Ausfalls für das Unternehmen aufzeigt.
Dann kann verhandelt werden zwischen dem, was technisch machbar und bezahlbar ist (wie von der Organisation festgelegt) und dem, was derzeit mit dem Disaster Recovery System passiert. Bitte nimm nicht einfach die RTO- und RPO-Werte, die dir vorgegeben werden, und ignoriere sie dann einfach. Erfinde bitte auch keine RTO und RPO, ohne die Geschäfts-/Betriebseinheiten zu konsultieren, weil du denkst, dass sie etwas Unangemessenes fordern werden. Dieses Gespräch ist wichtig und muss geführt werden, deshalb ist ihm Kapitel 2 gewidmet.
Aktuelle Erholungszeit und aktueller Erholungspunkt
Die Metriken Recovery Point Actual (RPA) und Recovery Time Actual (RTA) werden nur gemessen, wenn eine Wiederherstellung stattfindet, egal ob real oder durch einen Test. RTO und RPO sind Ziele; RPA und RTA messen, inwieweit du diese Ziele nach einer Wiederherstellung erreicht hast. Es ist wichtig, diesen Wert zu messen und mit dem RTO und RPO zu vergleichen, um zu beurteilen, ob du dein Backup- und Wiederherstellungssystem umgestalten musst.
Die Realität ist, dass die RTA und RPA der meisten Organisationen nicht annähernd den vereinbarten RTO und RPO für die Organisation entsprechen. Es ist wichtig, sich diese Realität bewusst zu machen und sie anzuerkennen. Entweder passen wir die RTO und RPO an, oder wir gestalten das Backup-System neu. Es hat keinen Sinn, ein strenges RTO oder RPO zu haben, wenn das RTA und RPA nicht annähernd erreicht werden.
Tipp
Aufeinanderfolgende Backup-Ausfälle kommen in der realen Welt häufig vor, und das kann sich auf dein RPA auswirken. Eine Faustregel, die ich verwende, um sicherzustellen, dass sich Backup-Ausfälle nicht auf mein RPA auswirken, ist, dass ich die Backup-Häufigkeit bestimme, indem ich den RPO durch drei teile. Ein RPO von drei Tagen würde zum Beispiel eine Sicherungshäufigkeit von einem Tag erfordern. Auf diese Weise kannst du bis zu zwei aufeinanderfolgende Backup-Ausfälle haben, ohne deinen RPO zu verpassen. Wenn dein Backup-System natürlich nur in der Lage ist, tägliche Backups durchzuführen, würde das bedeuten, dass dein RPA drei Tage betragen würde, wenn du zwei aufeinanderfolgende Backup-Ausfälle hast, die nicht behoben wurden. Da es in der Praxis häufig zu aufeinanderfolgenden Backup-Ausfällen kommt, wird der typische RPO von 24 Stunden selten eingehalten, es sei denn, du bist in der Lage, öfter als einmal am Tag zu sichern.
-Stuart Liddle
Einziehungen testen
Dies ist der perfekte Zeitpunkt, um darauf hinzuweisen, dass du Wiederherstellungen testen musst. Der Grund dafür ist, dass die meisten Unternehmen nur selten die Gelegenheit haben, ihr Backup-System im Eifer des Gefechts abzufeuern; deshalb müssen sie so tun, als ob sie das regelmäßig tun. Du wirst keine Ahnung haben, wie dein Backup-System tatsächlich funktioniert, wenn du es nicht testest.
Du wirst nicht wissen, wie zuverlässig dein Backup-System ist, wenn du es nicht mit Wiederherstellungen testest. Du wirst nicht wissen, welche Ressourcen eine groß angelegte Wiederherstellung verbraucht und wie sehr sie den Rest der Umgebung belastet. Du wirst keine Ahnung haben, wie hoch deine RTA und RPA sind, wenn du nicht gelegentlich eine große Wiederherstellung durchführst und siehst, wie lange sie dauert und wie viele Daten du verlierst.
Über Erfolgsmetriken werde ich auf den nächsten Seiten sprechen. Der Sicherungserfolg ist eine wichtige Kennzahl, aber es wird immer fehlgeschlagene Sicherungen geben. Wenn dein System das tut, was es tun soll, werden häufige Wiederherstellungen einen Wiederherstellungserfolg von 100 % (oder zumindest nahe daran) aufweisen. Die Bekanntmachung dieser Kennzahl trägt dazu bei, das Vertrauen in dein Wiederherstellungssystem zu stärken.
Nachdem ich an einigen großen Wiederherstellungen teilgenommen habe, bei denen ich die Fähigkeiten des Systems nicht sehr gut kannte, kann ich dir sagen, dass die erste Frage, die dir gestellt werden wird, lautet: "Wie lange wird das dauern?" Wenn du nicht regelmäßig Testwiederherstellungen durchgeführt hast, wirst du diese Frage nicht beantworten können. Das bedeutet, dass du die ganze Zeit mit einem Knoten im Magen dasitzt und nicht weißt, was du der Geschäftsleitung sagen sollst.
Sei mit der Wiederherstellung genauso vertraut wie mit der Datensicherung. Der einzige Weg, das zu tun, ist,zu testen.
Kapazitätsmetriken
Unabhängig davon, ob du ein lokales oder ein cloudbasiertes System verwendest, musst du die verfügbare Speicherung, die Rechenleistung und das Netzwerk überwachen und dein Design und deine Einstellungen bei Bedarf anpassen. Wie du in den folgenden Abschnitten sehen wirst, ist dies ein Bereich, in dem ein Cloud-basiertes System wirklich hervorragend ist.
Lizenz/Workload-Nutzung
Dein Backup-Produkt oder -Dienst verfügt über eine bestimmte Anzahl von Lizenzen für jede Sache, die du sicherst. Du solltest die Nutzung dieser Lizenzen verfolgen, damit du weißt, wann sie aufgebraucht sind.
Eng damit verbunden ist die Überwachung der Anzahl der Workloads, die du sicherst. Auch wenn dies nicht unbedingt zu einem Lizenzproblem führt, ist es eine weitere Kennzahl, die dir das Wachstum deines Backup-Systems zeigt.
Speicherkapazität und Nutzung
Beginnen wir mit einer sehr grundlegenden Kennzahl: Verfügt dein Backup-System über eine ausreichende Speicherung Kapazität, um deine aktuellen und zukünftigen Backup- und Recovery-Anforderungen zu erfüllen? Verfügt dein DR-System über ausreichende Speicher- und Rechenkapazitäten, um im Katastrophenfall die Aufgaben des primären Rechenzentrums zu übernehmen? Kann es dies tun und gleichzeitig Backups durchführen? Unabhängig davon, ob es sich um eine Bandbibliothek oder ein Speicher-Array handelt, hat dein Speichersystem nur eine begrenzte Kapazität, und du musst diese Kapazität und den Prozentsatz, den du im Laufe der Zeit nutzt, überwachen.
Wenn dir die Überwachung der Speichernutzung und -kapazität fehlt, kann das dazu führen, dass du gezwungen bist, Notfallentscheidungen zu treffen, die gegen die Richtlinien deines Unternehmens verstoßen. Die einzige Möglichkeit, zusätzliche Kapazität zu schaffen, ohne mehr zu kaufen, ist zum Beispiel das Löschen älterer Backups. Es wäre schade, wenn die Nichtüberwachung der Kapazität deines Speichersystems dazu führen würde, dass du die von deiner Organisation festgelegten Aufbewahrungsanforderungen nicht erfüllen kannst.
Das ist viel einfacher, wenn es sich bei der Speicherung in der Cloud um Objektspeicher handelt. Sowohl Objekt- als auch Blockspeicher haben in der Cloud eine praktisch unbegrenzte Kapazität, aber nur Objektspeicher wachsen automatisch mit deinem Bedarf. Wenn dein Backup-System erfordert, dass du blockbasierte Volumes in der Cloud erstellst, musst du trotzdem die Kapazität überwachen, weil du virtuelle Volumes erstellen und vergrößern musst, um das Wachstum deiner Daten zu bewältigen. Bei einer objektbasierten Speicherung ist dies nicht erforderlich.
Abgesehen von den Nachteilen, die das Erstellen, Verwalten, Überwachen und Erweitern dieser Volumes mit sich bringt, gibt es auch einen Unterschied in der Art der Abrechnung. Cloud-Blockspeicher werden nach der bereitgestellten Kapazität berechnet, nicht nach der genutzten Kapazität. Bei der Speicherung von Objekten hingegen wird nur die Anzahl der Gigabytes berechnet, die du in einem bestimmten Monat speicherst.
Durchsatzkapazität und Nutzung
Typische Backup-Systeme sind in der Lage, ein bestimmtes Volumen an Backups pro Tag zu verarbeiten, das normalerweise in Megabyte pro Sekunde oder Terabyte pro Stunde gemessen wird. Du solltest diese Zahl kennen und sicherstellen, dass du die Auslastung deines Backup-Systems überwachst. Wenn du das nicht tust, kann es passieren, dass die Backups länger dauern und sich in den Arbeitstag hineinziehen. Wie bei der Auslastung der Speicherkapazität kann ein Versäumnis bei der Überwachung dieser Kennzahl dich dazu zwingen, Notfallentscheidungen zu treffen, die gegen die Richtlinien deines Unternehmens verstoßen.
Die Überwachung der Durchsatzkapazität und der Nutzung des Bandes ist besonders wichtig. Wie ich im Abschnitt "Bandlaufwerke" näher erläutern werde , ist es sehr wichtig, dass der Durchsatz deiner Backups dem Durchsatz deines Bandlaufwerks bei der Datenübertragung entspricht. Das heißt, der Durchsatz, den du deinem Bandlaufwerk zur Verfügung stellst, sollte über der Mindestgeschwindigkeit des Bandlaufwerks liegen. Wenn du das nicht tust, kann das Gerät ausfallen und die Sicherung nicht funktionieren. Informiere dich in der Dokumentation des Laufwerks und im Supportsystem des Herstellers über die zulässige Mindestgeschwindigkeit und versuche, ihr so nahe wie möglich zu kommen. Es ist unwahrscheinlich, dass du dich der Höchstgeschwindigkeit des Bandlaufwerks näherst, aber auch das solltest du im Auge behalten.
Dies ist ein Bereich, in dem die Cloud sowohl einen Vorteil als auch einen Nachteil bietet. Der Vorteil ist, dass der Durchsatz in der Cloud praktisch unbegrenzt ist (wie bei der Cloud-basierten Speicherung von Objekten), vorausgesetzt, das von dir genutzte Cloud-basierte Produkt oder der Dienst kann die ihm zur Verfügung stehende Bandbreite skalieren. Wenn ihr Design zum Beispiel eine Standard-Backup-Software verwendet, die in einer VM in der Cloud läuft, bist du auf den Durchsatz dieser VM beschränkt und musst die Art der VM aufrüsten (weil verschiedene VM-Typen unterschiedliche Bandbreiten erhalten). Irgendwann stößt du jedoch an die Grenzen dessen, was deine Backup-Software mit einer VM leisten kann, und musst weitere VMs hinzufügen, um zusätzliche Bandbreite zu erhalten. Einige Systeme können die Bandbreite automatisch erhöhen, wenn dein Bedarf wächst.
Ein Nachteil bei der Nutzung der Cloud als Backup-Ziel ist, dass die Bandbreite deiner Website nicht unbegrenzt ist und auch die Anzahl der Stunden pro Tag nicht. Selbst bei einer Replikation auf Byte-Ebene oder einer quellseitigen Deduplizierung (wird später in diesem Kapitel erklärt) besteht die Möglichkeit, dass du die Upload-Bandbreite deiner Website überschreitest. In diesem Fall musst du die Bandbreite erhöhen oder möglicherweise das Design oder den Anbieter wechseln. (Die Bandbreite, die von verschiedenen Anbietern benötigt wird, ist nicht die gleiche.)
Rechnerkapazität und Nutzung
Die Leistungsfähigkeit deines Sicherungssystems hängt auch von der Leistungsfähigkeit des dahinter stehenden Computersystems ab. Wenn die Verarbeitungskapazität der Backup-Server oder der Datenbank hinter dem Backup-System nicht mithalten kann, kann das auch deine Backups verlangsamen und dazu führen, dass sie in den Arbeitstag hineinrutschen. Du solltest auch die Leistung deines Backup-Systems überwachen, um festzustellen, inwieweit dies der Fall ist.
Auch hier kann die Cloud helfen - wenn dein Backup-System für die Cloud ausgelegt ist. In diesem Fall kann es automatisch die Menge an Rechenleistung skalieren, die für die Erledigung der Aufgabe erforderlich ist. Manche können die Rechenleistung sogar im Laufe des Tages hoch- und runterfahren und so die Gesamtbetriebskosten senken, indem sie die Anzahl der verwendeten VMs, Container oder serverlosen Prozesse reduzieren.
Leider verwenden viele Sicherungssysteme und -dienste in der Cloud die gleiche Software, die du auch in deinem Rechenzentrum einsetzen würdest. Da das Konzept des automatischen Hinzufügens zusätzlicher Rechenleistung in der Cloud entstanden ist, verfügen die für das Rechenzentrum entwickelten Sicherungssoftwareprodukte nicht über dieses Konzept. Das bedeutet, dass du, wenn dir die Rechenleistung im Backend ausgeht, manuell zusätzliche Rechenleistung und die dazugehörigen Lizenzen hinzufügen musst.
Backup-Fenster
Ein herkömmliches Backup-System hat einen erheblichen Einfluss auf die Leistung deiner Primärsysteme während der Sicherung. Herkömmliche Backup-Systeme führen eine Reihe von vollständigen und inkrementellen Backups durch, die die zu sichernden Systeme stark beanspruchen können. Natürlich fordern die vollständigen Backups ihren Tribut, weil dabei alles gesichert wird. Inkrementelle Backups sind auch dann eine Herausforderung, wenn es sich um so genannte full-file incrementals handelt, d.h. das System sichert die gesamte Datei, auch wenn sich nur ein Byte geändert hat. Es ändert das Änderungsbit in Linux oder das Archivbit in Windows, und die ganze Datei wird gesichert. Da das typische Backup die Leistung der gesicherten Systeme stark beeinträchtigen kann, solltet ihr euch im Voraus auf eine bestimmte Zeitspanne einigen, die ihr als Backup-Fenster bezeichnen könnt.
Damals war ein typisches Backup-Fenster für mich von Montag bis Donnerstag 18 Uhr bis 6 Uhr morgens und von Freitag 18 Uhr bis Montag 6 Uhr morgens. Das galt für eine typische Arbeitsumgebung, in der die meisten Leute nicht am Wochenende arbeiteten und weniger Leute die Systeme nachts nutzten.
Wenn du ein Backup-Fenster hast, musst du überwachen, wie sehr du es füllst. Wenn du fast das gesamte Fenster mit Backups füllst, ist es entweder an der Zeit, das Fenster neu zu bewerten oder das Backup-System neu zu gestalten.
Ich bin auch der Meinung, dass du deinen Backup-Produkten ein Zeitfenster zuweisen solltest und sie nur innerhalb dieses Fensters die Planung übernehmen lässt. Manche Leute versuchen, ihr Backup-System zu überfordern, indem sie mit ihrem externen Zeitplannungsprogramm Tausende von einzelnen Backups planen. Ich habe noch nie erlebt, dass ein externes Zeitplannungsprogramm so effizient mit den Backup-Ressourcen umgehen kann wie das integrierte Zeitplannungsprogramm. Ich denke, er ist effizienter und viel weniger mühsam. Aber ich bin mir sicher, dass jemand, der das hier liest, ganz anderer Meinung ist.
Unternehmen, die Backup-Techniken verwenden, die in die Kategorie inkrementell für immer fallen (z. B. kontinuierliche Datensicherung [CDP], Near-CDP, inkrementelle Backups auf Blockebene oder quellseitige Deduplizierungs-Backups, die alle an anderer Stelle in diesem Buch erläutert werden), müssen sich in der Regel keine Gedanken über ein Backup-Fenster machen. Das liegt daran, dass diese Backups in der Regel nur sehr kurz laufen (ein paar Minuten) und nur eine kleine Datenmenge übertragen (ein paar Megabyte). Diese Methoden wirken sich in der Regel nur sehr gering auf die Leistung der Primärsysteme aus, oder zumindest weniger als gelegentliche Vollsicherungen und tägliche inkrementelle Volldateisicherungen. Aus diesem Grund führen Kunden, die solche Systeme nutzen, in der Regel den ganzen Tag über Backups durch, also einmal pro Stunde oder sogar alle fünf Minuten. Ein echtes CDP-System läuft kontinuierlich und überträgt jedes neue Byte, sobald es geschrieben wird. (Technisch gesehen handelt es sich nicht um ein kontinuierliches Datensicherungssystem, wenn es nicht ununterbrochen läuft. Das sage ich nur.)
Sicherung und Wiederherstellung - Erfolg und Misserfolg
Jemand sollte darüber Buch führen, wie viele Backups und Wiederherstellungen du durchführst und wie viel Prozent davon erfolgreich sind. Obwohl du in beiden Fällen 100 % anstreben solltest, ist das sehr unwahrscheinlich, vor allem beim Backup. Du solltest diese Kennzahl aber auf jeden Fall im Auge behalten und sie im Laufe der Zeit beobachten. Auch wenn das Backup-System selten perfekt sein wird, kannst du mit der Zeit feststellen, ob es besser oder schlechter wird.
Es ist auch wichtig, dass du dich mit fehlgeschlagenen Sicherungen oder Wiederherstellungen befasst. Wenn ein Backup oder eine Wiederherstellung erfolgreich wiederholt wird, kannst du zumindest den fehlgeschlagenen Vorgang von deiner Liste der Probleme streichen. Trotzdem ist es wichtig, diese Fehler zu verfolgen, um Trends zu erkennen.
Rückhaltung
Obwohl es sich technisch gesehen nicht um eine Kennzahl handelt, gehört die Aufbewahrung zu den Dingen, die in deinem Sicherungs- und Archivierungssystem überwacht werden. Du solltest sicherstellen, dass die festgelegten Aufbewahrungsrichtlinien eingehalten werden.
Wie RTO und RPO sollten auch die Aufbewahrungseinstellungen deines Datensicherungssystems von der Organisation festgelegt werden. Niemand in der IT-Abteilung sollte festlegen, wie lange Backups oder Archive aufbewahrt werden sollen; dies sollte durch gesetzliche, organisatorische und behördliche Anforderungen bestimmt werden.
Ein weiterer Punkt, der bei der Diskussion über die Aufbewahrung von Daten zu beachten ist, ist die Frage, wie lange die Daten auf den einzelnen Ebenen der Speicherung aufbewahrt werden sollten. Vorbei sind die Zeiten, in denen alle Backups und Archive auf Band gespeichert wurden. Heutzutage werden die meisten Sicherungen nicht auf Bändern, sondern auf Festplatten gespeichert. Festplatten sind aus Leistungs- und Kostengesichtspunkten in verschiedenen Kategorien zu finden. In der Aufbewahrungsfrist sollte auch festgelegt werden, wie lange die Dinge auf jeder Ebene aufbewahrt werden sollen.
Sobald du deine Aufbewahrungsrichtlinien festgelegt hast, solltest du auch überprüfen, ob sich dein Datensicherungssystem an die festgelegten Richtlinien hält. (Ich beziehe mich hier auf die Richtlinien des Unternehmens, nicht auf die Einstellungen des Sicherungssystems.) Lege deine Aufbewahrungsrichtlinien fest und dokumentiere sie. Überprüfe dann regelmäßig deine Sicherungs- und Archivierungssysteme, um sicherzustellen, dass die darin festgelegten Aufbewahrungsrichtlinien mit den Richtlinien übereinstimmen, die du für dein Unternehmen festgelegt hast. Passe sie bei Bedarf an und erstatte Bericht.
Metriken verwenden
Eine der Möglichkeiten, wie du das Vertrauen in dein Backup-System erhöhen kannst, ist die Dokumentation und Veröffentlichung aller hier genannten Kennzahlen. Lass dein Management wissen, inwieweit dein Backup-System wie geplant funktioniert. Lass sie wissen, wie viele Sicherungen und Wiederherstellungen du durchführst, wie gut sie funktionieren und wie lange es dauern wird, bis sie zusätzliche Kapazitäten kaufen müssen. Stelle vor allem sicher, dass sie wissen, ob dein Sicherungs- und Wiederherstellungssystem in der Lage ist, die vereinbarten RTO und RPO einzuhalten. Wenn du dein RTA und RPA versteckst, nützt es niemandem, wenn es zu einem Ausfall kommt.
Ich erinnere mich, dass ich die RTO- und RPO-Werte unseres Unternehmens kannte und wusste, dass unsere RTA- und RPA-Werte bei weitem nicht so hoch waren. Wir hatten eine RTO von vier Stunden und ich konnte in dieser Zeit kaum Bänder von unserem Tresoranbieter zurückbekommen. Die Wiederherstellung eines kompletten Servers dauerte in der Regel länger als vier Stunden, und ich wusste, dass die Wiederherstellung erst beginnen konnte, wenn wir die beschädigte Hardware ersetzt hatten. Ich erinnere mich, dass wir alle über diese Zahlen nur gelacht haben. Mach das nicht. Abbildung 4-2 verdeutlicht dies perfekt.
Abbildung 4-2. Sei kein Curtis
Sei die Person im Raum, die mutig genug ist, um in einer Sitzung die Hand zu heben und darauf hinzuweisen, dass die RTO und RPO nicht annähernd die RTA und RPA sind. Dränge auf eine Änderung der Ziele oder des Systems. Du gewinnst in jedem Fall.
Da wir gerade von Meetings sprechen, möchte ich mit ein paar Mythen über Backup und Archivierung aufräumen, die du wahrscheinlich in diesen Meetings hören wirst. Ich hoffe, dass du damit in der Lage bist, in Echtzeit auf sie zu reagieren.
Mythen über Sicherung und Archivierung
Es gibt viele Mythen im Bereich der Datensicherung und Archivierung. Über jeden der Mythen in diesem Abschnitt habe ich schon unzählige Male mit Menschen persönlich und noch mehr Menschen im Internet diskutiert. Die Leute sind von einer bestimmten Idee überzeugt und oft scheint keine Anzahl von Fakten ihre Meinung zu ändern, aber dies ist meine Antwort auf diese Mythen:
- Du brauchst kein RAID zu sichern.
- Redundante Plattensysteme machen ein Backup nicht überflüssig. Man sollte meinen, dass diese Frage nicht diskutiert werden muss, aber sie taucht viel häufiger auf, als du vielleicht denkst. RAID in all seinen Formen und Ausbaustufen sowie RAID-ähnliche Technologien wie Erasure Coding schützen nur vor dem Ausfall physischer Geräte. Verschiedene RAID-Levels schützen vor verschiedenen Arten von Geräteausfällen, aber letztendlich wurde RAID entwickelt, um Redundanz in der Hardware selbst zu gewährleisten. Es wurde nie entwickelt, um die Datensicherung zu ersetzen, und zwar aus einem sehr wichtigen Grund: RAID schützt das Volume, nicht das Dateisystem auf dem Volume. Wenn du eine Datei löschst, Ransomware eindringt und die Datei verschlüsselt wird oder du eine Tabelle in einer Datenbank löschst, die du nicht löschen wolltest, kann RAID nichts für dich tun. Aus diesem Grund sicherst du deine Daten auf einem RAID-Verbund, egal auf welcher Ebene.
Hinweis
Ein Freund von mir benutzte NT4 Workstation auf einem RAID1-Array, hatte aber keine Backups, weil es RAID1 und damit "sicher" war. Er war Datenbankadministrator (DBA) und semiprofessioneller Fotograf mit vielen Tausenden von Fotos auf derselben Partition wie das Betriebssystem. Ein Patch für das Betriebssystem beschädigte sein Dateisystem aufgrund einer Treiberinkompatibilität, aber seine Festplatten waren in Ordnung. Durch diesen Mythos hat er alle seine Fotos verloren. Ich versuchte, ihm bei der Wiederherstellung zu helfen, aber die Tools, die ich zur Verfügung hatte, halfen ihm nicht.
-Kurt Buff
- Du musst die replizierten Daten nicht sichern.
- Die Antwort darauf ist eigentlich dieselbe wie im Abschnitt über RAID. Die Replikation, egal wie oft du sie durchführst, repliziert alles, nicht nur die guten Dinge. Wenn mit den Daten auf deinem replizierten Volume etwas Schlimmes passiert, kopiert die Replikation diese Daten einfach an einen anderen Ort. Ich mache oft den Witz, dass die Replikation deinen Fehler nicht behebt oder den Virus stoppt; sie macht deinen Fehler oder den Virus nur noch effizienter. Er wird deinen Fehler oder Virus überall dort replizieren, wo du es ihm befohlen hast. Heutzutage kommt dies bei Multinode- und Sharded-Datenbanken wie Cassandra und MongoDB zum Tragen. Einige DBAs dieser Produkte haben erwähnt, dass jeder Shard auf mindestens drei Knoten repliziert wird und daher in der Lage sein sollte, mehrere Knotenausfälle zu überstehen. Das ist richtig, aber was passiert, wenn du eine Tabelle fallen lässt, die du nicht fallen lassen wolltest? Alle Replikationen der Welt können das nicht verhindern. Aus diesem Grund musst du die replizierten Daten sichern.
- IaaS und PaaS brauchst du nicht zu sichern.
-
Normalerweise gerate ich nicht allzu oft mit Leuten aneinander, die meinen, sie müssten ihre öffentliche Cloud-Infrastruktur nicht sichern. Die Anbieter von IaaS und PaaS bieten dir oft die Möglichkeit, dein eigenes Backup zu erstellen, aber ich kenne keinen, der in deinem Namen ein Backup erstellt. Cloud-Ressourcen sind wunderbar und unendlich skalierbar. Viele von ihnen verfügen auch über integrierte Hochverfügbarkeitsfunktionen. Aber genau wie Replikation und RAID hat Hochverfügbarkeit nichts damit zu tun, was passiert, wenn du einen Fehler machst, angegriffen wirst oder das Rechenzentrum durch eine Explosion zu einem Krater wird.
Der wichtigste Punkt, den ich hier ansprechen möchte, ist, dass es wirklich wichtig ist, deine Cloud Backups aus deinem Cloud-Konto und der Region, in der sie erstellt wurden, herauszuholen. Ja, ich weiß, das ist schwieriger. Ja, ich weiß, dass es auf diese Weise vielleicht sogar etwas mehr kostet. Aber wenn du deine Backups in demselben Konto belässt, in dem sie erstellt wurden, und sie in derselben Region speicherst wie die Ressourcen, die du schützen willst, entspricht das nicht der 3-2-1-Regel. Lies die Sidebar "Es gibt einen Neuen", um zu erfahren, was passieren kann, wenn du das nicht tust.
- Du musst kein Backup von SaaS machen
- Über diesen Mythos streite ich mittlerweile zwei- bis dreimal pro Woche. Jeder scheint zu denken, dass Backups entweder im Service enthalten sein sollten oder bereits enthalten sind, wenn du einen Vertrag mit einem SaaS-Anbieter wie Microsoft 365 oder Google Workspace abschließt. Aber hier ist eine wirklich wichtige Tatsache: Solche Dienste sind bei den großen SaaS-Anbietern fast nie enthalten. Wenn du mir nicht glaubst, dann versuche, die Worte Backup, Recovery oder Restore in deinem Servicevertrag zu finden. Versuche auch, das Wort Backup in der Dokumentation des Produkts zu finden. Ich habe nach all diesen Begriffen gesucht und nichts gefunden, was der grundlegenden Definition von Backup entspricht, nämlich der 3-2-1-Regel. Bestenfalls bieten diese Produkte bequeme Wiederherstellungsfunktionen, die mit Versionierung, Papierkorb und Ähnlichem arbeiten und nicht vor einem katastrophalen Ausfall oder Angriff geschützt sind. Dieses Thema wird im Abschnitt "Software-as-a-Service (SaaS)" ausführlicher behandelt .
- Backups sollten für viele Jahre aufbewahrt werden
-
Kapitel 3 enthält eine solide Definition von Backup und Archiv. Backup Produkte sind in der Regel nicht für die Archivierung konzipiert. Wenn dein Backup-Produkt den Hostnamen, den Anwendungsnamen, den Verzeichnis- und Tabellennamen und ein einzelnes Datum benötigt, um eine Wiederherstellung zu starten, dann handelt es sich um ein traditionelles Backup-Produkt und nicht um ein Produkt, das für die Wiederherstellung von Daten entwickelt wurde. Wenn du nach Informationen in einem anderen Kontext suchen kannst, z. B. wer die E-Mail geschrieben hat, welche Wörter in der E-Mail oder in der Betreffzeile standen und eine Reihe von Datumsangaben - unddu musst nicht wissen, von welchem Server die E-Mail kam -,dann kann dein Sicherungsprodukt Abfragen durchführen und du kannst einen anderen Mythos lesen.
Aber die meisten von euch haben es mit einem Backup-Produkt zu tun, das nur Backups und Wiederherstellungen durchführen kann, was bedeutet, dass es nicht weiß, wie man archiviert und wiederherstellt. (Nochmal: Wenn du den Unterschied nicht kennst, solltest du unbedingt Kapitel 3 lesen, in dem dieses Thema ausführlich behandelt wird.) Wenn dein Backup-Produkt nicht weiß, wie man Daten abruft, und du deine Backups mehrere Jahre lang aufbewahrst, kannst du dir nur Ärger einhandeln. Denn wenn die Daten für dich zugänglich sind und du eine E-Discovery Anfrage erhältst, bist du gesetzlich verpflichtet, dieser Anfrage nachzukommen. Wenn du nur ein Backup-Produkt und kein Archivierungsprodukt hast, kann die Beantwortung einer einzigen E-Discovery-Anfrage mehrere Millionen Dollar kosten. Wenn du denkst, dass ich übertreibe, dann lies den Abschnitt "Backups machen wirklich teure Archive".
Die meisten Wiederherstellungen stammen aus den letzten 24 Stunden. Ich habe in meiner Laufbahn schon sehr viele Wiederherstellungen gemacht, und nur sehr wenige davon waren älter als ein paar Tage, und noch weniger waren älter als ein paar Wochen. Ich persönlich stelle die Aufbewahrungszeit des Backup-Systems gerne auf 18 Monate ein, damit eine Datei, die du nur einmal im Jahr benutzt und nicht bemerkt hast, dass sie letztes Jahr gelöscht oder beschädigt wurde, nicht verloren geht.
Danach werden die Dinge noch viel komplizierter. Die Servernamen ändern sich, die Anwendungsnamen ändern sich, und du weißt nicht einmal mehr, wo die Datei ist. Die Datei könnte auch mit der aktuellen Version der Software, die du benutzt, nicht kompatibel sein. Das gilt besonders für Datenbank-Backups.
Wenn du Daten für viele Jahre aufbewahren musst, brauchst du ein System, das dazu in der Lage ist. Wenn du zu den wenigen Unternehmen gehörst, die ein Backup-System verwenden, das wirklich sowohl Backup als auch Archivierung kann, kannst du beruhigt sein. Wenn du aber zu den vielen Unternehmen gehörst, die ihre Daten sieben Jahre lang oder - Gott bewahre - für immer aufbewahren, solltest du diese Strategie ernsthaft überdenken. Du bittest um Ärger.
- Klebeband ist tot
-
Ich persönlich habe seit mehreren Jahren kein Bandlaufwerk mehr für eine Sicherung verwendet. Ich habe seit mindestens 10 Jahren kein neues Sicherungssystem mehr entwickelt, das Bandlaufwerke als erstes Sicherungsziel verwendet, wahrscheinlich sogar noch länger. Von wenigen Ausnahmen abgesehen ist das Band für mich als anfängliches Ziel für Backups so gut wie tot, und zwar aus all den Gründen, die in "Bandlaufwerke" genannt werden.(Ich ziehe es als Ziel für eine Kopie einer Sicherung in Betracht, worauf ich in Kapitel 9 eingehe).
Ich vertrete diese Meinung nicht, weil ich das Band für unzuverlässig halte. Wie ich bereits im Abschnitt "Bandlaufwerke" erwähnt habe, bin ich der Meinung, dass Bandlaufwerke grundsätzlich nicht mit der Art und Weise kompatibel sind, wie wir heute Backups durchführen. Bänder wollen viel schneller laufen als typische Backups, und die Inkompatibilität zwischen diesen beiden Prozessen führt zu der Unzuverlässigkeit, die manche Leute den Bandlaufwerken zuschreiben.
Die Ironie dabei ist, dass Bandlaufwerke besser darin sind, Einsen und Nullen zu schreiben als Festplatten; sie sind auch besser als Festplatten darin, Einsen und Nullen länger zu speichern. Aber es ist einfach unmöglich, ein Bandlaufwerk, das 1 GB pro Sekunde schreiben will, mit einem Backup zufrieden zu stellen, das nur ein paar Dutzend Megabyte pro Sekunde braucht.
Und doch werden heute mehr Bänder verkauft als je zuvor. Riesige Bandbibliotheken werden links und rechts verkauft, und diese Bandbibliotheken speichern etwas. Wie ich schon an anderer Stelle sagte, ist das am schlechtesten gehütete Geheimnis des Cloud Computing, dass die großen Cloud-Anbieter eine Menge Bandbibliotheken kaufen. Wofür werden all diese Bänder dann verwendet?
Ich denke, die perfekte Verwendung für Bänder sind Langzeitarchive. Versuche nicht, ein inkrementelles Backup direkt auf das Band zu übertragen, denn das kann zu Problemen führen. Wenn du aber ein großes Archiv mit einigen Terabyte Daten erstellst und es auf der Festplatte direkt neben dem Bandlaufwerk gespeichert hast, solltest du kein Problem haben, dieses Archiv direkt auf das Band zu übertragen und das Bandlaufwerk zufrieden zu stellen. Das Bandlaufwerk wird die Daten zuverlässig auf das Band schreiben und sie sehr lange aufbewahren. Du kannst drei oder mehr Kopien für so gut wie nichts erstellen und diese Kopien auch in der ganzen Welt verteilen.
Das Band ist ein unglaublich günstiges Medium. Nicht nur das Medium und die Laufwerke, die es erzeugen, sind unglaublich billig, auch der Strom und die Kühlung einer Bandbibliothek kosten viel weniger als der Strom und die Kühlung eines Plattensystems. Ein Festplattensystem würde sogar mehr kosten , selbst wenn die Festplatten selbst kostenlos wären. (Im Laufe der Zeit werden die Kosten für Strom und Kühlung der Festplattenlaufwerke die Kosten für Strom und Kühlung und die Anschaffungskosten der Bandlaufwerke aufwiegen).
Wenn du eine sehr kostengünstige Objektspeicherung in der Cloud nutzt, verbrauchst du wahrscheinlich mehr Band, als du denkst. Ich weiß es nicht genau, aber das Verhalten vieler dieser Systeme ähnelt sehr dem von Bändern. Auch wenn sich das Band aus dem Geschäft mit der Datensicherung und -wiederherstellung zurückzieht, hat es in der Langzeitspeicherung noch ein langes Leben.
Ich habe noch einen letzten Gedanken zu diesem Thema. Ich hatte vor kurzem ein Gespräch mit einem IT-Kollegen. Er erklärte mir, dass sein Rechenzentrum auf einer Karibikinsel liegt, die kein gutes Internet hat, und dass sie deshalb nicht glauben, dass Cloud-basierte Backups eine Möglichkeit sind, ihre Daten zu sichern, weil sie einfach nicht die Bandbreite dafür haben. Daher verwenden sie Festplatten-Backups, um ein Backup vor Ort zu erstellen, das dann auf ein externes Array repliziert wird, das dann auf Band kopiert und zu Iron Mountain geschickt wird. Ich sagte ihm, dass die Wahrscheinlichkeit, dass sie das Band jemals benutzen würden, gleich Null sei, und dann erinnerte er mich an einen Hurrikan, der vor nicht allzu langer Zeit die gesamte Insel verwüstet hatte. Alles, was sie hatten, waren Bänder. Wie ich schon sagte: Bänder sind nicht tot.
Nachdem diese Mythen nun aus dem Weg geräumt sind, lass uns mit den Grundlagen der Sicherung und Wiederherstellung fortfahren. Als Nächstes musst du dir Gedanken über die Einheit machen, die du sichern willst. Willst du einzelne Elemente (z. B. Dateien) oder ganze Bilder sichern?
Wir waren in der Lage, drei Wiederherstellungen gleichzeitig durchzuführen. Jede Wiederherstellung dauerte sehr lange und musste von jemandem durchgeführt werden, der wirklich wusste, was er tat. (Ein Team von Beratern, das eigens für diese Aufgabe eingestellt wurde, arbeitete mehrere Monate lang 24 Stunden am Tag daran. Es kostete den Kunden 2 Millionen Dollar an Beratungskosten.
Backups auf Item- versus Image-Ebene
Es gibt zwei sehr unterschiedliche Arten, einen Server zu sichern: die Sicherung auf Elementebene und die Sicherung auf Bildebene. Die Elementebene wird normalerweise als Dateiebene bezeichnet, obwohl du nicht immer Dateien sicherst. (Es kann sich auch um Objekte handeln.) Die Image-Ebene wird derzeit am häufigsten für die Sicherung von virtualisierten Umgebungen verwendet. Beide Varianten haben ihre eigenen Vor- und Nachteile.
Sicherung auf Artikelebene
Ein Backup auf Artikelebene sichert diskrete Sammlungen von Informationen, die als einzelne Artikel angesprochen werden, und die häufigste Art von Artikel ist eine Datei. Wenn dieser Abschnitt vor einigen Jahren geschrieben worden wäre, hätte man dies wahrscheinlich als Sicherung auf Dateiebene bezeichnet.
Die andere Art von Gegenständen, die in ein Backup auf Artikelebene einbezogen werden können, ist ein Objekt in einem Objektspeichersystem. In vielen Umgebungen sind Objekte mit Dateien vergleichbar. Die meisten Unternehmen, die die Objektspeicherung nutzen, verwenden sie einfach, um Dateien zu speichern, aber da sie in einem Objektspeichersystem gespeichert werden, sind sie keine Dateien, da Dateien in einem Dateisystem gespeichert werden. Der Inhalt ist oft derselbe, aber sie bekommen einen anderen Namen, weil sie anders gespeichert werden.
Normalerweise führst du eine Sicherung auf Elementebene durch, wenn du einen Backup-Agenten auf dem Server oder der VM selbst einsetzt. Der Backup-Agent entscheidet, welche Dateien gesichert werden sollen, indem er sich zunächst das Dateisystem ansieht, z. B. C:\Users oder /Users. Wenn du ein vollständiges Backup durchführst, sichert er alle Dateien im Dateisystem. Wenn du ein inkrementelles Backup durchführst, werden die Dateien gesichert, die sich seit dem letzten Backup geändert haben. Du führst auch eine Sicherung auf Objektebene durch, wenn du dein Objektspeichersystem wie Amazon S3, Azure Blob oder Google Cloud Storage sicherst. Ob du Objektspeicher sichern sollst, erfährst du in "Objektspeicherung in der Cloud".
Der Vorteil eines Backups auf Artikelebene ist, dass es sehr einfach zu verstehen ist. Installiere einen Backup-Agenten an der richtigen Stelle und er wird dein Datei- oder Objektspeichersystem untersuchen, alle Artikel finden und sie zum richtigen Zeitpunkt sichern.
Backups auf Image-Ebene
Ein Backup auf Image-Ebene ist das Ergebnis eines Backups eines physischen oder virtuellen Geräts auf der Blockebene und erstellt ein Abbild des gesamten Laufwerks. Aus diesem Grund werden Backups auf Image-Ebene auch als Backups auf Laufwerksebene, Volume-Ebene oder VM-Ebene bezeichnet. Auf dem Laufwerk kann eine Vielzahl von Informationen gespeichert sein, z. B. ein Standard-Dateisystem, eine Blockspeicherung für eine Datenbank oder sogar das Boot-Volume für eine physische oder virtuelle Maschine. Bei einem Backup auf Image-Ebene werden die Bausteine des Dateisystems gesichert und nicht die Dateien selbst.
Vor dem Aufkommen der Virtualisierung waren Backups auf Image-Ebene selten, weil das Sichern des physischen Laufwerks viel schwieriger war und das Dateisystem während der Sicherung der Blöcke ausgehängt werden musste. Andernfalls riskierte man ein verunreinigtes Backup, bei dem einige Blöcke von einem Zeitpunkt und einige Blöcke von einem anderen Zeitpunkt stammten. Die Technologie des virtuellen Snapshots, wie sie in den Windows Volume Shadow Services (VSS) oder den VMware-Snapshots zu finden ist, löste dieses grundlegende Problem.
Die Sicherung auf Volume-Ebene wurde viel beliebter, als VMs auf den Plan traten. Mit Backups auf Image-Ebene kannst du ein Backup einer VM auf der Hypervisor-Ebene durchführen. Dabei läuft deine Backup-Software außerhalb der VM und sieht die VM als ein oder mehrere Images (z.B. VMDK-Dateien in VMware).
Die Sicherung auf Image-Ebene hat eine Reihe von Vorteilen. Erstens ermöglicht sie schnellere Backups und viel schnellere Wiederherstellungen. Backups auf Image-Ebene vermeiden den Overhead des Datei- oder Objektspeichersystems und werden direkt auf die zugrunde liegende Speicherung übertragen. Wiederherstellungen auf Image-Ebene können viel schneller sein, weil bei Backups auf Dateiebene jede Datei einzeln wiederhergestellt werden muss. Dazu muss eine Datei im Dateisystem erstellt werden, ein Prozess, der mit viel Overhead verbunden ist. Dieses Problem tritt vor allem dann auf, wenn sehr dichte Dateisysteme mit Millionen von Dateien wiederhergestellt werden müssen, weil die Erstellung der Dateien während der Wiederherstellung länger dauert als die Übertragung der Daten in die Dateien. Bei der Wiederherstellung auf Image-Ebene gibt es dieses Problem nicht, da die Daten direkt auf Blockebene auf das Laufwerk geschrieben werden.
Nachdem das Problem der sich ändernden Blöcke mit Snapshots gelöst war, sahen sich Backup-Systeme mit der zweiten großen Herausforderung von Backups auf Image-Ebene konfrontiert: inkrementelle Backups. Wenn du auf Laufwerks-, Volume- oder Image-Ebene sicherst, ist jede Datei eine Vollsicherung. Nehmen wir zum Beispiel eine virtuelle Maschine (VM), die durch eine VMDK-Datei (Virtual Machine Disk) repräsentiert wird. Wenn diese VM läuft und sich ein einzelner Block in der VM ändert, zeigt die Änderungszeit auf dem Image an, dass er sich geändert hat. Bei einem nachfolgenden Backup wird dann die gesamte VMDK-Datei gesichert, auch wenn sich nur ein paar Datenblöcke geändert haben könnten.
Diese Herausforderung wurde auch in der VM Welt durch das Changed-Block-Tracking (CBT) gelöst. Dabei handelt es sich um einen Prozess, der festhält, wann ein vorheriges Backup erstellt wurde und welche Blöcke sich seit diesem letzten Backup geändert haben. Auf diese Weise kann ein Backup auf Image-Ebene ein inkrementelles Backup auf Blockebene durchführen, indem es dieses Protokoll verwendet, um zu fragen, welche Blöcke sich geändert haben, und dann nur diese Blöcke zu kopieren.
Wiederherstellung auf Dateiebene von einer Sicherung auf Imageebene
Unter gibt es noch einen letzten Nachteil der Sicherung auf Image-Ebene, nämlich das Fehlen einer Wiederherstellung auf-Ebene. Die Kunden wollen in der Regel nicht die gesamte VM wiederherstellen, sondern nur eine oder zwei Dateien innerhalb der VM. Wie kannst du eine einzelne Datei aus einer VM wiederherstellen, wenn du die gesamte VM als ein einziges Image gesichert hast? Auch dieses Problem haben viele Anbieter von Sicherungssoftware bereits gelöst. Im Fall einer VMware-VM verstehen sie zum Beispiel das Format der VMDK-Dateien, was ihnen eine Reihe von Möglichkeiten bietet.
Eine Möglichkeit, die einige Sicherungsprodukte bieten, ist das Einhängen der ursprünglichen VMDK-Dateien als virtuelles Volume, das über den Dateiexplorer auf dem Sicherungsserver oder jedem Client, auf dem die Sicherungssoftware läuft, verfügbar gemacht werden kann. Der Kunde kann dann per Drag & Drop die gewünschte(n) Datei(en) aus diesem Image ziehen und der Backup-Software sagen, dass sie es aushängen soll. In diesem Fall wird das Image normalerweise schreibgeschützt gemountet, was diese Art der Wiederherstellung per Drag-and-Drop erleichtert. (Das VM-Image schreibgeschützt zu mounten und die VM von diesem Image aus laufen zu lassen, nennt man Instant Recovery und wird in Kapitel 9 behandelt).
Andere Sicherungssoftwareprodukte können die Abbilder im Voraus indizieren, so dass sie wissen, welche Dateien welche Blöcke im Abbild verwenden. Dadurch können diese Produkte regelmäßige Wiederherstellungen auf Dateiebene von diesen Abbildern unterstützen, ohne dass der Kunde das Abbild mounten und die Dateien manuell holen muss. Der Kunde wählt die Dateien für die Wiederherstellung wie gewohnt aus, und das Sicherungssystem erledigt im Hintergrund alles Notwendige, um die betreffenden Dateien wiederherzustellen.
Kombinieren von Backups auf Image- und Dateiebene
Die meisten Kunden von führen Backups auf Image-Ebene ihrer VMs durch und behalten dabei die Möglichkeit, sowohl inkrementelle Backups als auch Wiederherstellungen auf Elementebene durchzuführen. Sie wollen auch inkrementelle Backups auf Blockebene, die viel effizienter sind als inkrementelle Backups auf Elementebene.
Die Sicherung auf der Ebene der VM (d.h. auf Image-Ebene) bietet auch die Möglichkeit, die VM als ein einziges Image wiederherzustellen. Das macht das, was wir früher Bare-Metal-Recovery nannten, viel einfacher als es war. Du bekommst alle Bare-Metal-Wiederherstellungsfunktionen, die du brauchst, ohne dass du dich um die Probleme mit wechselnden Blöcken kümmern musst, die bei Backups auf Image-Ebene auftreten.
Wir haben sogar Backups auf Image-Ebene von physischen Windows-Servern, da die meisten Leute Windows VSS verwenden, um einen Schnappschuss von jedem Dateisystem zu erstellen, bevor es gesichert wird. So kann die Sicherungssoftware ein Backup auf Image-Ebene erstellen, ohne dass die Daten beschädigt werden.
Wenn du dich entschieden hast, was du sichern willst, musst du wissen, wie das Backup-Produkt die zu sichernden Daten auswählt. Dieser Abschnitt ist sehr wichtig, denn wenn du die falsche Methode wählst, kann das zu erheblichen Lücken in deinem Backup-System führen.
Backup-Auswahlmethoden
Um sicherzustellen, dass die Dateien, von denen du glaubst, dass sie gesichert werden, auch wirklich gesichert werden, ist es wichtig zu wissen, wie Systeme, Verzeichnisse und Datenbanken in das Backup-System einbezogen werden ( ). Niemand möchte feststellen, dass das System oder die Datenbank, die er für geschützt hält, gar nicht geschützt ist.
Allerdings gibt es einen Vorbehalt. Deine Backup-Auswahlmethoden funktionieren nur, wenn dein Backup-System die zu sichernden Systeme kennt. Das bedeutet, dass der erste Schritt auf dem Weg zu diesem Ziel darin besteht, sicherzustellen, dass die Server und Dienste, die du sichern willst, bei deinem Backup- und Recovery-System registriert sind.
Wenn du z.B. eine neue SaaS-Lösung wie Salesforce nutzt, wird das Backup-System dies nicht automatisch bemerken und die Sicherung für dich übernehmen. Wenn du vollständig mit VMware virtualisiert bist und dein Sicherungssystem mit dem vCenter verbunden ist, wird das System automatisch bemerken, wenn du der Konfiguration einen neuen Knoten hinzufügst. Wenn du jedoch Hyper-V oder eine virtuelle Kernel-Maschine (KVM) verwendest, wird das Sicherungssystem nicht automatisch bemerken, dass es einen neuen Hypervisor im Rechenzentrum gibt und mit der Sicherung beginnen. Und natürlich wird dein Sicherungssystem auch nicht bemerken, dass du einen neuen physischen Server installiert hast. Diese Auswahlmethoden sind also mit diesem Vorbehalt behaftet.
Selektive Inklusion versus selektiver Ausschluss
Es gibt zwei sehr breite Kategorien, wie Gegenstände in ein Sicherungssystem aufgenommen werden können: selektive Aufnahme und selektiver Ausschluss.
Beim selektiven Einschluss legt der Administrator individuell fest, welche Dateisysteme, Datenbanken oder Objekte das Backup-System sichern soll. Wenn ein Administrator z. B. nur das Laufwerk D:\ oder nur die Apollo-Datenbank sichern will, praktiziert er eine selektive Einbeziehung.
Beim selektiven Ausschluss, auch bekannt als automatischer Einschluss, legt ein Administrator fest, dass alles auf dem Server gesichert wird, außer dem, was ausdrücklich ausgeschlossen wurde. Ein Administrator könnte zum Beispiel alle Dateisysteme außer /tmp auf einem Linux-System oder die Verzeichnisse iTunes oder Movies eines Benutzers auf einem Windows-Laptop auswählen.
Es kommt häufig vor, dass Administratoren denken, dass sie ihre Systeme so verwalten, dass es keinen Sinn macht, ein Backup des Betriebssystems zu erstellen. Sie wissen, dass sie C:\Users auf einem Windows-Laptop, /Users auf einem MacBook oder etwas wie /data oder /home auf einem Linux-System. Sie sehen keinen Sinn darin, das Betriebssystem oder die Anwendungen zu sichern, also wählen sie manuell nur die Dateisysteme aus, die sie sichern wollen. Das Gleiche gilt für Datenbanken. Sie wollen vielleicht nicht, dass deine Testdatenbanken gesichert werden, also wählen sie selektiv aus, welche Datenbanken sie sichern wollen.
Das Problem bei der selektiven Einbeziehung sind Konfigurationsänderungen. Jedes Mal, wenn eine neue Datenbank oder ein Dateisystem mit Daten zu einem System hinzugefügt wird, muss jemand die Backup-Konfiguration ändern, sonst wird die neue Ressource nie gesichert. Aus diesem Grund ist die selektive Einbeziehung viel unsicherer als der selektive Ausschluss.
Beim selektiven Ausschluss ist der schlimmste mögliche Nebeneffekt, dass du einige wertlose Daten sicherst (vorausgesetzt, du hast vergessen, sie auszuschließen). Vergleiche das mit der schlimmstmöglichen Nebenwirkung des selektiven Einschlusses, bei dem wichtige Daten komplett vom Sicherungssystem ausgeschlossen werden. Es gibt einfach keinen Vergleich zwischen diesen beiden Möglichkeiten. Selektive Datensicherung spart zwar scheinbar Geld, weil weniger Daten gespeichert werden, aber sie ist viel riskanter.
Es ist einfach, Daten auszuschließen, von denen du weißt, dass sie wertlos sind, wie z. B. /tmp oder /temp auf einem Linux-System. Wenn du keinen Grund siehst, das Betriebssystem zu sichern, kannst du auch /, /user, /usr, /var und /opt ausschließen, obwohl ich diese Verzeichnisse sichern würde. Auf einem Windows-System könntest du C:\Windows und C:\Program Files ausschließen, wenn du das Betriebssystem und die Anwendungsprogramme wirklich nicht sichern willst.
Du solltest jedoch bedenken, welche Auswirkungen die Deduplizierung auf diese Entscheidung haben könnte. Es ist eine Sache zu wissen, dass du Hunderte oder Tausende von Dateisystemen sicherst, die keinen Wert haben, und wertvollen Speicherplatz auf deinem Festplatten-Array oder deiner Bandbibliothek verschwendest. Aber was ist, wenn das Betriebssystem, auf das du so viel Zeit verwendest, eigentlich nur einmal gespeichert wird?
Die Deduplizierung würde sicherstellen, dass nur eine Kopie des Windows- oder Linux-Betriebssystems in deinem Backup-System gespeichert wird. In Anbetracht dessen könntest du das Backup-System vielleicht einfach in der Standardkonfiguration belassen und dir keine Gedanken darüber machen, das Betriebssystem auszuschließen, denn die Kosten für dein Backup-System werden sehr gering sein.
Tag-basierte und Ordner-basierte Inklusion
Eine weitere Möglichkeit, Sicherungsdaten automatisch zum Sicherungssystem hinzuzufügen, ist die tag- und ordnerbasierte Aufnahme. Diese Methode ist in der Virtualisierungswelt sehr beliebt geworden. Jede neu erstellte VM oder Datenbank kann mit einem oder mehreren Tags versehen werden (oder in einem bestimmten Ordner abgelegt werden), mit denen die Art der VM oder Datenbank klassifiziert werden kann.
Zum Beispiel können alle neuen Datenbankserver mit dem Tag database versehen oder in den Datenbankordner gelegt werden, um anderen Prozessen anzuzeigen, dass es sich um eine datenbankbezogene VM handelt. Dies könnte bestimmten Überwachungssystemen mitteilen, dass sie überwachen sollen, ob die Datenbank verfügbar ist. Es kann auch automatisch bestimmte Sicherheitsregeln und Firewalls auf diese VM anwenden. Und in vielen Sicherungssystemen kann es auch automatisch eine datenbankbezogene Sicherungsrichtlinie auf diese VM anwenden.
Eine wichtige Sache, die du bei dieser Methode beachten solltest: Du brauchst eine Standard-Sicherungsrichtlinie. Du solltest eine Sicherungsrichtlinie erstellen, die deine Sicherungssoftware automatisch verwendet, wenn keine passenden Tags gefunden werden oder wenn sich eine VM nicht in einem bestimmten Ordner befindet. Achte dann darauf, dass du diese Standardrichtlinie für alle neu auftauchenden Systeme überprüfst, denn das bedeutet, dass die Daten auf diesen Systemen möglicherweise nicht richtig gesichert werden. Wenn deine Backup-Software bei dieser Methode keine Standard-Backup-Richtlinie unterstützt, solltest du diese Funktion besser nicht nutzen, denn es besteht das Risiko, dass neue VMs oder Datenbanken nicht gesichert werden.
Hinweis
Wir haben unseren Servererstellungsprozess automatisiert und die VMs werden durch eine SLA gesichert, die dem Ordner hinzugefügt wird, in dem die VMs abgelegt werden. Für die Datenbanksicherungen müssen wir einen Agenten hinzufügen, sie zu unserer Backup-Software hinzufügen und eine SLA hinzufügen. Das alles geschieht während der Servererstellung, wenn die DB überprüft wird. Auf diese Weise verpassen wir hoffentlich kein Backup, von dem wir nichts wussten.
-Julie Ulrich
Mitbringsel
Wenn du ein Backup-System entwickelst oder betreibst, für das du kein SLA für RTO und RPO vereinbart hast, kannst du dir nur Ärger einhandeln. Nimm dir jetzt die Zeit, eine solche Vereinbarung zu dokumentieren, und erinnere dich daran, dass sie von der Organisation und nichtvon der IT-Abteilung kommen sollte. Und wenn du eine dokumentierte RTO und RPO hast und weißt, dass deine RTA und RPA nicht annähernd so weit sind, ist es jetzt an der Zeit, etwas zu sagen.
Was die Backup-Mythen angeht, so sagen alle, dass du X, Y oder Z nicht sichern musst. Das stimmt fast nie. Wenn du ein System hast, bei dem Backup und Wiederherstellung wirklich zum Funktionsumfang gehören, solltest du dir das schriftlich geben lassen.
Was die Sicherungsstufen angeht, denke ich, dass die meisten Leute diesen ganzen Abschnitt nicht brauchen. Die meisten modernen Backup-Produkte machen inkrementelle Backups auf Blockebene und brauchen die Backup-Ebenen von früher nicht mehr.
Standardmäßig ist ein selektiver Ausschluss (d.h. eine automatische Aufnahme) möglich. Verbringe deine wertvolle Zeit mit anderen administrativen Tätigkeiten, ohne dich darum kümmern zu müssen, ob deine neue Datenbank gesichert wird. Bei der Datensicherung sollten Sicherheit und Schutz immer an erster Stelle stehen, Kosten an zweiter. Niemand ist jemals gefeuert worden, weil sein Backup-System zu viele Daten gesichert hat, aber viele Leute sind gefeuert worden, weil sie nicht genug Daten gesichert haben.
Das nächste Kapitel ist der Art und Weise gewidmet, wie die meisten Leute heute sichern: die Festplatte als Hauptziel. Ich gehe auf die verschiedenen Arten ein, wie Menschen Festplatten in ihren Sicherungssystemen verwenden, und anschließend auf die verschiedenen Arten der Wiederherstellung.
1 Eine vollständige Geschichte des Spiels und eine URL, unter der du es im Internet spielen kannst, findest du unter http://www.math.toronto.edu/mathnet/games/towers.html.
2 Das gilt immer für alle Empfehlungen in diesem Buch. Wenn es dich oder deine Backup-Methode verwirrt, ist es nicht gut! Wenn deine Backups dich verwirren, solltest du gar nicht erst versuchen, sie wiederherzustellen! Always Keep It Simple SA . . (K.I.S.S.).
3 Ein Chunk ist eine Ansammlung von Bytes. Die meisten Leute verwenden den Begriff Chunk im Gegensatz zu Block, weil Blöcke in der Regel eine feste Größe haben, während Chunks beliebig groß sein können. Einige Deduktionssysteme verwenden sogar Chunks mit variabler Größe.
Get Moderner Datenschutz now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
