Die Website ist kaputt. Wann hast du zuletzt dein Backup geprüft?

Am Dienstag um 8:50 Uhr schreibt dir dein Manager: „Die Website zeigt nur eine weiße Seite.“ Eine halbe Stunde später steht fest, dass sich nachts ein Plugin aktualisiert hat. Jetzt sind weder der Katalog noch der Adminbereich erreichbar. Du antwortest gelassen: „Kein Problem, wir haben doch Backups.“ Und genau da wird es interessant.

Wer erstellt sie? Der Hoster. Gut, von wann ist das letzte? Muss man nachschauen. Wer kann die Website wiederherstellen? Vermutlich Oleg, der Dienstleister. Oleg ist im Urlaub. Wenn die Wiederherstellung abgeschlossen ist, zeigt sich noch eine Kleinigkeit: Das Backup wurde um drei Uhr nachts erstellt, die Bestellungen vom Vorabend sind darin nicht enthalten.

Die Situation ist typisch: Der Inhaber geht ehrlich davon aus, dass Sicherungen vorhanden sind, und hat damit formal recht. Doch „Backups sind vorhanden“ beantwortet nur eine von vier Fragen. Die anderen drei lauten: Was genau verlieren wir, wie lange fällt die Website aus und wer drückt auf den Knopf?

Im Folgenden begleite ich eine beispielhafte Geschichte: einen Onlineshop für Ersatzteile für Landmaschinen. Ein Katalog mit mehreren Tausend Artikeln, Bestellungen von landwirtschaftlichen Betrieben, zwei Mitarbeitende im Vertrieb und eine Website auf WordPress mit WooCommerce. Die Geschichte ist erfunden, aber jedes ihrer Probleme kommt im Alltag vor.

Wenn die Website ausgefallen ist, interessiert dich nicht allein, ob irgendwo ein Archiv existiert. Du musst zwei Zahlen kennen.

Wie viele Daten du zu verlieren bereit bist. Wird einmal täglich ein Backup erstellt, geht im schlimmsten Fall fast ein ganzer Tag verloren: neue Bestellungen, Preisänderungen, neue Produkte und registrierte Kunden. Das ist die Grenze für den Datenverlust. Bei einer einfachen Unternehmenswebsite, deren Texte sich einmal im Quartal ändern, tut der Verlust einer Woche kaum weh. Für einen Ersatzteilshop bedeuten selbst Bestellungen aus einem halben Tag während der Feldarbeitssaison Anrufe bei verärgerten Landwirten und manuelle Rekonstruktion aus E-Mails.

Wie lange die Website ausfallen darf. Das ist die Wiederherstellungszeit. Dazu gehört, wie lange du nach Zugangsdaten suchst, wie lange die Wiederherstellung selbst dauert und wie lange du das Ergebnis prüfst. Der Hoster verspricht vielleicht eine Wiederherstellung „mit einem Klick“. Doch jemand muss diesen Klick ausführen und dafür Zugang haben.

Diese beiden Zahlen solltest du vor einem Notfall festhalten. Nehmen wir an, unser Beispielshop entscheidet: Höchstens eine Stunde an Bestellungen darf verloren gehen, und der Shop darf höchstens vier Stunden ausfallen. Aus diesen beiden Angaben ergibt sich fast alles Weitere: wie häufig Backups erstellt werden, wo sie liegen und wen du weckst, wenn etwas kaputtgeht.

Schau dir einen normalen Arbeitstag an und prüfe, was sich zwischen zwei Backups auf deiner Website ändert.

Der Ersatzteilshop erhält beispielsweise 30 Bestellungen am Tag. Am Abend aktualisiert ein Mitarbeiter die Preise anhand einer Tabelle des Lieferanten. Das Backup wird um drei Uhr nachts erstellt. Der Ausfall passiert um 16:00 Uhr. Dazwischen liegen dreizehn Stunden: Bestellungen vom Vorabend und vom heutigen Morgen, aktualisierte Preise und zwei neue Großhandelskunden mit individuellen Rabatten.

