Backups, die man wirklich wiederherstellt
Jeder sagt, Backups seien wichtig. Kaum jemand prüft, ob sie funktionieren. Ich habe es lange selbst nicht getan: Der Backup-Job lief, die Dateien waren da, ich habe auf die grüne Erfolgsmeldung geschaut und weitergearbeitet. Bis ich das erste Mal wirklich etwas wiederherstellen musste – und merkte, dass ich keine Ahnung hatte, ob das geht. Nicht ob die Daten da sind, sondern ob ich sie zurückbekomme.
Das ist der Unterschied, um den es hier geht. Ein Backup ist kein Artefakt, sondern ein Versprechen. Und ein Versprechen, das man nie einlöst, ist keins.
Der erste echte Restore
Mein erster Zwang kam über Nextcloud. Eine falsche occ-Aktion hatte eine Datenbanktabelle ruiniert, und die Instanz wollte nicht mehr hoch. Backup war da – ein Dump von gestern Nacht. Also: Dump einspielen, fertig, dachte ich.
Es dauerte drei Stunden.
Nicht, weil der Dump kaputt war. Sondern weil ich die Reihenfolge nie durchdacht hatte: Erst die Datenbank, dann die Dateien, dann die Config, dann die Berechtigungen – und in welcher Reihenfolge stoppt man die Dienste, damit nicht ein laufender PHP-Prozess mitten in den Restore schreibt? All das wusste ich nicht, weil ich es nie geübt hatte. Ich habe es an diesem Abend live ausprobiert, auf einem defekten System, mit einem Kunden, der wartet. Genau die falsche Umgebung für ein Experiment.
Was dabei kaputtgeht
Der Abend hat mir eine Liste von Annahmen zerlegt, die ich vorher für selbstverständlich hielt:
- Der Dump ist lesbar. Ein
pg_dump, das seit Wochen läuft, kann korrupt sein, ohne dass der Job einen Fehler meldet. Erst beim Einspielen merkt man es. - Der Restore passt auf die Version. Ein Backup von Nextcloud 27 in eine 29er-Instanz zurückzuspielen ist kein Restore, sondern ein Migrationsprojekt. Versionsstände gehören mit ins Backup – oder besser: ins Restore-Skript.
- Die Config ist nicht nur die DB. Bei Nextcloud liegen Zustand und Daten an mindestens drei Orten: Datenbank, Datenverzeichnis,
config.php. Wer nur einen davon sichert, hat keinen Stand. - Berechtigungen sind Teil der Daten. Ein Restore mit falschen Owner- oder Group-Rechten führt zu einer Instanz, die aussieht wie neu, aber nichts darf.
www-dataist keine Formalie. - Ich war der Flaschenhals. Das eigentliche Problem war nicht die Technik, sondern dass ich den Ablauf zum ersten Mal machte. Unter Druck.
Der gemeinsame Nenner: Der Backup-Job prüft, ob er geschrieben hat. Nicht, ob du zurückkommst.
Was ich seitdem ändere
Aus dem Abend sind drei Gewohnheiten geworden, die mehr wert sind als jedes zusätzliche Backup-Tool:
1. Restore üben, bevor man ihn braucht. Ich nehme mir regelmäßig eine Test-Instanz und spiele den letzten Stand zurück – nicht die Produktion, eine Kopie davon. Der Ablauf wird zur Routine, die Schritte werden zum Muskelgedächtnis. Wenn es dann ernst wird, ist es kein Experiment mehr, sondern Wiederholung.
2. Das Backup als Skript, nicht als Konfiguration. Der Restore ist ein Skript, das ich pflege wie den Rest des Codes. Es kennt die Reihenfolge, die Versionsstände, die Berechtigungen. Ich muss es nicht mehr auswendig wissen – ich muss es nur ausführen und sehen, dass es durchläuft.
3. Den Restore automatisieren und prüfen. Ein Skript, das nachts den Dump einspielt und anschließend eine Prüfung startet – kommt die Instanz hoch, ist der Stand lesbar? Wenn ja, war das Backup von gestern tatsächlich brauchbar. Das ist der einzige Test, der zählt.
Die unbequeme Wahrheit
Backup-Software verkauft dir das Gefühl von Sicherheit. Die grüne Meldung, der Haken, die Mail „Backup erfolgreich". Aber kein Tool der Welt weiß, ob du aus diesem Backup tatsächlich wieder ein laufendes System bekommst. Das weißt nur du – und nur dann, wenn du es ausprobiert hast.
Meine Regel ist seitdem simpel: Wenn ich nicht bereit bin, dieses Backup morgen zurückzuspielen, ist es keins. Der Rest ist Dateiverwaltung mit gutem Gewissen.
Backups zu haben ist keine Leistung. Sie zurückzubekommen schon.