Zum Hauptinhalt springen

Werkstattbericht · Backup

WordPress-Backups testen:
wenn der Test lügt

Zwei Monate lang meldete ein automatisierter Wiederherstellungstest regelmäßig defekte Websites. Elf Meldungen über acht verschiedene Installationen. Am Ende der Ursachensuche stand ein Ergebnis, das ich so nicht erwartet hatte: keine einzige davon war ein kaputtes Backup, und keine war eine kaputte Website. Alle elf kamen aus dem Testaufbau selbst.

Restore-Tests werden dadurch nicht überflüssig. Ihr Ergebnis gehört aber als Hypothese gelesen, solange es nicht gegengeprüft ist. Dieser Text beschreibt die zwei Ursachen, die dahintersteckten, und die Regeln, die sich daraus ableiten lassen.

Ausgangslage

Ein Backup ist eine Behauptung

Solange eine Sicherung nicht wiederhergestellt wurde, ist sie eine Datei mit einer Vermutung darüber, was drinsteht. Die Liste der Dinge, die dabei schiefgehen können, ist länger als sie sein sollte: Ein Datei-Archiv wird unvollständig übertragen. Eine Passphrase wurde nach dem letzten Vollbackup rotiert, das ältere Set bleibt damit dauerhaft unlesbar. Datenbank und Dateien stammen aus zwei verschiedenen Sicherungsläufen und passen inhaltlich nicht zusammen.

Keiner dieser Fälle fällt beim Erstellen auf. Alle fallen beim Wiederherstellen auf, und wer das nie tut, erfährt davon im Ernstfall.

Für Dienstleister kommt eine rechtliche Seite dazu. Artikel 32 der Datenschutz-Grundverordnung verlangt in Absatz 1 lit. d ausdrücklich ein Verfahren zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit technischer Schutzmaßnahmen. Ein nie geprüftes Backup erfüllt das nicht. Es ist eine Maßnahme ohne Bewertung.

Aufbau

Wie ein automatisierter Test aussieht

Der Ablauf ist unspektakulär. Ein Cron-Job wählt nachts eine Website aus einer Rotation, holt deren neueste Sicherung vom Backup-Speicher, entschlüsselt sie und spielt sie in eine frisch gestartete, vom Netz abgeschottete Container-Umgebung ein: eine Datenbank, ein Webserver mit PHP, sonst nichts. Danach wird die Startseite aufgerufen und geprüft, ob sie ausliefert.

Das Ergebnis ist dreistufig, und diese Abstufung ist der wichtigste Teil des ganzen Aufbaus. Bestanden heißt: entschlüsselt, importiert, Website rendert. Fehlgeschlagen heißt: Das Backup ließ sich nicht wiederherstellen, hier liegt ein echtes Backup-Problem. Warnung heißt: Das Backup ist in Ordnung, aber die wiederhergestellte Website zeigt einen Fehler.

Genau diese dritte Stufe hat zwei Monate lang das Falsche gemeldet.

Ursache 1

Ein Wettlauf beim Containerstart

Das offizielle WordPress-Container-Image kopiert den Programmkern erst beim Start in das Zielverzeichnis und legt danach die Konfigurationsdatei an. Das dauert je nach Datenmenge und Systemlast unterschiedlich lang. Der Testaufbau wartete zwar auf den Container, aber nur darauf, dass er läuft. Ohne eigene Bereitschaftsprüfung ist dieser Zustand sofort erreicht, lange bevor WordPress tatsächlich fertig entpackt ist.

Die unmittelbar danach abgesetzten Kommandozeilenbefehle liefen deshalb manchmal in ein halb initialisiertes Verzeichnis und brachen ab. Das allein wäre harmlos gewesen. Das eigentliche Problem war, dass sie mit einem angehängten || true abgesichert waren und ihre Fehlerausgabe verworfen wurde. Der Abbruch geschah also lautlos.

Übersprungen wurden dabei ausgerechnet die zwei Schritte, die den Test aussagekräftig machen: das Umschreiben der Domain in der Datenbank und das Abschalten der Caching-Erweiterungen. Deren Konfigurationsdateien blieben aktiv, zeigten in der Testumgebung ins Leere und rissen die Seite in einen Fehler.

Weil das Ergebnis vom Kopiertempo abhing, meldete dieselbe Website mal Erfolg und mal Fehler. Diese Sprunghaftigkeit war das Signal, das die ganze Zeit sichtbar war und trotzdem niemand gelesen hat.

Ursache 2

Die Testumgebung prüfte eine andere PHP-Version

Der zweite Fall war deterministisch: Eine Shop-Installation meldete bei jedem Durchlauf denselben Fehler. Die Ursache lag in einer festen Zeile der Container-Konfiguration, die immer PHP 8.3 startete, unabhängig davon, worauf die Website tatsächlich läuft. Der Datenbankexport verrät die echte Version im Kopfbereich, und die lag hier bei PHP 7.4.

Der Unterschied wurde an einer defekten deutschen Übersetzung sichtbar. In der Sprachdatei war eine Formatierungsanweisung verstümmelt, aus Alle %s war Alle % geworden. Unter PHP 7.4 erzeugt das eine Warnung, die niemand sieht. Ab PHP 8.0 ist derselbe Aufruf ein schwerer Fehler, der die Seite abbricht.

