Website-Backups: Wiederherstellung im Ernstfall testen

Der Begriff Datensicherung wird im Alltag für zwei sehr verschiedene Vorgänge benutzt. Der eine ist das Anlegen einer Kopie, der andere das Zurückspielen dieser Kopie auf ein laufendes System. Das IT-Grundschutz-Kompendium trennt beides ausdrücklich und hält fest, dass zu einem vollständigen Datensicherungskonzept nicht nur gehört, wie Sicherungen präventiv erstellt werden, sondern auch, wie sie auf dem Ursprungssystem wiederhergestellt werden (BSI). Diese zweite Hälfte wird in der Praxis selten geübt, weil sie Aufwand kostet und weil nichts sie erzwingt: Eine Sicherung meldet Erfolg, sobald die Kopie geschrieben ist. Ob die Kopie brauchbar ist, prüft sie nicht.

Der Unterschied klingt akademisch, bis er teuer wird. Ein Archiv kann vollständig sein und trotzdem unbrauchbar, weil die Datenbank in einem Format vorliegt, das die neue Serverversion nicht mehr einliest. Eine Sicherung kann jede Nacht laufen und seit Wochen einen Ordner auslassen, den niemand vermisst hat, weil er nur die hochgeladenen Bilder enthält. Ein Sicherungssatz kann verschlüsselt sein und der Schlüssel im selben Verzeichnis liegen. Keiner dieser Fälle fällt beim Sichern auf. Alle drei fallen beim ersten Zurückspielen auf, und wenn dieses erste Zurückspielen der Ernstfall ist, verlängert jeder von ihnen den Ausfall um Stunden.

Der Satz stammt aus der Gefährdungslage des Bausteins und beschreibt die Lücke präzise: Regelmäßigkeit ist eine Eigenschaft des Sicherns, nicht des Wiederherstellens. Wer die zweite Hälfte belegen will, braucht einen eigenen Vorgang mit eigenem Termin und eigenem Ergebnis. Wie sich das in den laufenden Betrieb einfügt, hängt eng mit der übrigen Pflege zusammen, die eine Website braucht; wir haben die Bausteine dafür in unserem Beitrag zu den Grundlagen der Website-Sicherheit beschrieben.

Eine Sicherungseinstellung lässt sich nicht bewerten, solange nicht feststeht, was sie leisten soll. Dafür genügen zwei Zahlen. Die erste ist der maximal zulässige Datenverlust, in der Notfallplanung als Recovery Point Objective oder RPO bezeichnet; das IT-Grundschutz-Kompendium nennt sie als eine der wesentlichen Anforderungen, die im Datensicherungskonzept berücksichtigt werden sollten (BSI). Sie beantwortet die Frage, wie viele Stunden Arbeit im schlimmsten Fall verloren gehen dürfen, und legt damit den Abstand zwischen zwei Sicherungen fest. Die zweite ist die Wiederherstellungsdauer: die Zeitspanne vom Erkennen der Störung bis zu dem Punkt, an dem die Website wieder benutzbar ist.

Beide Zahlen sind Geschäftsentscheidungen, keine technischen. Sie werden nicht vom Sicherungsverfahren vorgegeben, sondern vom Wert der Arbeit, die zwischen zwei Sicherungen entsteht, und von dem, was ein Tag Stillstand kostet. Erst wenn sie feststehen, lässt sich sagen, ob eine nächtliche Sicherung ausreicht oder ob es zusätzlich stündliche Stände der Datenbank braucht. Wer beide Werte nicht benennt, hat keine Sicherungsstrategie, sondern eine Sicherungsgewohnheit.

Ein Wiederherstellungstest ist kein Projekt. Er ist ein festgelegter Ablauf, der zweimal im Jahr wiederholt wird und beim zweiten Mal deutlich schneller geht als beim ersten. Entscheidend ist, dass er in ein getrenntes Ziel läuft und nicht auf das laufende System. Ein Testlauf, der die produktive Website überschreibt, ist kein Test, sondern ein zweiter Schaden.

Die ersten beiden Schritte lassen sich mit Bordmitteln erledigen und brauchen keine besondere Ausstattung. Wichtig ist nur, dass die Prüfsumme vor dem Entpacken gebildet wird und dass die Anzahl der enthaltenen Dateien mit einem Erwartungswert verglichen wird. Ein Archiv, das plötzlich ein Drittel kleiner ist als beim letzten Mal, ist erfahrungsgemäß der erste sichtbare Hinweis auf eine ausgelassene Verzeichnisebene.

Der letzte Schritt ist der, den man am leichtesten weglässt und am dringendsten braucht. Ein Protokoll muss nicht schön sein, es muss vergleichbar sein: in jedem Lauf dieselben Felder, in jedem Lauf dasselbe Format, abgelegt an einer Stelle, die auch dann erreichbar ist, wenn die Website es nicht ist. Eine kleine Datei genügt, solange sie Datum, gemessene Werte und die vereinbarten Zielwerte nebeneinander stellt.

Zwei Felder sind dabei die eigentlichen Ergebnisse: der gemessene Datenverlust gegen den vereinbarten und die gemessene Dauer gegen die vereinbarte. Alles andere ist Kontext. Wenn eine der beiden Zahlen ihr Ziel verfehlt, ist die Konsequenz keine Diskussion, sondern eine Änderung am Intervall, am Verfahren oder an der Vorbereitung, und der nächste Testlauf prüft genau diese Änderung.

Wer personenbezogene Daten verarbeitet, und das tut jede Website mit Kontaktformular, Kundenkonto oder Bestellvorgang, findet die Anforderung im Gesetzestext selbst. Artikel 32 der Datenschutz-Grundverordnung zählt zu den geeigneten technischen und organisatorischen Maßnahmen ausdrücklich die Fähigkeit zur raschen Wiederherstellung, und im selben Absatz auch ein Verfahren zur regelmäßigen Überprüfung der Wirksamkeit dieser Maßnahmen (Datenschutz-Grundverordnung). Beides zusammen beschreibt genau das, was ein dokumentierter Wiederherstellungstest leistet.

Der Verordnungstext nennt keine Fristen und keine Intervalle, weil sich beides nach dem Risiko richtet. Er verlangt aber eine Fähigkeit und ein Verfahren, und eine Fähigkeit, die noch kein einziges Mal ausprobiert wurde, ist schwer zu belegen. Ein Protokoll mit Datum, Dauer und Befund ist deshalb nicht nur betrieblich sinnvoll, sondern auch der einfachste verfügbare Nachweis. Welche weiteren Punkte auf einer Website dazugehören, haben wir in unserer Checkliste zur DSGVO zusammengestellt. Beim Wiederaufbau nach einem Vorfall gelten dieselben Regeln für Weiterleitungen und Adressen wie bei einem geplanten Umbau, wie wir sie im Beitrag zu typischen Fehlern beim Website-Relaunch beschrieben haben.