Backup ohne Wiederherstellungstest ist keine Sicherung

Fast jeder Betrieb sichert seine Daten. Deutlich weniger prüfen, ob sich diese Sicherungen zurückspielen lassen. Der Unterschied fällt erst an dem Tag auf, an dem man sie braucht, und dann ist es die teuerste mögliche Erkenntnis.

Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung, sondern eine Vermutung. Sie belegt Speicherplatz und beruhigt. Der einzige Beleg, dass sie trägt, ist ein Wiederherstellungstest: Daten aus dem Archiv holen, in ein leeres System einspielen, nachzählen, ob alles da ist. Automatisiert dauert das Minuten.

Was bei Sicherungen typischerweise schiefgeht

Sicherungen scheitern selten spektakulär. Sie scheitern still, und meistens an einem dieser Punkte:

• Das Archiv ist unvollständig. Ein Datenbankauszug bricht nach der Hälfte ab, weil ein Zeitlimit greift. Die Datei existiert, hat eine plausible Größe und ist trotzdem unbrauchbar.
• Der Auszug ist syntaktisch kaputt. Steuerzeichen werden beim Schreiben entschärft, Sonderzeichen gehen verloren. Beim Einlesen bricht es an der ersten betroffenen Zeile ab.
• Es fehlt genau das, was man braucht. Die Datenbank ist gesichert, die hochgeladenen Dateien nicht. Oder umgekehrt.
• Niemand kommt an den Schlüssel. Verschlüsselte Sicherungen sind richtig, aber wenn die Passphrase nur auf dem Server liegt, der ausgefallen ist, ist die Verschlüsselung ein Verlust und kein Schutz.
• Die Meldung ist falsch. Ein Sicherungsskript, das aus einem harmlosen Hinweis einen Fehlschlag macht, erzeugt jede Nacht eine Warnmail. Nach der dritten liest sie niemand mehr, und dann fällt der echte Fehler auch nicht mehr auf.

Der letzte Punkt ist der unterschätzte. Fehlalarme sind gefährlicher als keine Alarme, weil sie die Aufmerksamkeit abnutzen, die man im Ernstfall braucht.

Wie ein automatischer Wiederherstellungstest aufgebaut ist

Das Prinzip ist unspektakulär und genau deshalb zuverlässig. Der Test läuft auf denselben Dateien, die auch im Ernstfall verwendet würden, und nicht auf einer Kopie aus dem laufenden System:

1. Frische, leere Zielsysteme starten. Für Datenbanken bieten sich kurzlebige Container an, etwa postgres:16-alpine und mariadb:11. Wichtig ist, dass es nicht die laufenden Datenbanken sind: ein Fehler im Test darf den Betrieb nicht berühren.
2. Die Sicherung der letzten Nacht einspielen. Nicht einen eigens erzeugten Auszug, sondern die Datei aus dem Archiv.
3. Nachzählen. Wie viele Datenbanken, wie viele Tabellen. Eine Zahl, die man mit dem Vortag vergleichen kann, findet stille Ausfälle, die ein reiner Erfolgsstatus verschweigt.
4. Jedes Dateiarchiv öffnen. Ein tar -tzf über jedes Archiv beantwortet die Frage, ob es sich überhaupt lesen lässt, in Sekunden.
5. Ergebnis maschinenlesbar ablegen. Eine Statusdatei, die die tägliche Systemprüfung ausliest. Steht dort ein Fehler, gibt es eine Alarmmail. Ist der letzte erfolgreiche Test älter als vierzig Tage, gibt es eine Warnung.

Punkt fünf ist der, der aus einem einmaligen Test eine Zusage macht. Ein Wiederherstellungstest, an den sich niemand erinnert, ist keine Absicherung.

Was ein Wiederherstellungstest nicht beantwortet

Er prüft die Lesbarkeit und Vollständigkeit der Daten. Er beantwortet ausdrücklich nicht, wie lange es dauert, nach einem Totalausfall wieder online zu sein. Dafür braucht es einen Durchlauf auf einer leeren Maschine, mit Zugangsdaten, Zertifikaten, Konfiguration und Namensauflösung, und der dauert Stunden statt Minuten.

Beides hat seinen Platz. Der tägliche Test beantwortet „sind die Daten da“, die Übung beantwortet „wie schnell sind wir zurück“. Wer nur eines von beidem hat, sollte wissen, welches.

Verschlüsselung und Schlüsselverwahrung

Sicherungen gehören verschlüsselt, spätestens sobald eine Kopie das Haus verlässt. Damit entsteht aber eine neue Abhängigkeit, die mitgedacht werden muss: Ein Wiederherstellungstest kann verschlüsselte Archive nur prüfen, wenn er an den Schlüssel kommt. Liegt der Schlüssel bewusst nicht auf dem Server, muss der Test vor der Verschlüsselung laufen, sonst prüft er nichts.

Ebenso wichtig ist der umgekehrte Fall. Schlüssel und Passphrase gehören an einen Ort, der einen Totalausfall des Servers übersteht. Ein Passwortmanager außerhalb der eigenen Infrastruktur erfüllt das, ein Zettel im Serverraum nicht.

Das Minimum, wenn du keinen eigenen Server betreibst

Dafür braucht es weder Skripte noch Werkzeuge. Nimm dir einmal im Quartal eine halbe Stunde:

• Lade die aktuelle Sicherung deiner Website herunter und öffne sie. Lässt sich das Archiv entpacken? Ist die Datenbankdatei deutlich größer als ein paar Kilobyte?
• Nimm eine einzelne Datei heraus, deren Inhalt du kennst, und schau sie an. Steht drin, was drinstehen soll?
• Trag das Prüfdatum irgendwo ein. Wann zuletzt geprüft wurde, ist die wichtigere Information als wie oft gesichert wird.

Die Frage, die du deinem Dienstleister stellen solltest

Nicht „macht ihr Backups“. Die Antwort ist immer ja. Sondern: „Wann wurde zuletzt eine Sicherung testweise zurückgespielt, und was kam dabei heraus?“ Wer darauf ein Datum und eine Zahl nennt, hat einen Prozess. Wer allgemein antwortet, hat eine Absichtserklärung.

Wie wir das machen

Für alles, was wir betreiben, läuft die Sicherung nachts, verschlüsselt, mit einer Kopie an einem zweiten Standort, und der Wiederherstellungstest läuft mit. Schlägt er fehl, kommt morgens eine Mail bei uns an und nicht irgendwann ein Ausfall beim Kunden. Was sonst noch dazugehört, steht unter Managed Hosting und laufender Betrieb.