Fast jeder hat Backups. Deutlich weniger Leute haben schon einmal einen echten Restore gemacht. Genau diese Lücke ist der Grund, warum Datenverluste so oft Leute treffen, die sich für abgesichert hielten — die Sicherung lief jahrelang, nur eben nicht auf das, was am Ende wichtig war.
Ich betreue eigene Server und Kundenprojekte, und mein Verhältnis zu Backups hat sich von “ist eingerichtet” zu “ist letzten Monat getestet worden” verschoben. Das ist der ganze Unterschied.
Was du eigentlich sicherst
Bevor du über Werkzeuge nachdenkst, brauchst du eine ehrliche Liste dessen, was bei einem Totalverlust weg wäre und nicht rekonstruierbar ist. Meistens sind das drei Kategorien.
Erstens die Datenbank — der offensichtliche Teil, aber auch der, bei dem am meisten schiefgeht, weil eine Datei-Kopie eines laufenden Datenbankverzeichnisses kein konsistenter Zustand ist. Datenbanken sichert man mit ihren eigenen Werkzeugen, nicht mit dem Dateisystem-Backup obendrüber.
Zweitens die hochgeladenen Dateien: Bilder, PDFs, Kundenuploads. Das ist der Teil, der in Backup-Konzepten am häufigsten vergessen wird, weil er nicht im Repository liegt und nicht in der Datenbank steht. Ein wiederhergestellter Shop mit korrekten Bestellungen und komplett fehlenden Produktbildern ist nur die halbe Rettung.
Drittens die Konfiguration: Webserver-Konfiguration, Service-Definitionen, Cron-Einträge, Umgebungsvariablen und Secrets. Nicht weil sie sich nicht rekonstruieren ließen, sondern weil die Rekonstruktion unter Zeitdruck Stunden kostet, in denen etwas offline ist.
Der Anwendungscode selbst gehört in aller Regel nicht ins Backup, sondern ins Versionskontrollsystem — vorausgesetzt, dort liegt tatsächlich alles, was für ein Deployment nötig ist. Wer über die Jahre “kurz mal” direkt auf dem Server editiert hat, hat diesen Vorteil verspielt und sollte das zuerst geradeziehen.
Die drei Fragen, die dein Konzept bestimmen
Statt sofort ein Werkzeug auszusuchen, beantworte drei Fragen — sie legen fest, wie aufwendig deine Lösung sein muss.
Wie viele Daten darfst du verlieren? Wenn ein Tagesbackup bedeutet, dass im schlimmsten Fall ein Arbeitstag fehlt, ist das für eine Broschüren-Website egal und für einen Shop ein Problem. Aus dieser Zahl folgt dein Backup-Intervall.
Wie lange darf die Wiederherstellung dauern? Ein Stunden-Restore aus einem Archiv ist etwas anderes als ein Snapshot, den du in Minuten hochfährst. Aus dieser Zahl folgt die Art der Sicherung.
Wie lange musst du zurückgehen können? Der Fall, gegen den man sich mit langer Aufbewahrung schützt, ist nicht der Serverausfall, sondern der schleichende Schaden: eine kaputte Migration, ein fehlerhafter Import, eine Kompromittierung, die erst Wochen später auffällt. Wer nur die letzten drei Tage vorhält, hat gegen diese Fälle nichts in der Hand.
Die Regeln, die sich bewährt haben
Die alte Faustregel lautet: mindestens drei Kopien der Daten, auf zwei verschiedenen Medien oder Systemen, davon eine an einem anderen Ort. Modern ergänzt man sinnvollerweise: eine davon unveränderlich oder zumindest nicht vom produktiven System aus löschbar.
Der letzte Punkt ist der wichtigste und der am häufigsten verletzte. Wenn dein Server die Zugangsdaten zum Backup-Speicher hat und dort löschen darf, dann kann alles, was deinen Server übernimmt, auch deine Backups löschen. Genau das passiert bei Verschlüsselungsangriffen regelmäßig. Die Gegenmaßnahmen sind unspektakulär: Zugangsdaten, die nur Anhängen und Lesen erlauben, ein Aufbewahrungsschutz beim Speicheranbieter, oder ein Ziehen der Daten durch einen separaten Backup-Host statt eines Schiebens durch den Produktivserver.
Und: Verschlüssele die Sicherungen, bevor sie das eigene System verlassen. Ein Backup enthält typischerweise alle personenbezogenen Daten deiner Anwendung. Es beim günstigsten Speicheranbieter unverschlüsselt abzulegen, ist nicht nur technisch fahrlässig, sondern datenschutzrechtlich schwer zu vertreten.
Der Restore-Test ist die eigentliche Arbeit
Der Satz, der sich in Backup-Diskussionen durchgesetzt hat, stimmt: Niemand will Backups, alle wollen Restores. Ein Sicherungsjob, dessen Wiederherstellung nie ausprobiert wurde, ist eine Vermutung.
Ein Restore-Test muss nicht kompliziert sein. Nimm die Sicherung von gestern, spiel sie auf einer frischen Maschine oder in einem Container ein, starte die Anwendung, logge dich ein und schau dir echte Daten an. Was du dabei findest, sind fast immer dieselben Dinge: eine Datenbank, die zwar gesichert wird, aber ohne Erweiterungen nicht startet; ein Upload-Verzeichnis, das gar nicht im Sicherungspfad lag; eine Umgebungsdatei, ohne die nichts hochkommt; oder ein Archiv, das seit vier Monaten leer ist, weil sich ein Pfad geändert hat und niemand die Ausgabe des Jobs liest.
Deshalb gehört zu jedem Backup eine Überwachung, die nicht meldet, dass der Job lief, sondern dass er erfolgreich lief und die Sicherung eine plausible Größe hat. Ein stiller Cron-Job, dessen Fehlermeldungen an eine nicht gelesene Systemmailbox gehen, ist der Normalzustand — und die häufigste Ursache dafür, dass Leute im Ernstfall in ein leeres Verzeichnis schauen.
Schreib den Wiederherstellungsweg außerdem auf, in nüchternen Schritten, und lege ihn dorthin, wo du auch drankommst, wenn der betroffene Server aus ist. Im Ernstfall arbeitest du unter Druck, meistens abends, oft mit einem Kunden am Telefon. Da will man lesen, nicht denken.
Für Kundenprojekte: Sag, was du sicherst
Zum Schluss der geschäftliche Teil. Kunden gehen selbstverständlich davon aus, dass “irgendwer” Backups macht. Wenn du das nicht ausdrücklich anbietest und niemand sonst es tut, existiert die Sicherung nicht — die Verantwortung dafür wird dir aber trotzdem zugeschrieben, wenn es knallt.
Deshalb gehört in jedes Angebot ein klarer Satz dazu, ob und was gesichert wird, wie oft, wie lange aufbewahrt und wie schnell wiederhergestellt werden kann. Wenn der Kunde das nicht will, ist das seine Entscheidung — aber eine dokumentierte. Und wenn er es will, ist es ein guter, ehrlich begründbarer Bestandteil einer laufenden Betreuung, weil dahinter echte, wiederkehrende Arbeit steckt.
Falls du gerade dein eigenes Setup überprüfst: Der schnellste Erkenntnisgewinn ist ein Restore-Versuch heute Abend, nicht ein neues Werkzeug. Und wenn dabei etwas Peinliches herauskommt — im Discord der Community hat das jeder schon erlebt.