Einen Teil davon findest du an anderer Stelle wieder. Bestellbenachrichtigungen liegen im E-Mail-Postfach, Zahlungen im Konto des Zahlungsdienstes, Versandbelege beim Versanddienstleister. Allerdings muss jemand die Bestellungen von Hand aus den E-Mails rekonstruieren. Und diese Person wird sich dafür kaum bei dir bedanken.

Die WordPress-Dokumentation gibt eine Orientierung: Bei kleinen Websites mit wenigen Änderungen einmal pro Woche sichern, bei aktiven Websites täglich und außerdem immer vor einem Update (WordPress: Backups). Für einen Shop mit laufenden Bestellungen reicht „täglich“ oft nicht. Deshalb solltest du die Datenbank häufiger sichern als die Dateien. Dateien wie Themes, Plugins und Produktfotos ändern sich seltener. Die Bestellungen liegen in der Datenbank.

Was du tun kannst: Frag die Person, die deine Website betreut, wann und wie oft die Datenbank gesichert wird. Vergleiche die Antwort damit, wie viele Bestellungen oder Anfragen du von Hand wiederherstellen würdest.

Für eine typische WordPress-Website brauchst du zwei Teile: die Dateien und die Datenbank. Die offizielle Dokumentation erklärt ausdrücklich, dass eine Dateisicherung die Datenbank nicht enthält, weil diese in einem separaten System gespeichert wird (WordPress: Backups, Anleitung zur Datenbanksicherung).

Doch selbst ein vollständiges Archiv mit Dateien und Datenbank enthält oft nicht alles, was dein Unternehmen braucht, um wieder arbeiten zu können. Geh diese Liste durch:

• E-Mail. Postfächer beim Hoster sind normalerweise getrennt von der Website gespeichert. Das britische Zentrum für Cybersicherheit NCSC nennt ausdrücklich E-Mails, Rechnungen, Kontakte und Kundendaten als Informationen, die Unternehmen zusammen mit ihrer Website sichern sollten (NCSC: Backing up your data).
• DNS-Einträge der Domain. Werden sie geändert oder gelöscht, sind Website und E-Mail nicht mehr erreichbar, obwohl beide selbst unbeschädigt sind. Ein Screenshot oder Export der Einträge genügt, wenn er separat aufbewahrt wird.
• Servereinstellungen. Weiterleitungsregeln, Passwörter für interne Bereiche und Zugriffsbeschränkungen liegen häufig in der Serverkonfiguration und nicht in WordPress.
• Zugangsschlüssel für Integrationen. Dazu gehören Zahlungsdienst, Versand und die Synchronisierung mit Lager oder Buchhaltungsprogramm. Nach einer Wiederherstellung müssen diese Verbindungen manchmal neu eingerichtet werden. Gut, wenn du vorher weißt, wo die Zugangsdaten liegen.
• Dateien außerhalb der Website. Produktfotos können in einem separaten Cloudspeicher liegen, Anfrageformulare bei einem externen Dienst.
• Geplante Aufgaben. Etwa die nächtliche Preisaktualisierung, der Export zu einem Marktplatz oder Erinnerungen an Kunden.

Bei unserem Beispielshop gab es genau hier die erste Überraschung. Die Produktfotos waren jahrelang in einen separaten Speicher hochgeladen worden und gehörten nicht zum Website-Archiv. Der wiederhergestellte Katalog sah aus wie eine Auslage nach der Inventur: Namen und Preise waren da, anstelle der Bilder nur graue Kästchen.

Ein Backup beim selben Hoster wie die Website ist wie ein Ersatzschlüssel, den du mit Klebeband an dieselbe Tür klebst. Solange die Tür noch da ist, ist das sehr praktisch.

Das Problem: Typische Vorfälle treffen genau diesen Ort. Der Hoster sperrt das Konto wegen einer offenen Rechnung. Jemand verschafft sich Zugang zum Konto und löscht alles samt Backups. Der Server wird beschädigt. In jedem dieser Fälle verschwinden Website und Rettung gleichzeitig.

