Ein Backup, das es nicht gibt
Die Sicherung läuft jede Nacht, das Plugin meldet Erfolg, die Liste im Backend ist durchgehend grün. Wer sein WordPress Backup prüfen will, schaut genau dorthin – und bekommt eine beruhigende Antwort. Nur beschreibt diese Antwort etwas anderes als das, was eigentlich interessiert: Sie sagt, was das Plugin selbst mitbekommen hat. Nicht, ob irgendwo eine Datei liegt.
Es gibt zwei Arten von Backup-Problemen. Die laute Art meldet sich. Eine Fehlermail kommt an, der Lauf steht als gescheitert in der Übersicht, jemand kann reagieren. Die stille Art meldet sich nicht. Sie hinterlässt eine grüne Liste, einen leeren Posteingang und keine Sicherung. Bemerkt wird sie in dem Moment, in dem man sie braucht.
1. Warum ein abgebrochener Lauf keine Fehlermeldung erzeugt
Ein Backup-Plugin kann eine 50-GB-Website nicht in einem Durchgang packen. PHP bricht jeden Vorgang nach einer festgelegten Zeit ab, meist nach fünf Minuten. Deshalb arbeiten die Plugins in Scheiben: ein Stück packen, Zwischenstand merken, beim nächsten Aufruf weitermachen. Dass dabei ein Zeitlimit erreicht wird, ist der Normalfall und kein Fehler.
Interessant ist, was passiert, wenn der Prozess nicht nur unterbrochen wird, sondern mitten im Schreiben stirbt – weil der Speicher nicht reicht, die Platte voll ist oder der Prozess vom Server abgeräumt wird. Dann nimmt niemand den Faden wieder auf. Und weil der Lauf nie zu einem Ende kommt, schließt er auch keinen Bericht ab.
Kein Bericht heißt in der Praxis: kein Eintrag in der Übersicht, kein Fehlerstatus, keine Mail. Der Lauf verschwindet aus der Aufgabenliste, seine halbfertigen Dateien bleiben liegen. In der Berichtsliste stehen danach weiterhin nur die Läufe, die ordentlich durchgelaufen sind – alle grün.
2. Ein Fall aus der Praxis
Vor einigen Wochen kam eine Website neu in unsere Wartung. Eine über Jahre gewachsene Seite mit sehr vielen Bildern, rund 50 GB groß, technisch unauffällig. Ein bekanntes Backup-Plugin war installiert, ein Zeitplan eingerichtet, als Ziel ein externer Speicher hinterlegt. Auf dem Papier alles richtig gemacht.
Zu einer Übernahme gehört bei uns, dass wir nicht ins Backend schauen, sondern in den Zielordner. Das Backend hätte auch nichts zu berichten gehabt: Die Liste der letzten Läufe zeigte zehn Einträge, alle zehn mit dem Status erfolgreich. Kein Fehler, keine Warnung, keine offene Benachrichtigung.
Im Zielordner sah es anders aus. Die Datenbank kam jede Nacht zuverlässig an, daran lag es nicht. Die wöchentliche Voll-Sicherung der Dateien dagegen fehlte an drei Terminen hintereinander. Auf dem Server selbst lagen 279 GB unvollständige Reste aus vier abgebrochenen Anläufen, der älteste vier Wochen alt. Keiner dieser vier Läufe stand in der Berichtsliste, keiner hatte eine Mail ausgelöst.
Hätte in diesen Wochen jemand die Seite wiederherstellen müssen, wäre die Datenbank da gewesen. Die Bilder nicht – und damit praktisch der gesamte Inhalt.
| Was die Einstellung sagt | Was die Messung zeigt | Warum beides auseinanderfällt |
|---|---|---|
| Zeitplan: täglich | Dateien nur jeden zweiten Tag | Die geplante Aufgabe kommt nicht durch |
| Alle Läufe erfolgreich | Drei Nächte ohne Sicherung | Abgebrochene Läufe werden nicht protokolliert |
| Lokale Kopien werden gelöscht | 279 GB Reste auf der Platte | Das Löschen hängt am erfolgreichen Upload |
3. Drei Stellen, an denen eine Sicherung still ausfällt
Der zweite Punkt ist der tückischste, weil an der Website selbst nichts auffällt. WordPress löst geplante Aufgaben normalerweise beim Seitenaufruf aus. Auf gut betreuten Servern wird das abgeschaltet und durch eine echte Server-Aufgabe ersetzt, die unabhängig von Besuchern läuft – das ist die bessere Lösung und der Grund, warum Sicherungen nachts um zwei starten können.
Diese Server-Aufgabe hat allerdings eigene Einstellungen, unter anderem eine eigene PHP-Version. Die hat nichts mit der Version zu tun, mit der die Website ausgeliefert wird. Steht dort eine Version, die die Installation längst nicht mehr unterstützt, scheitert die Aufgabe beim Start – und zwar lautlos. Die Website läuft weiter, das Backend sieht normal aus, im Zeitplan steht alles richtig. Es passiert nur nichts mehr.
Wichtig zu wissen:
Wenn Sicherungen zu wandernden Uhrzeiten eintreffen und einzelne Tage fehlen, ist das kein Zufall und keine Serverlast. Es ist das Erkennungszeichen einer geplanten Aufgabe, die nicht mehr zuverlässig startet. Von außen sieht man es nur, wenn man die Zeitstempel über mehrere Tage nebeneinanderlegt.
4. Vier Fragen, die ein WordPress Backup wirklich prüfen
Keine dieser Fragen lässt sich im Einstellungsdialog beantworten. Alle vier zielen auf einen Zustand, nicht auf eine Absicht – und der Unterschied ist genau das Problem. Die Einstellung beschreibt, was passieren soll. Sie sagt nichts darüber, ob es passiert ist.
Besonders die dritte Frage wird unterschätzt. Eine Sicherung, die auf derselben Maschine liegt wie die Website, hilft bei einem Serverausfall nicht und bei einem Einbruch erst recht nicht – Verschlüsselungs-Schadsoftware sucht gezielt nach Backup-Ordnern. Die offizielle WordPress-Dokumentation zu Backups nennt die räumliche Trennung als Grundanforderung, nicht als Komfortfunktion.
Und die vierte Frage ist die, die am häufigsten unbeantwortet bleibt. Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Ob das Archiv lesbar ist, ob die Datenbank zum Dateistand passt, ob am Ende eine funktionierende Website herauskommt – das weiß man erst nach einem Versuch. Am besten nicht im Ernstfall.
Zum Merken:
Eine Konfiguration ist eine Absicht, kein Zustand. Ob eine Sicherung ankommt, entscheidet sich im Zielordner – nicht auf der Einstellungsseite und nicht in der Berichtsliste.
5. Was das für den laufenden Betrieb heißt
Die Prüfung selbst ist keine große Sache. Jemand muss sie nur regelmäßig machen, und zwar am Ziel statt im Backend. Technisch heißt das: Zugriff auf den Backup-Speicher, Kenntnis der erwarteten Zeitpläne und ein Blick auf den Server, um die Reste gescheiterter Läufe zu finden, von denen das Plugin nichts weiß.
Deshalb gehört die Ankunftsprüfung bei uns zur Routine. Wir sehen nach, ob für jede betreute Installation eine frische Sicherung am Zielort liegt, ob sie vollständig ist, und ob auf dem Server Fragmente abgebrochener Läufe liegen geblieben sind. Dazu prüfen wir, ob die geplanten Aufgaben überhaupt noch durchkommen – der Punkt, der sich aus der Konfiguration grundsätzlich nicht ablesen lässt.
Was ein Ausfall kostet, wenn eine Website wiederhergestellt werden muss und das Backup nicht trägt, haben wir an anderer Stelle durchgerechnet: Was kostet eine Downtime wirklich. Die kurze Antwort: deutlich mehr als die Wartung, die den Fall verhindert hätte.
Fazit:
Ein Backup-Plugin zu installieren und einen Zeitplan zu setzen, ist der erste Schritt und der einfachste. Was danach fehlt, ist jemand, der nachsieht. Eine grüne Berichtsliste und ein leerer Posteingang belegen nicht, dass Sicherungen ankommen – sie belegen nur, dass nichts gemeldet wurde. Das ist nicht dasselbe.
