Ihr Backup läuft. Aber haben Sie es je zurückgespielt?
Zwischen „wir sichern täglich“ und „wir sind in zwei Stunden wieder da“ liegt ein Test, den fast niemand macht.
Die Frage, die in Gesprächen über Backups am wenigsten gestellt wird und am meisten aussagt, lautet nicht „Sichern Sie regelmäßig?”. Sie lautet: „Wann haben Sie zuletzt eine Sicherung zurückgespielt?”
Bei den allermeisten Antworten entsteht an dieser Stelle eine Pause.
Das ist keine Nachlässigkeit, sondern nachvollziehbar: Ein Backup-Protokoll, das jeden Morgen grün meldet, fühlt sich nach Sicherheit an. Nur beweist es nichts über den einzigen Moment, auf den es ankommt.
Was ein grünes Protokoll nicht abdeckt
Ob die Daten vollständig sind. Gesichert wird, was im Backup-Auftrag steht. Wenn vor acht Monaten eine zweite Datenbank dazukam, die nie aufgenommen wurde, meldet der Auftrag trotzdem Erfolg — er sichert ja korrekt, was ihm aufgetragen wurde.
Ob sich die Sicherung lesen lässt. Beschädigte Archive, abgelaufene Verschlüsselungsschlüssel, ein Repository, dessen Index nicht mehr zur Datenmenge passt: Das alles fällt beim Schreiben nicht auf, sondern beim Lesen.
Ob Sie wissen, wie es geht. Das ist der unterschätzte Teil. Der Ablauf steht selten vollständig irgendwo, das Passwort für das Backup-Repository liegt manchmal in genau dem System, das gerade weg ist, und die Reihenfolge — erst Datenbank, dann Anwendung, dann Verbindungen prüfen — kennt nur derjenige, der es aufgesetzt hat.
Wie lange es dauert. „Ein paar Stunden” ist keine Planungsgrundlage. Der Unterschied zwischen zwei und zwölf Stunden entscheidet, ob Sie einen Tag Umsatz verlieren oder eine Woche Vertrauen.
Die zwei Zahlen, die Sie kennen sollten
RPO — wie viel Arbeit dürfen Sie verlieren? Sichern Sie einmal täglich um zwei Uhr nachts und der Ausfall passiert um 18 Uhr, sind sechzehn Stunden Arbeit weg: Bestellungen, Zahlungseingänge, Artikelpflege. Für viele Händler ist das die falsche Antwort — dann brauchen Sie zusätzliche Sicherungen über den Tag verteilt, nicht mehr Speicherplatz.
RTO — wie lange dürfen Sie stehen? Diese Zahl entsteht nicht am Reißbrett, sondern beim Messen. Genau dafür gibt es den Restore-Test.
Ein Ablauf, den man zweimal im Jahr durchzieht
Vorher festlegen, was als bestanden gilt. Zum Beispiel: Die Datenbank ist auf einem separaten System wiederhergestellt, die Anwendung verbindet sich, die letzten drei Bestellungen vor dem Sicherungszeitpunkt sind vorhanden und die Artikelanzahl stimmt mit der Erwartung überein.
Auf ein separates System zurückspielen, niemals über das produktive. Eine zweite Instanz oder ein temporärer Server genügt. Wer direkt über die Produktion zurückspielt, hat aus einem Test einen Ausfall gemacht.
Die Zeit stoppen — ehrlich. Von „jetzt ist es weg” bis „es arbeitet wieder”. Inklusive der Minuten, in denen Sie das Repository-Passwort suchen. Genau die zählen im Ernstfall auch.
Stichproben in den Daten, nicht im Protokoll. Öffnen Sie ein paar Datensätze. Ein technisch erfolgreicher Restore mit einer drei Wochen alten Datenbank ist kein bestandener Test.
Aufschreiben, was gehakt hat. Der Wert des Tests liegt nicht im grünen Haken, sondern in der Liste der Kleinigkeiten, die Sie beim nächsten Mal nicht mehr suchen müssen.
Was ich bei Kunden regelmäßig finde
Alle Sicherungen liegen beim selben Anbieter wie die Systeme. Bequem, aber bei einem kompromittierten Zugang oder einem Problem auf Anbieterseite ist beides gleichzeitig betroffen. Eine Kopie mit eigenen, getrennten Zugangsdaten gehört an einen anderen Ort.
Das Backup-Passwort liegt im Passwortmanager auf dem Server, der gesichert wird. Ein Zirkelschluss, der erst im Ernstfall auffällt.
Niemand bekommt mit, wenn die Sicherung ausfällt. Fehlermails gehen an eine Adresse, die keiner mehr liest. Besser: aktiv prüfen, ob eine Sicherung stattgefunden hat — und melden, wenn seit zu langer Zeit keine mehr kam. Ausbleibende Meldungen sind ein schlechtes Erfolgssignal.
Der Aufbewahrungszeitraum ist zu kurz. Sieben Tage reichen für einen Serverausfall. Sie reichen nicht, wenn Sie nach drei Wochen bemerken, dass seit einem Monat Daten fehlerhaft geschrieben werden. Für solche Fälle brauchen Sie Stände, die weiter zurückreichen.
Der ehrliche Satz zum Schluss
Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Es kann funktionieren. Vielleicht tut es das auch. Aber Sie wissen es nicht, und der Tag, an dem Sie es herausfinden, ist per Definition der schlechteste Tag dafür.
Zwei Stunden, zweimal im Jahr. Mehr ist es nicht.
Häufige Fragen
Wie oft sollte man einen Restore testen?
Zweimal im Jahr ist ein guter Kompromiss aus Aufwand und Sicherheit, zusätzlich nach jeder größeren Änderung an Server, Datenbank oder Backup-Software. Wichtiger als die Frequenz ist, dass der Test überhaupt stattfindet und jemand die benötigte Zeit misst.
Was ist der Unterschied zwischen RPO und RTO?
RPO ist der maximal tolerierbare Datenverlust, gemessen in Zeit: Bei täglicher Sicherung um zwei Uhr nachts verlieren Sie im schlimmsten Fall knapp einen Tag Arbeit. RTO ist die Zeit bis zur Wiederherstellung. Beide Werte sollten Sie kennen, bevor Sie sie im Ernstfall herausfinden.
Reicht ein Snapshot beim Hoster als Backup?
Als alleinige Sicherung nicht. Snapshots liegen meist auf derselben Infrastruktur und sind an das Konto gebunden — bei einem kompromittierten Zugang oder einem Problem beim Anbieter sind sie mit weg. Eine Kopie an einem separaten Ort mit eigenen Zugangsdaten gehört dazu.
