Backups: vorhanden, vollständig, getestet

„Wir haben ein Backup" ist einer der Sätze, die im Ernstfall am häufigsten nicht stimmen. Nicht, weil gelogen wurde — sondern weil „Backup" drei verschiedene Dinge bedeuten kann, und nur eines davon hilft. Ein Backup ist erst dann eines, wenn es vorhanden ist (es wird regelmäßig erzeugt), vollständig (es enthält alles zum Wiederherstellen) und getestet (jemand hat schon einmal daraus wiederhergestellt). Am dritten Punkt scheitert es fast immer — und er ist der einzige, der im Ernstfall zählt.

Was zu einem vollständigen Backup gehört

Die WordPress-Dokumentation sagt es knapp: Ein Backup hat zwei Teile, Datenbank und Dateien, und für eine vollständige Wiederherstellung braucht man beide.

• Die Datenbank enthält alle Inhalte — Seiten, Beiträge, Einstellungen, Benutzer, Formulareinträge. Ohne sie ist die Website leer.
• Die Dateien sind WordPress selbst, das Theme, die Plugins, die Konfigurationsdatei und vor allem der Upload-Ordner mit allen Bildern und Dokumenten. Ohne sie fehlen die Gestaltung und jedes Bild.

Ein Backup mit nur einem der beiden Teile ist keins. Das kommt häufiger vor, als man denkt — etwa wenn ein Anbieter „Backups" anbietet und nur die Datenbank meint, oder wenn jemand die Dateien kopiert und die Datenbank vergessen hat. Und die Konfigurationsdatei mit den Zugangsdaten wird manchmal ausgelassen, weil sie sensible Daten enthält. Ohne sie wird die Wiederherstellung mühsam.

Wo das Backup liegen muss

Nicht nur auf demselben Server wie die Website. Das ist die wichtigste Regel und die am häufigsten verletzte. Ein Backup im selben Verzeichnis hilft genau in einem Fall: wenn man versehentlich etwas gelöscht hat. Es hilft nicht bei einem Serverausfall, bei einem gesperrten oder verlorenen Hosting-Konto, bei einem Angriff mit Serverzugriff — dann sind die Backups gleich mit betroffen — und nicht bei Verschlüsselungsschadsoftware.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt dafür die 3-2-1-Regel: drei aktuelle Versionen, auf zwei verschiedenen Medien, eine davon an einem anderen Ort. Die WordPress-Dokumentation sagt dasselbe praktischer: mehrere aktuelle Sicherungen an verschiedenen Orten, etwa eine beim Hoster, eine in einem Cloudspeicher und eine auf dem eigenen Rechner.

Für eine Unternehmenswebsite heißt die Mindestanforderung: eine automatische Sicherung auf dem Server und eine automatische Kopie woanders.

Wie oft, und wie lange aufbewahren

Wie oft hängt davon ab, wie viel Arbeit du bereit bist zu verlieren. Die WordPress-Dokumentation nennt wöchentlich für kleine Websites mit wenig Änderungen und täglich für aktive. Bei einem Shop mit laufenden Bestellungen ist täglich eher zu wenig.

Zusätzlich immer vor einem WordPress-Update, einem Theme- oder Plugin-Update, der Installation eines neuen Plugins und größeren Umbauten. Genau dort wird ein Backup am häufigsten tatsächlich gebraucht — nicht bei einem Angriff, sondern nach einem Update, das etwas kaputtgemacht hat.

Wie lange aufbewahren ist die Frage, über die kaum jemand nachdenkt, und sie hat einen konkreten Grund: Angriffe werden oft spät entdeckt. IBM misst in seinem jährlichen Bericht zu Datenpannen für 2025 im Schnitt 181 Tage, bis ein Einbruch überhaupt bemerkt wird. Wer nur die letzten drei Tage aufbewahrt, hat im Ernstfall womöglich drei bereits befallene Sicherungen.

Ein bewährter Arbeitswert für Unternehmenswebsites sind 30 Tage, besser länger. Die Aufteilung: auf dem Server nur wenige Tage, die lange Aufbewahrung am zweiten Ort — dort ist Speicherplatz günstiger und stört den Betrieb nicht.

Der Punkt, an dem es scheitert: der Wiederherstellungstest

Ein Backup, aus dem noch nie jemand wiederhergestellt hat, ist eine Vermutung. Das BSI macht daraus in seinem IT-Grundschutz eine Basis-Anforderung: Es muss regelmäßig getestet werden, ob sich die gesicherten Daten einwandfrei und in angemessener Zeit zurückspielen lassen.

Was in der Praxis schiefgeht:

• Die Datei ist beschädigt und lässt sich nicht entpacken.
• Die Sicherung läuft seit Monaten mit einem Fehler, den niemand gesehen hat, weil niemand die Meldungen liest.
• Der Upload-Ordner war ausgenommen, weil er „zu groß" war.
• Die Datenbank ist da, die Konfigurationsdatei fehlt.
• Alles ist vollständig — aber niemand weiß, wie man es einspielt, und im Ernstfall ist keine Zeit, es zu lernen.