WordPress empfiehlt, mehrere aktuelle Kopien an verschiedenen Orten aufzubewahren: beim Hoster, in einem Cloudspeicher und lokal (WordPress: Backups). NCSC ergänzt zwei wichtige Details: Eine externe Festplatte sollte nicht ständig mit dem Computer verbunden sein, weil manche Viren auch sie erreichen. Der Cloudspeicher mit den Backups sollte außerdem durch eine Anmeldung mit zwei Faktoren geschützt sein (NCSC).

Ich empfehle noch etwas Einfaches: Der Zugang zum externen Backup sollte sich vom Zugang zur Website unterscheiden. Wenn ein Passwort sowohl die Website als auch den Backup-Speicher öffnet, bekommt eine Person, die dieses Passwort stiehlt, Zugriff auf beides. Verschiedene Konten und unterschiedliche Personen mit Zugang sind im Alltag etwas umständlicher, am Tag eines Notfalls aber deutlich hilfreicher.

Wie du einen Hoster unter diesem Gesichtspunkt beurteilst, habe ich im Artikel „Webhosting auswählen und nicht erst am Tag deiner Rabattaktion von den Limits erfahren“ beschrieben. Hier ist vor allem eines wichtig: Backups beim Hoster sind gut, sollten aber nicht die einzigen sein.

Über diese Frage denken nur wenige nach. Dabei entscheidet sie darüber, ob dich ein Backup nach einem Angriff retten kann.

Eine gehackte Website fällt selten sofort aus. Häufig funktioniert sie wochenlang wie gewohnt, während irgendwo im Hintergrund bereits fremder Code liegt: Er verschickt Spam, manipuliert Links oder wartet auf seinen Einsatz. Bemerkt wird das oft erst, wenn Kunden sich über merkwürdige Weiterleitungen beschweren oder der Hoster das Konto sperrt.

Stell dir nun vor, der Hoster speichert nur die letzten sieben täglichen Backups. Der Angriff fand vor drei Wochen statt. Alle sieben Kopien enthalten bereits denselben fremden Code. Egal, welche du wiederherstellst: Du bekommst eine gehackte Website zurück, nur eine etwas ältere.

Ein nützliches Aufbewahrungsschema reicht deshalb weiter zurück: tägliche Kopien der letzten ein bis zwei Wochen, wöchentliche Kopien der letzten ein bis zwei Monate und monatliche Kopien über einen längeren Zeitraum. Die genauen Zeiträume hängen von der Website und dem Budget für Speicherplatz ab. Die Idee ist einfach: Mindestens eine Sicherung sollte garantiert älter sein als das Problem.

WordPress empfiehlt in seinem Beitrag zu gehackten Websites, beim Hoster nachzufragen, wie genau er Backups speichert, und sie frühzeitig als Teil der Planung für den fortlaufenden Geschäftsbetrieb zu berücksichtigen (WordPress: FAQ My site was hacked). Ich würde ergänzen: Stell diese Frage, bevor etwas passiert. Die Antwort „Wir speichern drei Tage“ hört man besser mit klarem Kopf.

Das Backup eines Shops enthält alles: Kundennamen, Telefonnummern, Lieferadressen, Bestellhistorien und manchmal Passwort-Hashes. Deine gesamte Kundendatenbank steckt also in einer einzigen Datei.

Wir haben erlebt, dass nach dem Umzug einer Website auf einen anderen Server SQL-Kopien der Datenbank direkt im Website-Verzeichnis lagen und über einen direkten Link heruntergeladen werden konnten. Die Website lief, niemand bemerkte etwas. Der alte Server hatte den Zugriff auf diese Dateien durch eigene Regeln gesperrt, der neue las diese Regeln nicht.

Deshalb gelten für Backups einige Sicherheitsanforderungen:

1. Archive nicht im öffentlichen Website-Verzeichnis aufbewahren, wo sie jeder herunterladen kann, der den Dateinamen errät. Namen wie backup_new_2_ok.zip lassen sich leichter erraten, als man denkt.
2. Kopien außerhalb des Hostings verschlüsseln und das Passwort für die Verschlüsselung so aufbewahren, dass zwei Personen es finden können, nicht nur eine.
3. Beschränken, wer ein Backup herunterladen darf. Der Dienstleister braucht es für seine Arbeit, der Praktikant für Social Media vermutlich nicht.
4. Alte Kopien nach einer festen Regel löschen und nicht erst, wenn der Speicherplatz ausgeht.

