Recovery-Architektur: Verfahren, Ketten und der Weg zurück

Die Sicherung läuft nachts schnell und braucht wenig Platz — und genau deshalb dauert die Wiederherstellung Tage. Dieses Modul bewertet jedes Verfahren von der Rückseite her: wie viele Bestandteile ein Restore auf einen bestimmten Zeitpunkt braucht, warum ein Defekt im zehnten Glied zwanzig Tage kostet, warum Deduplizierung beim Zurückholen nichts spart, und warum eine Speicherklasse, die nach sieben Tagen ins Tiefarchiv verschiebt, eine Zwölf-Stunden-Zusage reißt, bevor ein Byte übertragen wird.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-04

Die Architektur folgt der Rechnung, nicht dem Angebot

Die beiden vorigen Module liefern die Eingaben: eine Verlustgrenze, eine Wiederanlaufzeit, einen Umfang und einen Entwurf, der sagt, gegen welche Schadenswege geschützt wird. Dieses Modul beantwortet die nächste Frage — mit welchem Verfahren und auf welchem Medium das überhaupt einzuhalten ist.

Der übliche Ablauf ist umgekehrt: Ein Produkt wird ausgewählt, weil es empfohlen wurde oder weil es schon da ist, und danach schreibt man die Ziele so, dass sie zum Produkt passen. Das fällt jahrelang nicht auf, weil im Normalbetrieb nur die Sicherungsseite läuft. Die Rechnung wird erst beim ersten ernsten Restore aufgemacht.

Die Prüfrichtung dieses ModulsJede Eigenschaft eines Verfahrens wird hier von der Wiederherstellung her bewertet, nicht von der Sicherung. Ein Verfahren, das nachts wenig Zeit und wenig Platz braucht, kann beim Zurückholen genau deshalb teuer werden — und umgekehrt. Wer nur die Sicherungsseite betrachtet, optimiert die Hälfte, die im Ernstfall nicht zählt.

Vier Verfahren, gemessen am Restore

Die Grundverfahren sind seit Jahrzehnten dieselben; nur ihre Namen wechseln mit den Produkten. Entscheidend ist, wie viele Bestandteile beim Zurückholen zusammenkommen müssen.

Vollsicherung: Jedes Mal alles. Teuer in Zeit und Platz, im Restore aber genau ein Bestandteil — der schnellste und robusteste Weg zurück.
Differenziell: Alle Änderungen seit der letzten Vollsicherung. Der Restore braucht zwei Bestandteile: die Vollsicherung und den jüngsten differenziellen Stand.
Inkrementell: Nur die Änderungen seit dem letzten Lauf. Sehr günstig beim Schreiben; der Restore braucht die Vollsicherung und jedes Glied der Kette bis zum Zielzeitpunkt.
Synthetische Vollsicherung: Das Sicherungssystem baut aus Vollsicherung und Inkrementen im Hintergrund einen neuen vollständigen Stand. Restore wie Vollsicherung, Schreiblast wie inkrementell — dafür dauerhafte Last auf dem Sicherungsziel.

Die vierte Zeile ist der Grund, warum die Diskussion „inkrementell oder voll“ heute meist an der Sache vorbeigeht: Moderne Sicherungssysteme schreiben inkrementell und halten trotzdem vollständige Wiederherstellungspunkte vor. Was man wissen muss, ist nicht der Name des Verfahrens, sondern die Antwort auf eine einzige Frage — wie viele Bestandteile braucht der Restore auf einen bestimmten Zeitpunkt?

Wiederherstellungspunkt — Ein Zeitpunkt, auf den sich der Bestand tatsächlich zurücksetzen lässt. Nicht jeder Sicherungslauf erzeugt einen eigenständigen Punkt: Bei einer Kette ist jeder Punkt nur zusammen mit allen vorherigen Gliedern verwertbar.

Die Frage nach der Bestandteilzahl lässt sich für jedes vorhandene System in fünf Minuten beantworten und wird selten gestellt. Man wählt einen beliebigen Zeitpunkt vor vier Wochen, sucht im Sicherungssystem den zugehörigen Wiederherstellungspunkt und lässt sich anzeigen, welche Bestände dafür gelesen werden müssen. Ist die Antwort eine Zahl über zwanzig, ist die Kettenlänge eine Entwurfsentscheidung, die niemand getroffen hat — sie ist der Voreinstellung des Produkts entsprungen.

