Website-Backup-Strategie: So sichern Sie Ihre Daten richtig

Eine belastbare Website-Backup-Strategie hält drei Kopien Ihrer Daten auf mindestens zwei verschiedenen Medien, davon eine außer Haus, unveränderlich und mit eigenen Zugangsdaten — und sie wird regelmäßig probehalber zurückgespielt. Sie legt fest, was gesichert wird, in welchem Rhythmus, wie lange aufbewahrt wird und wie die Wiederherstellung abläuft. Das wichtigste Merkmal einer echten Sicherung ist nicht die Software, sondern der Nachweis: Sie wurde auf einer Testumgebung wiederhergestellt. Alles andere ist eine Vermutung über Daten, die man im Ernstfall nicht zurückbekommt.

##Warum reicht das Backup des Hosters nicht?

Hoster-Backups sichern den Betrieb des Hosters, nicht Ihren Datenbestand. Sie liegen häufig im selben Rechenzentrum, decken nur Teile ab — Datenbank ja, Medienordner manchmal —, behalten kurze Zeiträume und nutzen dieselben Zugangsdaten wie das Produktivsystem. Löscht jemand den Uploads-Ordner per Skript, löscht er ihn meist auch in der Sicherung mit. Und selbst wo Zusagen existieren: Die Wiederherstellung ist ein Support-Vorgang mit eigener Bearbeitungszeit — sie folgt dem Service des Anbieters, nicht Ihrem Datenverlust-Budget. Ein eigenes Sicherungsziel außerhalb des Servers und außerhalb desselben Rechenzentrums ist deshalb keine Zusatzoption, sondern die Mindestanforderung.

##Was gehört in eine vollständige Sicherung?

Eine Website besteht aus mehr als der Datenbank. Wer nur den Dump nimmt, stellt nach einem Ausfall eine Seite mit Texten und leeren Bildrahmen wieder her. Vollständig ist eine Sicherung erst, wenn alle Teile vorhanden sind, die die Seite laufen lassen — inklusive der Information, welcher Codestand zu welchem Datenstand gehört. Diese Zusammenschau entscheidet im Ernstfall darüber, ob die Seite in einer Stunde läuft oder tagelang halb steht.

• ›Datenbank und hochgeladene Dateien im selben Lauf, damit sie zueinander passen.
• ›Konfiguration und Umgebungsvariablen — separat abgelegt und verschlüsselt, denn sie enthalten Zugangsdaten.
• ›Cronjobs, TLS-Zertifikate, DNS-Einträge und Webserver-Konfiguration, die Backups gern vergessen.
• ›Der zugehörige Codestand: Commit-Hash oder Release-Tag mitprotokollieren.
• ›Sicherung verschlüsselt, außerhalb des Servers und außerhalb desselben Rechenzentrums.

##Wie funktioniert die 3-2-1-Regel in der Praxis?

Die 3-2-1-Regel ist der bewährte Rahmen, und auch die Datensicherungsbausteine im IT-Grundschutz des BSI folgen derselben Struktur: mehrere Kopien, getrennte Speichermedien, mindestens ein Standort außerhalb der Produktivumgebung. Die Logik dahinter: Jede einzelne Kopie kann verloren gehen — Platte defekt, Account gesperrt, Verschlüsselung durch Schadsoftware. Solche Ausfälle überlappen selten, wenn die Kopien technisch und organisatorisch wirklich getrennt sind.

• ›Drei Kopien der Daten — die Produktion plus zwei Sicherungen.
• ›Zwei verschiedene Medien oder Anbieter, nicht zweimal derselbe Account desselben Anbieters.
• ›Eine Kopie außer Haus, idealerweise unveränderlich (Immutable Storage, WORM) oder offline.
• ›Die Zugangsdaten für diese Kopie liegen nicht auf dem Produktivsystem.

##Wie sichern Sie Datenbank und Dateien konsistent?

Ein Datenbank-Dump von 03:00 Uhr und ein Datei-Backup von 05:00 Uhr ergeben nach der Wiederherstellung einen inkonsistenten Mischstand: Beiträge ohne Bilder, Bestellungen ohne Belege. Beides muss zum selben Zeitpunkt gehören — am besten als ein Vorgang mit einem gemeinsamen Zeitstempel. Die Option --single-transaction fängt dabei die Datenbank als einheitlichen Stand ein, ohne laufende Vorgänge zu blockieren; die Uploads werden im selben Lauf gezogen und mit demselben Zeitstempel markiert.

##Wie beweisen Sie, dass Ihr Backup funktioniert?

Der einzige Beweis ist eine Wiederherstellung. Einmal pro Quartal den Bestand vollständig auf einer Staging-Umgebung einspielen, die Zeit stoppen, Seite aufrufen, Anmeldung prüfen, ein Bild öffnen — dreißig Minuten, die die häufigste böse Überraschung ausschließen: eine Sicherungsdatei, die seit Monaten leer ist, weil sich ein Pfad geändert hat. Die gestoppte Zeit ist Ihre reale Wiederanlaufzeit, nicht die Zahl aus dem Hoster-Vertrag. Halten Sie zusätzlich fest, wer im Ernstfall was tut: wer die Wiederherstellung startet, wer den Hoster kontaktiert, wer Kunden informiert. Diese drei Zeilen unterscheiden einen geordneten Ablauf von einer Stunde Telefonieren, bevor irgendjemand anfängt.

##Was ändert Ransomware an den Anforderungen?

Ransomware verschlüsselt alles, was vom kompromittierten System aus beschreibbar ist — eingeschlossen Backups, die über dieselben Zugangsdaten erreichbar sind. Genau darauf zielen Angriffe auf kleine und mittlere Unternehmen heute oft ab: erst die Produktion, dann die Sicherung. Deshalb gilt: mindestens eine Kopie unveränderlich oder offline, mit eigenen Zugangsdaten, die auf dem Produktivsystem nicht liegen. Der Unterschied ist nicht akademisch — er entscheidet darüber, ob aus dem Zwischenfall eine Wiederanlaufzeit von Stunden wird oder ein Totalverlust. Und er kostet in der Regel nur die Konfiguration eines zweiten Speicherziels.

##Wo fangen Sie am besten an?

Sie müssen nicht alles an einem Tag umbauen. Vier Schritte bringen den größten Zuwachs an Sicherheit und kommen in dieser Reihenfolge für fast jede Website infrage:

• ›RPO und RTO in zwei Sätzen festlegen — mit demjenigen, der im Ernstfall den Schaden meldet.
• ›Den jetzigen Backup-Bestand einmal probehalber zurückspielen. Das Ergebnis ist Ihre Ausgangslage, sei sie gut oder schlecht.
• ›Ein zweites, außer-Haus-Ziel einrichten und den Zugang vom Produktivsystem trennen.
• ›Den Restore-Test quartalsweise in den Betriebsteam-Kalender schreiben — er ist der einzige Nachweis, der zählt.