Falls deine Website kürzlich umgezogen ist, solltest du danach gesondert prüfen, ob interne Dateien vor Zugriff geschützt sind.

Am besten findest du heraus, ob dein Backup funktioniert, indem du die Website an einem ruhigen Tag daraus wiederherstellst. In einer separaten Testumgebung, nicht auf der Live-Website. Wie bei einer Brandschutzübung: Niemand zündet etwas an, aber alle verlassen tatsächlich das Gebäude und jemand steht mit der Stoppuhr bereit.

So hat unser Beispielshop den Probealarm durchgeführt.

Vorbereitung. Das Team wählte einen Tag mit wenigen Bestellungen. Der Dienstleister richtete eine separate Subdomain für den Test ein, schützte sie mit einem Passwort und untersagte die Indexierung, damit die Testkopie nicht bei Google erscheint und der Live-Website keine Besucher abnimmt.

Stoppuhr starten. Die Uhr lief nicht erst los, als die Wiederherstellung begann, sondern als der Inhaber sagte: „Stellen wir uns vor, die Website ist ausgefallen.“ Denn auch bei einem echten Notfall vergehen die ersten Minuten häufig mit der Suche nach Zugangsdaten.

Wiederherstellung. Das Team nahm die letzte Sicherung der Dateien und der Datenbank von dem Ort, an dem sie außerhalb des Hostings aufbewahrt wird, und spielte sie auf der Test-Subdomain ein.

Prüfung. Das Team ging die Website aus Sicht eines Käufers und eines Mitarbeiters durch:

• Startseite, Katalog, Suche und einige Produktseiten mit Fotos;
• Preise entsprechen dem Stand des Backups;
• Anmeldung im Adminbereich funktioniert;
• der Bestellvorgang erreicht den Zahlungsschritt im Testmodus, ohne echte Abbuchungen;
• das Kontaktformular sendet eine Nachricht an eine Testadresse.

Vor der Prüfung ist es wichtig, Newsletter und Kundenmails in der Testkopie abzuschalten. Sonst verschickt die wiederhergestellte Datenbank womöglich pflichtbewusst Erinnerungen an Warenkörbe, die Landwirte schon im Frühjahr stehen gelassen haben.

Protokoll. Das Team hielt vier Dinge fest: das Datum des Backups, die Gesamtzeit von „ausgefallen“ bis „funktioniert“, was nicht wiederhergestellt wurde und wer was getan hat.

Das Ergebnis war lehrreich. Das Backup selbst war in Ordnung. Vom Start bis zur funktionierenden Website vergingen aber mehr als drei Stunden: Eine Stunde suchte das Team nach der Person mit Zugang zum externen Speicher. Dann stellte sich heraus, dass die Produktfotos nicht im Archiv enthalten waren und der Schlüssel für den Zahlungsdienst erneut angefordert werden musste. Bei einer Grenze von vier Stunden liegt das noch im Rahmen, aber ohne Reserve. Nach der Übung wurden die Fotos in die Sicherung aufgenommen, die Zugänge im Passwortmanager des Unternehmens hinterlegt und die Integrationsschlüssel in einem separaten geschützten Dokument gespeichert.

Wie oft du das pro Jahr machst, entscheidest du selbst. Einmal pro Quartal und nach jeder größeren Änderung an der Website scheint mir ein vernünftiges Minimum. Eine größere Änderung kann ein Umzug, ein neues Zahlungsmodul oder der Wechsel zu einem anderen Theme oder einer anderen Plattform sein.

Wenn die Website ausfällt, möchtest du vor allem eines: so schnell wie möglich auf „Wiederherstellen“ klicken. Manchmal ist das richtig. Doch bei einem Shop gibt es eine Falle.