Die Kette ist die Schwachstelle

Sicherungskette — Die Folge von Beständen, die für die Wiederherstellung auf einen bestimmten Zeitpunkt vollständig und lesbar vorliegen muss. Fehlt oder bricht ein Glied, sind alle Stände nach diesem Glied nicht mehr wiederherstellbar.

Damit hat die Kettenlänge zwei Wirkungen, und beide gehen in dieselbe Richtung. Sie verlängert die Wiederanlaufzeit, weil mehr Bestandteile gelesen und angewendet werden müssen. Und sie vergrößert das Risiko, weil jedes zusätzliche Glied eine weitere Stelle ist, an der ein Defekt die gesamte jüngere Historie entwertet.

Eine Kette von 30 Inkrementen bedeutet: 31 Bestandteile müssen vorhanden, lesbar und in der richtigen Reihenfolge anwendbar sein.
Ein Defekt im zehnten Glied kostet nicht einen Tag, sondern zwanzig — alles danach hängt daran.
Deshalb ist die Länge zwischen zwei vollständigen Ständen eine Entwurfsentscheidung, keine Voreinstellung.
Und deshalb muss die Prüfung die Kette betreffen und nicht nur den letzten Lauf.

Die Prüfung, die nicht prüft, was man denktEin Beispiel dafür, wie leicht man sich hier täuscht, liefert restic: Der Befehl restic check prüft laut Dokumentation die strukturelle Stimmigkeit — Snapshots, Bäume, Indizes — und liest die eigentlichen Datenpakete ausdrücklich nicht, weil das jede Datei herunterladen müsste. Erst restic check --read-data tut das, mit entsprechender Zeit und Bandbreite; --read-data-subset=n/t prüft je Lauf einen Bruchteil, sodass über t Läufe alles abgedeckt ist. Wer „check läuft grün“ als Beweis für lesbare Daten nimmt, hat eine Aussage über die Verwaltungsdaten und keine über den Inhalt.

Deduplizierung: günstig beim Schreiben, teuer beim Lesen

Deduplizierung — Verfahren, das gleiche Datenblöcke nur einmal speichert und alle weiteren Vorkommen als Verweis ablegt. Über viele ähnliche Systeme hinweg spart das oft ein Vielfaches an Speicher und Übertragungsvolumen.

Der Gewinn ist real und macht Kopien an entfernten Orten überhaupt erst bezahlbar. Zwei Nebenwirkungen gehören aber in jede Entscheidung, und beide betreffen die Wiederherstellung.

Der Zielbestand entsteht in voller Größe: Beim Restore müssen die Verweise wieder aufgelöst werden. Was 20 TB waren, sind beim Zurückschreiben wieder 20 TB — die gesparten Bytes sind auf der Sicherungsseite gespart, nicht auf der Wiederherstellungsseite.
Gemeinsame Blöcke koppeln Wiederherstellungspunkte: Ein beschädigter Block, auf den 40 Wiederherstellungspunkte verweisen, beschädigt 40 Wiederherstellungspunkte. Der Speicher wird durch Deduplizierung nicht nur kleiner, sondern auch enger verflochten.

Daraus folgt kein Verzicht, sondern eine Konsequenz: Bei stark deduplizierten Beständen ist die regelmäßige Prüfung des tatsächlichen Inhalts wichtiger als bei unabhängigen Vollsicherungen — und eine zweite Kopie in einer anderen Domäne wird wichtiger, weil ein einzelner Speicherdefekt eine größere Reichweite hat.

Snapshots: nicht Sicherung, aber unverzichtbar

Ein Snapshot friert den Zustand eines Datenträgers oder Dateisystems zu einem Zeitpunkt ein, ohne die Daten zu kopieren. Er entsteht in Sekunden, kostet zunächst kaum Platz und wächst mit den nachfolgenden Änderungen.

