In jeder technischen Prüfung, die ich mache, steht eine Frage, auf die es fast immer eine schnelle Antwort gibt: Gibt es Sicherungen? Ja, natürlich, täglich.
Die zweite Frage bringt die Pause: Wann wurde zuletzt eine zurückgespielt? Und wie lange hat das gedauert?
Diese zweite Frage ist die einzige, die zählt. Eine Sicherung, die niemand zurückgespielt hat, ist keine Sicherung, sondern eine Vermutung. Dieser Artikel beschreibt, wie eine Probe abläuft, was dabei regelmäßig gefunden wird und in welchem Rhythmus sie Sinn ergibt.
Warum „gibt es Sicherungen" nichts aussagt
Eine Sicherung ist eine Kette aus mehreren Schritten, und sie reißt an jeder Stelle still. Der Vorgang, der sie erstellt, meldet Erfolg, und was in der Datei steht, prüft niemand.
Drei Arten des stillen Versagens habe ich mehrfach gesehen, und keine davon erzeugte eine Meldung.
Die Sicherung ist leer oder unvollständig. Ein Export, dessen Zugangsdaten nicht mehr stimmten, schrieb monatelang eine Datei mit einer Fehlermeldung darin. Die Datei war da, sie hatte eine Größe, die Überwachung prüfte auf Existenz.
Die Sicherung enthält nicht alles. Ein Export mit einer Liste von Tabellen, die vor Jahren geschrieben wurde. Neue Tabellen kamen dazu, die Liste blieb. Der Fund geschieht bei der Wiederherstellung, nicht vorher.
Die Sicherung ist nicht lesbar. Verschlüsselt mit einem Schlüssel, der auf dem Server lag, der ausgefallen ist. Oder in einem Format, das eine Version braucht, die es nicht mehr gibt.
Alle drei sind Fehler in der Kette, und alle drei finden sich in einer Stunde, wenn jemand eine Wiederherstellung versucht. Ohne Versuch finden sie sich an dem Tag, an dem man sie braucht.
Was eine Probe wirklich misst
Die Probe beantwortet vier Fragen, und drei davon sind in keiner Konfiguration nachzulesen.
Lässt es sich überhaupt herstellen? Die Ja-Nein-Frage. Sie ist die wichtigste und die, an der es am häufigsten scheitert.
Wie lange dauert es? Das ist die tatsächliche Wiederanlaufzeit, und sie ist fast immer länger als die angenommene. Bei größeren Datenmengen ist das Einspielen selbst der kleinere Teil; die Zeit geht für das Beschaffen, Entpacken und die Nacharbeiten drauf.
Wie alt sind die Daten danach? Der tatsächliche Datenverlust. Eine nächtliche Sicherung um zwei Uhr heißt bei einem Ausfall um siebzehn Uhr fünfzehn Stunden Verlust. Das ist eine Zahl, die eine Geschäftsführung bewerten kann, und sie wird selten so ausgesprochen.
Funktioniert die Anwendung danach? Die Frage, die am häufigsten vergessen wird. Eine wiederhergestellte Datenbank ist noch kein laufendes System: Es fehlen Dateien, Konfiguration, Zugänge, Suchindizes.
Die letzten beiden Fragen sind der Grund, warum eine Probe nicht bei der Datenbank aufhört.
Wie die Probe abläuft
Der Ablauf ist unspektakulär und dauert bei mittlerer Größe einen halben Tag. Wichtig ist, dass er aufgeschrieben wird, während er läuft, weil genau dieses Protokoll später der Wert ist.
- Zeit notieren. Nicht überspringen. Ohne Startzeit gibt es am Ende keine Zahl, sondern ein Gefühl.
- Die Sicherung beschaffen, wie im Ernstfall. Wer sie aus einem Archivspeicher holen muss, misst hier Stunden statt Minuten, und genau diese Stunden fehlen in jeder Planung.
- In einer neuen Umgebung einspielen, nicht über das Bestehende. Eine Probe, die das Produktionssystem überschreibt, ist keine Probe, sondern ein Vorfall.
- Die Anwendung dagegen starten. Mit der wiederhergestellten Datenbank, den wiederhergestellten Dateien und einer Konfiguration, die auf die neue Umgebung zeigt.
- Fünf fachliche Wege prüfen. Anmelden, einen Datensatz suchen, einen anlegen, einen Bericht erzeugen, eine Schnittstelle aufrufen. Nicht mehr, aber diese fünf richtig.
- Zeit notieren und aufschreiben, was gefehlt hat. Das ist das Ergebnis.
Der dritte Punkt ist der, bei dem Proben unterbleiben, weil niemand eine zweite Umgebung hat. In einer Cloud-Umgebung ist das eine Frage von Minuten und ein paar Euro; im eigenen Rechenzentrum ist es der Grund, warum die Probe seit Jahren aussteht. Dann ist die kleinere Fassung besser als keine: die Datenbank auf einem Entwicklungsrechner wiederherstellen und wenigstens die Fragen eins bis drei beantworten.
Was dabei regelmäßig gefunden wird
Die Funde sind erstaunlich gleichförmig. Vier Dinge tauchen in fast jeder ersten Probe auf.
Etwas fehlt, das nicht in der Datenbank steht. Hochgeladene Dateien, ein Suchindex, Zwischenspeicher mit Inhalten, die nirgends sonst existieren. Die Datenbank wird gesichert, weil sie offensichtlich wichtig ist; das Verzeichnis mit den Kundendokumenten wird vergessen, weil es niemandem als Datenbestand erscheint.
Die Anwendung startet nicht ohne Handarbeit. Eine Konfigurationsdatei, die auf dem alten Server lag und nicht im Repository. Ein Schlüssel, der zur Entschlüsselung gespeicherter Daten nötig ist. Ein Zertifikat. Diese Dinge sind einzeln klein und zusammen der Unterschied zwischen zwei Stunden und zwei Tagen.
Es dauert länger als gedacht, und zwar an einer unerwarteten Stelle. Nicht das Einspielen der Daten, sondern der Aufbau der Indizes danach. Oder das Herunterladen aus einem Archivspeicher mit niedrigem Tarif, der Stunden Vorlauf hat.
Niemand weiß, wer es darf. Die Zugangsdaten für den Sicherungsspeicher hat eine Person, und die ist im Urlaub. Das ist kein technischer Fund und in einem Notfall der teuerste.
Jeder dieser Funde ist eine Kleinigkeit, wenn man ihn an einem ruhigen Dienstag findet. Jeder ist eine Katastrophe, wenn man ihn um drei Uhr nachts findet.
Der geprobte Wiederanlauf liefert nebenbei den Bestand, aus dem sich ein Testdatensatz formen lässt: Testdaten aus der Produktion.
Der Rhythmus, der durchzuhalten ist
Eine jährliche Übung ist besser als keine und zu selten, um Veränderungen zu bemerken. Ein monatlicher Vollversuch ist gründlich und wird nach dem dritten Mal ausgelassen.
Was sich in der Praxis hält, ist eine Staffelung nach Aufwand.
Täglich, automatisch: die Sicherung wird auf Inhalt geprüft. Nicht auf Existenz. Ein Skript sieht in die Datei, zählt die Tabellen oder die Zeilen einer Leittabelle und meldet, wenn die Zahl abweicht. Das findet die ersten beiden stillen Versager von oben.
# Reicht die Datei ueberhaupt? Pruefung auf Inhalt statt auf Groesse.
tabellen=$(zcat sicherung-$(date +%F).sql.gz | grep -c "^CREATE TABLE")
zeilen=$(zcat sicherung-$(date +%F).sql.gz | grep -c "^INSERT INTO \`bestellung\`")
if [ "$tabellen" -lt 40 ] || [ "$zeilen" -lt 1 ]; then
meldung "Sicherung verdaechtig: $tabellen Tabellen, $zeilen Bestellzeilen"
fiVierteljährlich, von Hand: die vollständige Probe. Mit Anwendung, mit den fünf Wegen, mit Zeitmessung. Ein halber Tag, ein Termin im Kalender, eine Person mit Namen.
Nach jeder größeren Änderung: die Probe erneut. Eine neue Tabelle, ein neues Verzeichnis, ein Wechsel der Datenbankversion, ein Umzug. Das ist der Punkt, an dem eine funktionierende Sicherung still aufhört zu funktionieren.
Die Zahl aus der letzten Probe gehört an eine sichtbare Stelle, mit Datum. Nicht in ein Dokument, sondern dorthin, wo die Betriebszahlen stehen. „Wiederherstellung zuletzt geprüft am 14.10.2026, Dauer 3 h 40 min" ist eine Aussage, mit der jemand planen kann.
Ein Rückweg im Ausrollen ist dasselbe Versprechen, nur auf der Betriebsseite: Blue/Green und Canary ohne Kubernetes.
Drei Sonderfälle
Verschlüsselte Sicherungen. Der Schlüssel darf nicht nur dort liegen, wo auch das System liegt, das ausfallen könnte. Das klingt selbstverständlich und ist der häufigste Konstruktionsfehler bei verschlüsselten Sicherungen. Zur Probe gehört deshalb, den Schlüssel aus seiner vorgesehenen Quelle zu holen, nicht aus dem Passwortspeicher des Prüfers.
Objektspeicher mit Versionierung. Wo Dateien in einem Objektspeicher mit Versionierung und Regeln liegen, ist die Sicherung technisch gelöst. Die Frage verschiebt sich dann auf die Löschung: Kann jemand mit Zugang alles löschen, Versionen eingeschlossen? Wenn ja, ist die Sicherung gegen Ausfall geschützt und nicht gegen einen Angriff.
Verwaltete Datenbanken. Automatische Sicherungen und Wiederherstellung auf einen Zeitpunkt sind da, und das ist ein echter Gewinn. Was bleibt, ist die Zeitfrage: Eine Wiederherstellung erzeugt eine neue Instanz, und wie lange das für die eigene Datenmenge dauert, weiß man erst, wenn man es einmal gemacht hat. Die Probe wird dadurch kürzer, nicht überflüssig.
Und was in allen drei Fällen gilt: Die Probe prüft den Weg, den jemand im Ernstfall gehen würde, nicht den bequemsten. Wer für die Übung Zugänge benutzt, die es in der Nacht nicht gäbe, hat etwas anderes geprüft.
Wenn aus dieser Probe ein geübter Ablauf werden soll, mit Wiederanlaufzeiten, die zugesagt werden können: wie ich Ausfallsicherheit in bestehenden Umgebungen aufbaue, steht auf einer eigenen Seite. Was darüber hinaus nötig ist, wenn eine ganze Region ausfällt, ist eine andere Größenordnung und steht in einem eigenen Artikel.
Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.