Wenn der Ausfall um 16:00 Uhr passiert und das Backup von 3:00 Uhr nachts stammt, überschreibt die Wiederherstellung der Datenbank alles, was in der Zwischenzeit hinzugekommen ist, selbst wenn diese Daten physisch noch auf dem Server liegen. Tu deshalb vor der Wiederherstellung drei Dinge:

1. Sichere den aktuellen Zustand, auch wenn er fehlerhaft ist. Eine Kopie der Datenbank zum Zeitpunkt des Ausfalls kann genau diese dreizehn Stunden an Bestellungen enthalten. Die Website ist möglicherweise nicht erreichbar, während die Datenbank völlig intakt ist.
2. Exportiere oder notiere neue Bestellungen. Aus dem Adminbereich, falls er funktioniert, oder aus den E-Mail-Benachrichtigungen und dem Konto des Zahlungsdienstes.
3. Stelle die Website zuerst in einer Testumgebung wieder her, wenn die Zeit es erlaubt, und übertrage sie erst danach auf die Live-Website.

Wenn ein Update den Ausfall verursacht hat, löst die Rücksetzung des Plugins oder Themes auf die vorherige Version das Problem häufig, ohne die gesamte Datenbank wiederherzustellen. Dafür brauchst du jemanden, der den Unterschied versteht. Genau deshalb ist es wichtig, schon vorher zu wissen, wer diese Person ist.

Und noch eine Gewohnheit, die besonders häufig hilft: ein frisches Backup unmittelbar vor jedem Update. Genau das empfiehlt WordPress (WordPress: Backups). Ein nächtliches automatisches Update ohne frisches Backup unmittelbar davor ist ein mutiges Experiment, bei dem du das Versuchskaninchen bist.

Ein Wiederherstellungsplan muss kein dreißigseitiges Dokument sein. Eine Seite reicht, solange du sie findest, wenn die Website nicht funktioniert. Also nicht auf der Website selbst und nicht ausschließlich in einem E-Mail-Postfach beim selben Hoster.

Auf dieser Seite steht:

• wer entscheidet, ob und aus welchem Backup wiederhergestellt wird;
• wer die Wiederherstellung technisch durchführt und wer einspringt, falls diese Person nicht verfügbar ist;
• wo die Backups liegen und wie man darauf zugreift;
• die Kontaktdaten des Hosting-Supports und die Vertrags- oder Kontonummer;
• wer die Mitarbeitenden informiert und was sie Kunden sagen, solange die Website nicht funktioniert;
• die vereinbarte Grenze für Datenverlust und die vereinbarte Wiederherstellungszeit.

Wenn dir beim Lesen dieser Liste auffällt, dass die Hälfte der Zugänge noch immer beim Dienstleister liegt, beginne mit unserer Zugangsprüfung im Artikel „Der Dienstleister ist weg. Was bleibt von deiner Website?“. Ohne Zugänge bleibt ein Wiederherstellungsplan ein guter Wunsch.

Du kannst diese Nachricht kopieren und an die Person schicken, die deine Website betreut. Die Antworten liefern dir ungefähr dasselbe Bild wie ein Probealarm, nur ohne Stoppuhr.

Wenn bei der siebten Frage erst einmal Schweigen herrscht, ist auch das eine Antwort.

Du musst nicht alles auf einmal umbauen. Hier ist eine kurze Reihenfolge:

1. Schreib zwei Zahlen auf: Wie viele Stunden an Bestellungen oder Anfragen kannst du verlieren und wie viele Stunden darf die Website ausfallen?
2. Schick die Nachricht oben ab und lass dir die Antworten schriftlich geben.
3. Stell sicher, dass mindestens eine Kopie außerhalb des Hostings liegt und einen separaten Zugang hat.
4. Leg einen Termin für den ersten Probealarm fest und starte die Stoppuhr.
5. Erstelle einen einseitigen Wiederherstellungsplan und bewahre ihn dort auf, wo man ihn auch ohne funktionierende Website findet.

Wenn du einen Blick von außen möchtest, können wir deine Website, Backups und Zugänge prüfen. Falls deine Website so überarbeitet werden muss, dass Sicherung und Wiederherstellung von Anfang an mitgedacht sind, findest du mehr auf unserer Seite zu Websites und E-Commerce.