Warum er keine Sicherung ist. Er liegt auf demselben Speichersystem, unter derselben Verwaltung. Der Ausfall des Systems nimmt Original und Snapshot; eine Anmeldung, die das eine löscht, löscht meist auch das andere.
Warum er trotzdem gebraucht wird. Für Bedienfehler ist er der schnellste Weg zurück, den es gibt — Minuten statt Stunden, und ohne Übertragung.
Wofür er technisch nötig ist. Er liefert den unbewegten Zustand, aus dem eine konsistente Sicherung überhaupt erst gelesen werden kann.
Was er kostet. Bei hoher Änderungsrate wächst der Platzbedarf schnell, und viele lange gehaltene Snapshots bremsen manche Speichersysteme spürbar.

Die saubere FormulierungEin Snapshot ist ein Wiederherstellungspunkt in derselben Fehlerdomäne. Er verkürzt die Wiederanlaufzeit für die häufigsten Fälle erheblich und ersetzt keine einzige Kopie außerhalb dieser Domäne. Beides gleichzeitig zu sagen, ist die ganze Wahrheit — Architekturen scheitern regelmäßig daran, dass nur eine Hälfte davon im Konzept steht.

Der Medienentscheid ist ein RTO-Entscheid

Speicherklassen für Archivdaten sind der bequemste Weg, Aufbewahrungstiefe billig zu bekommen — und der übersehene Weg, die Wiederanlaufzeit zu ruinieren. Der Grund steht in der Dokumentation und hat nichts mit Bandbreite zu tun: Archivierte Objekte lassen sich nicht einfach lesen, sie müssen erst zum Abruf angefordert werden.

S3 Glacier Flexible Retrieval: Abruf über RestoreObject. Beschleunigt 1–5 Minuten für Objekte unter 250 MB, Standard 3–5 Stunden, Massenabruf 5–12 Stunden.
S3 Glacier Deep Archive: Kein beschleunigter Abruf. Standard typischerweise 12 Stunden, Massenabruf typischerweise 48 Stunden.
Azure Blob Archive: Vor dem Lesen ist eine Rehydrierung nötig. Standardpriorität bis zu 15 Stunden für Objekte unter 10 GB, hohe Priorität über x-ms-rehydrate-priority unter einer Stunde für Objekte unter 10 GB — und laut Dokumentation ohne Garantie.
Sofort lesbare Klassen: Direkt über GET erreichbar. Deutlich teurerer Speicherpreis, dafür keine Wartezeit vor dem ersten Byte.

Die zweite Rechnung neben der ZeitArchivklassen sind beim Liegenlassen billig und beim Herausholen nicht. Abruf wird in diesen Klassen getrennt berechnet — nach Anfrage und nach abgerufener Datenmenge — und der beschleunigte Abruf ist laut AWS-Dokumentation ausdrücklich ein Aufpreisdienst. Für den Entwurf heißt das: Die monatliche Ersparnis steht einer einmaligen Rechnung im Schadensfall gegenüber, die niemand eingeplant hat. Die Größenordnung lässt sich vorab überschlagen, und sie gehört in dieselbe Vorlage wie die Wartezeit.

Die Speicherklasse, die eine Zwölf-Stunden-Zusage unmöglich macht

Szenario

Ein Dienst der Klasse B hat eine zugesagte Wiederanlaufzeit von zwölf Stunden. Zur Kostensenkung wurden die Sicherungen nach 30 Tagen in eine Tiefarchivklasse verschoben. Ein Restore wird nötig, der Zielzeitpunkt liegt sechs Wochen zurück.

Anforderungen

Die zugesagten zwölf Stunden sollen eingehalten werden.
Die Kostensenkung soll nicht vollständig zurückgenommen werden.

Schritte