Die Testumgebung prüfte damit nicht das Backup, sondern eine hypothetische PHP-Migration. Sie alarmierte für einen Fehler, den es im Ist-Zustand der Website nicht gibt.

Der naheliegende Fix erwies sich als Verschlimmbesserung. Die offiziellen Images koppeln PHP- und WordPress-Version fest aneinander: Das Image mit der passenden PHP-Version brachte einen vier Jahre alten Programmkern mit, unter dem erwartungsgemäß andere Erweiterungen scheiterten. Ein Mismatch gegen einen anderen getauscht. Umgesetzt wurde am Ende die konservative Variante: PHP wird nur angeglichen, solange der Programmkern gleich bleibt, und die verbleibende Abweichung steht im Ergebnis.

Was daraus folgt

Vier Regeln für Prüfsysteme

  1. 01

    Schwankende Ergebnisse sind ein Werkzeugproblem

    Ein defektes Backup wird zwischen zwei Durchläufen nicht heil, eine kaputte Website nicht ganz. Meldet dieselbe Prüfung heute Erfolg und morgen Fehler, liegt die Ursache im Prüfsystem. Diese Unterscheidung spart Tage.

  2. 02

    Fehler unterdrücken nur, wo sie das Ergebnis nicht ändern

    Ein || true an einem Schritt, der die Aussagekraft des Tests trägt, ist kein Robustheitsmerkmal. Es macht blind. Der Test läuft scheinbar sauber durch und liefert ein wertloses Ergebnis, was schlechter ist als ein sichtbarer Abbruch.

  3. 03

    Abweichungen der Testumgebung gehören ins Ergebnis

    Eine Sandbox bildet die Produktivumgebung nie vollständig ab. Solange die bekannten Unterschiede im Ergebnis stehen, bleibt eine Meldung lesbar. Steht dort nur „Fehler", ist jede Abweichung ununterscheidbar von einem echten Schaden. Ein Ergebnis sollte entweder grün sein oder erklärt.

  4. 04

    Vor der Kundenmeldung 30 Sekunden gegenprüfen

    Ein einzelner Aufruf der echten Website beantwortet die Frage, ob der Alarm überhaupt plausibel ist. Antwortet sie normal, ist die Meldung ein Werkzeugartefakt. Diese halbe Minute verhindert Anrufe bei Kunden, die kein Problem haben.

Was der Test am Ende beweist

Nach zwei Monaten Betrieb und der Aufräumaktion lautet die ehrliche Bilanz: Jede untersuchte Warnung war ein Fehler im Prüfsystem, keine ein Schaden am Backup oder an einer Website. Das könnte man als Argument gegen den Aufwand lesen. Dagegen spricht die Erfahrung aus diesen zwei Monaten: Ein Prüfsystem, das nie etwas meldet, wurde meist nur nie scharf genug eingestellt, um etwas zu finden.

Was bleibt, ist eine Aussage, die vorher nicht möglich war: Für jede betreute Website liegt ein dokumentiertes, datiertes Ergebnis vor, ob sich ihre Sicherung wiederherstellen lässt. Nicht behauptet, sondern gemessen.

Wartung mit Restore-Tests Was Wartung kostet

Häufige Fragen

Kurz beantwortet

Warum reicht es nicht, Backups nur zu erstellen?
Weil beim Erstellen niemand prüft, ob sich daraus wieder eine lauffähige Website machen lässt. Sicherungen können unvollständig sein, mit einer alten Passphrase verschlüsselt oder aus zwei verschiedenen Läufen zusammengesetzt. Auffallen tut das erst beim Wiederherstellen, also im schlechtesten Fall im Ernstfall.
Wie oft sollte man eine Wiederherstellung testen?
Sinnvoll ist ein rotierender Turnus, bei dem jede Website mindestens monatlich an die Reihe kommt. Ein einmaliger Test nach der Einrichtung sagt wenig aus, weil sich Backup-Zeitpläne, Passphrasen und Datenmengen im Betrieb ändern.
Was verlangt die DSGVO zu Backups?
Artikel 32 Absatz 1 lit. d verlangt ein Verfahren zur regelmäßigen Überprüfung und Bewertung der Wirksamkeit technischer Schutzmaßnahmen. Ein Backup, das nie wiederhergestellt wurde, ist eine unbewertete Maßnahme. Für Auftragsverarbeiter ist das im Schadensfall ein Haftungsthema.
Kann eine Testumgebung die Live-Umgebung vollständig abbilden?
Nein, und das ist der häufigste Grund für falschen Alarm. Webserver-Kontext, PHP-Version, Datenbank-Engine und externe Dienste weichen fast immer ab. Jede dieser Abweichungen kann einen Fehler erzeugen, den es auf der echten Website nicht gibt.
Woran erkennt man einen Fehler im Testaufbau statt im Backup?
Am einfachsten daran, ob das Ergebnis schwankt. Meldet dieselbe Website mal Erfolg und mal Fehler, ohne dass sich etwas geändert hat, liegt es am Testaufbau. Ein defektes Backup und eine kaputte Website kippen nicht zwischen zwei Durchläufen.

Verfasst von Mario Knebl, Kaevo, Gallneukirchen. Zuletzt aktualisiert am . Der beschriebene Aufbau läuft im eigenen Betrieb; betroffene Websites sind bewusst nicht benannt.