Der ehrliche Test: Sicherung auf einer Testumgebung einspielen, Startseite aufrufen, ins Backend einloggen, ein paar Unterseiten ansehen, ein Formular abschicken, prüfen, ob die Bilder da sind. Wenn das funktioniert, hast du ein Backup.

Der schnelle Test dazwischen: Nachsehen, ob die letzte Sicherung existiert, wann sie erzeugt wurde und wie groß sie ist. Eine Sicherung, die plötzlich ein Zehntel der üblichen Größe hat, ist ein Alarmzeichen.

Was du im Ernstfall brauchst

Der Ernstfall ist kein guter Zeitpunkt, um Dinge zu suchen. Diese Angaben gehören an einen Ort, der unabhängig von der Website erreichbar ist:

• Zugang zum Hoster — Kundennummer, Login, Ansprechpartner
• Zugang zum Domainverwalter, falls das ein anderer ist
• Zugang zum Speicherort der Backups
• Zugangsdaten für Datenbank und Dateizugriff
• eine kurze Anleitung, in welcher Reihenfolge wiederhergestellt wird
• wer wen anruft

Das klingt bürokratisch. Es ist der Unterschied zwischen zwei Stunden und zwei Tagen.

Die Reihenfolge beim Wiederherstellen

In groben Zügen — die Einzelheiten macht in aller Regel jemand, der das kennt:

1. Website in den Wartungsmodus setzen oder vom Netz nehmen, damit kein weiterer Schaden entsteht.
2. Vorher den kaputten Zustand sichern. Das klingt widersinnig und ist wichtig: Geht bei der Wiederherstellung etwas schief, ist der kaputte Stand besser als keiner — und nach einem Angriff braucht man ihn womöglich zur Aufklärung.
3. Dateien wiederherstellen.
4. Datenbank wiederherstellen.
5. Zugangsdaten in der Konfigurationsdatei prüfen.
6. Prüfen: Startseite, wichtigste Unterseiten, Formulare, Bilder, Backend.
7. Nach einem Angriff alle Passwörter ändern.

Und danach fragen, warum es passiert ist. Eine Wiederherstellung ohne Ursachensuche führt dazu, dass dasselbe bald wieder passiert — besonders nach einem Angriff, bei dem die Lücke ja weiter offen ist.

Was Hoster-Backups leisten und was nicht

Fast jeder Hoster wirbt mit Backups. Das ist gut und ersetzt keine eigene Lösung. Drei Fragen dazu:

• Wie weit reichen sie zurück? Oft sind es sieben oder vierzehn Tage — für einen spät entdeckten Angriff zu wenig.
• Kannst du selbst wiederherstellen, oder musst du fragen? Läuft es über ein Ticket, kann es am Wochenende dauern.
• Kannst du einzelne Dinge zurückholen oder nur den ganzen Stand?

Und der grundsätzliche Einwand: Die Sicherung liegt beim selben Anbieter wie die Website. Geht dort etwas grundsätzlich schief, ist beides betroffen. Hoster-Backups sind eine Bequemlichkeit, die eigene Sicherung an einem anderen Ort ist die Absicherung.

Fünf Fragen, die du heute beantworten kannst

1. Wann wurde die letzte Sicherung erzeugt?
2. Wo liegt sie?
3. Enthält sie Datenbank und Dateien?
4. Wie weit reichen die Sicherungen zurück?
5. Wann hat zuletzt jemand daraus wiederhergestellt?

Kannst du eine davon nicht beantworten, ist das der erste Arbeitsschritt. Und ein praktischer Blick: Die letzten fünf Sicherungen sollten ungefähr gleich groß sein und mit dem Inhalt wachsen. Ein plötzlicher Einbruch heißt, dass etwas nicht mitgesichert wurde.

Was zu tun ist

1. Den Ist-Zustand klären — die fünf Fragen oben.
2. Für eine Kopie außer Haus sorgen. Wenn du nur eine Sache änderst, dann diese.
3. Die Aufbewahrung verlängern, auf mindestens 30 Tage.
4. Einen Wiederherstellungstest machen. Einmal — danach weißt du, ob du ein Backup hast oder eine Hoffnung.
5. Die Prüfung in die laufende Wartung aufnehmen: monatlich, ob die Sicherung läuft und vollständig ist, und stichprobenartig, ob sie sich einspielen lässt.
6. Die Notfallmappe anlegen — Zugänge und Reihenfolge, außerhalb der Website.

Von allen Punkten in der laufenden Betreuung ist das der einzige, bei dem ein Versäumnis nicht zu einer schlechteren Website führt, sondern zu gar keiner. Alles andere lässt sich nachholen. Verlorene Daten nicht.

Quellen

• WordPress Advanced Administration, WordPress-Backups — Datenbank und Dateien, Häufigkeit, Kopien an mehreren Orten: developer.wordpress.org
• BSI, Vorschläge zu Business-Continuity-Strategien (Hilfsmittel zum Standard 200-4) — die 3-2-1-Regel: bsi.bund.de
• BSI, IT-Grundschutz-Baustein CON.3 Datensicherungskonzept — CON.3.A15 Regelmäßiges Testen der Datensicherungen: bsi.bund.de
• IBM, Cost of a Data Breach Report 2025 — im Schnitt 181 Tage bis zur Entdeckung: ibm.com