Feststellen, dass der Abruf beginnt, bevor irgendetwas übertragen wird: Ein Massenabruf aus dem Tiefarchiv dauert laut Dokumentation typischerweise 48 Stunden.
Erkennen, dass die zwölf Stunden damit bereits gerissen sind, bevor ein einziges Byte die Leitung berührt — Bandbreite ist hier irrelevant.
Den Zielkonflikt richtig benennen: Die Speicherklasse bedient die Aufbewahrungstiefe, die Zusage bedient die Wiederanlaufzeit. Beide betreffen dieselben Daten, aber verschiedene Zeiträume.
Die Trennung in die Aufbewahrungsstaffel ziehen: Stände innerhalb des Zeitraums, für den die Zusage gilt, bleiben sofort lesbar; ältere Stände dürfen ins Tiefarchiv.
Für die alten Stände eine eigene, ehrliche Zusage aufschreiben — etwa „Wiederherstellung aus dem Archiv: drei Tage“ — statt sie stillschweigend unter die Zwölf-Stunden-Zusage fallen zu lassen.

Merksatz: Eine Speicherklasse ist keine Kostenentscheidung mit Nebenwirkung, sondern eine Zusage über die Wiederanlaufzeit. Die Umlagerungsregel und die Aufbewahrungsstaffel müssen dieselbe Grenze benutzen — sonst kauft man Aufbewahrungstiefe mit einer RTO, die niemand vereinbart hat.

Der Wiederherstellungsweg entscheidet, was möglich ist

Ein Verfahren liefert nicht „die Daten“, sondern bestimmte Wege zurück. Welche das sind, entscheidet darüber, ob ein Ernstfall in Minuten oder in Tagen behandelt wird — und die Wege sind nicht ineinander umrechenbar.

Einzelne Datei: Der häufigste Fall im Alltag. Setzt einen Katalog voraus, der Dateien einzeln adressierbar macht.
Anwendungsobjekt: Ein Postfach, eine Datenbank, ein Element daraus. Setzt voraus, dass das Verfahren die Anwendung kennt.
Gesamtes System: Alles auf einmal, meist als Abbild. Der Weg für den Totalverlust — und der, der die längste Zeit braucht.
Auf andere Hardware: Dasselbe System auf anderem Blech oder in einer anderen Umgebung. Die Frage, die im Ernstfall zuerst gestellt und selten vorher beantwortet wird.

Die ersten beiden Wege hängen an einem Katalog: Nur was einzeln verzeichnet ist, lässt sich einzeln zurückholen. Ein Verfahren, das ganze Datenträgerabbilder schreibt und keinen Dateiindex führt, beantwortet den häufigsten Alltagsfall — eine versehentlich gelöschte Datei — mit einer vollständigen Wiederherstellung in eine Nebenumgebung. Das funktioniert, dauert aber Stunden statt Minuten und bindet Speicherplatz in der Größe des Originals. Wer den Alltagsfall im Entwurf vergisst, bezahlt ihn wöchentlich.

Die Zeile, die am häufigsten fehltDie letzte. Ein Abbild, das nur auf identische Hardware zurückläuft, ist bei einem Totalschaden wertlos, wenn diese Hardware Teil des Schadens war und nicht binnen Stunden beschaffbar ist. Die Prüffrage lautet: Auf welches Zielsystem läuft dieses Abbild, und steht dieses Zielsystem im Ernstfall zur Verfügung? Ist die Antwort „auf den Server, der gerade abgebrannt ist“, ist der Wiederherstellungsweg nicht vollständig.

Erstbefüllung: das Problem ist der Anfang

Bei Kopien an entfernten Orten führt fast jede Planung die laufende Änderungsmenge an — täglich ein paar hundert Gigabyte, das passt durch die Leitung. Die Rechnung stimmt und beschreibt den Zustand nach der Erstbefüllung. Die Erstbefüllung selbst überträgt den gesamten Bestand einmal, und das ist bei mehreren hundert Terabyte eine Aufgabe von Wochen.

Die Rechnung ist dieselbe wie bei der Wiederanlaufzeit, nur mit anderem Vorzeichen: 200 TB über eine Leitung, die dauerhaft 200 Mbit/s für die Sicherung übrig hat, sind rund 25 MB/s und damit etwa 8 Millionen Sekunden — knapp 93 Tage. Drei Monate, in denen der Schutz zugesagt ist und noch nicht besteht. Vier Wege führen aus dieser Lage heraus, und der erste ist der unelegante.

Physischer Transport. Der Bestand wird lokal auf ein Medium geschrieben und transportiert. Alle großen Anbieter bieten dafür Verfahren an; der Umweg ist unelegant und meist um Größenordnungen schneller.
Gestaffelter Beginn. Zuerst die Dienste der obersten Klasse, dann die übrigen. Das erzeugt früh einen wirksamen Schutz statt spät einen vollständigen.
Bandbreitenbegrenzung mit Zeitfenstern. Die Erstbefüllung darf den Produktivbetrieb nicht verdrängen — was die Dauer weiter verlängert und in die Planung gehört.
Der Zeitraum bis zur Vollständigkeit ist ungeschützt. Er muss benannt sein: Solange die Erstbefüllung läuft, gilt die zugesagte Klasse noch nicht.

Prüfung gehört in die Architektur, nicht in den Betrieb daneben

Jedes bisher genannte Verfahren hat eine eigene Art, unbemerkt kaputtzugehen: die Kette an einem fehlenden Glied, der deduplizierte Bestand an einem gemeinsam genutzten Block, das Archiv an einem Medium, das seit Jahren niemand gelesen hat. Deshalb ist die Prüfung kein Betriebsdetail, sondern Bestandteil des Entwurfs.

Strukturprüfung: Sind Verwaltungsdaten, Index und Verweise stimmig? Schnell, günstig, und sagt nichts über den Inhalt.
Inhaltsprüfung: Werden die tatsächlichen Datenblöcke gelesen und ihre Prüfsummen nachgerechnet? Teuer in Zeit und Übertragung — und die einzige Prüfung, die Lesbarkeit belegt.
Stichprobe über die Zeit: Je Lauf ein Bruchteil des Bestands, sodass über mehrere Läufe alles abgedeckt ist. Der übliche Kompromiss für große Bestände.

Kurzcheck

Ein wöchentlicher Prüflauf meldet seit zwei Jahren „keine Fehler“. Er führt ausschließlich die Strukturprüfung aus. Welche Aussage ist damit belegt?

Dass Index und Verweise stimmig sind — über die Lesbarkeit der Daten sagt der Lauf nichts.
Dass der gesamte Bestand lesbar ist, weil ein Defekt die Verweise beschädigt hätte.
Dass zumindest der jüngste Wiederherstellungspunkt vollständig ist.

Treffer. Richtig. Die Strukturprüfung liest die Datenpakete nicht. Zwei Jahre grüne Läufe schließen einen unlesbaren Bestand nicht aus.

Die Entscheidungsroute

Aus den Eingaben der vorigen Module wird eine Architektur in einer festen Reihenfolge. Jeder Schritt schließt Möglichkeiten aus, statt neue zu eröffnen — deshalb lohnt sich die Reihenfolge.

Wiederherstellungswege festlegen, die der Dienst im Ernstfall braucht→Verfahren wählen, die diese Wege liefern→Kettenlänge und Abstand vollständiger Stände aus der Wiederanlaufzeit ableiten→Medien und Speicherklassen je Aufbewahrungsstufe zuordnen→Prüfart und Prüfrhythmus je Bestand festlegen

Vom Weg zurück zum Verfahren — nie umgekehrt

Was die Route nicht ersetztSie liefert einen Entwurf, der rechnerisch passt. Ob er in dieser Umgebung tatsächlich funktioniert, sagt keine Route und kein Angebot — das sagt der erste gemessene Restore. Der Entwurf hat seinen Zweck erfüllt, wenn dieser Restore keine Überraschung mehr enthält, die schon auf dem Papier sichtbar gewesen wäre.

Abgrenzung

Wie die gewählten Verfahren konkret eingerichtet, überwacht und verschlüsselt werden, ist Gegenstand des nächsten Moduls. Wie ein Restore nachgewiesen und gemessen wird, folgt danach.

NachbartracksSynchrone und asynchrone Replikation im Detail, Dateisystemgrenzen und Speicherpfade stehen in storage-file-services; die Besonderheiten virtueller Umgebungen in virtualization-private-cloud. Hier interessiert nur, welche Eigenschaft eines Verfahrens eine zugesagte Zahl einhält oder verfehlt.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität5 Primärquellen · zuletzt geprüft: 2026-09-04