WordPress-Wiederherstellung testen: Restore-Probe auf einer Testinstanz Schritt für Schritt

Ein Backup, das nie zurückgespielt wurde, ist eine Annahme. Ob die Datenbank vollständig ist, ob die Uploads im Archiv stecken und wie lange die Wiederherstellung dauert, zeigt erst eine Restore-Probe. Diese Anleitung spielt ein WordPress-Backup auf eine getrennte Testinstanz zurück, passt die Adresse an, prüft das Ergebnis und hält fest, was dabei auffiel. Den kompletten Ablauf haben wir in einer Testumgebung mit WordPress 7.1.2 und WP-CLI 2.12.0 durchgespielt, inklusive der dabei aufgetretenen Fehlermeldungen.

Voraussetzungen

• Ein vollständiges Backup der Live-Website: Datenbank-Dump als SQL-Datei und ein Archiv des Ordners wp-content, möglichst mit Prüfsummendatei
• Eine getrennte Testinstanz mit eigener, leerer Datenbank und eigener Adresse: Subdomain beim Hoster, lokaler Rechner oder eigener Testserver
• Auf der Testinstanz dieselbe WordPress-Hauptversion wie live (hier 7.1.2) und eine passende PHP-Version (Test: PHP 8.4)
• SSH-Zugang zur Testinstanz mit WP-CLI; ohne SSH geht es mit dem Restore-Werkzeug Ihres Backup-Plugins, die Prüfschritte bleiben gleich
• Zugangsdaten eines Administratorkontos der Live-Website, denn nach dem Import gelten deren Benutzer
• Etwa eine Stunde Zeit beim ersten Durchlauf

Schritt 1: Testinstanz vorbereiten und strikt trennen

Der wichtigste Grundsatz: Die Restore-Probe darf die Live-Website nie berühren. Das klingt selbstverständlich, doch in der Praxis entstehen Schäden vor allem durch eine falsche wp-config.php. Zeigt die Testinstanz auf die Datenbank der Live-Website, überschreibt der Import die echten Daten. Kontrollieren Sie deshalb in der wp-config.php der Testinstanz DB_NAME, DB_USER und DB_HOST, bevor Sie irgendetwas importieren.

Die Testinstanz braucht eine laufende WordPress-Installation mit Kerndateien und wp-config.php. Die Kerndateien müssen Sie nicht aus dem Backup holen; sie lassen sich jederzeit neu von wordpress.org laden und werden im letzten Schritt ohnehin per Prüfsumme kontrolliert. Wichtig ist der Tabellenpräfix: Er muss mit dem der Live-Website übereinstimmen. Sie finden ihn im Dump in den Tabellennamen, etwa wp_options, und in der Testinstanz so:

wp config get table_prefix

Tragen Sie außerdem den Umgebungstyp ein. Viele Plugins erkennen ihn und schalten dann zum Beispiel Zahlungsanbieter in den Testmodus oder unterlassen E-Mails an Kunden. Verlassen Sie sich darauf aber nicht blind, sondern prüfen Sie das bei Ihren eigenen Plugins.

wp config set WP_ENVIRONMENT_TYPE staging
wp eval 'echo wp_get_environment_type();'

Verifizieren: Die Ausgabe lautet staging, und DB_NAME in der Testinstanz unterscheidet sich eindeutig vom Datenbanknamen der Live-Website.

Schritt 2: Backup-Dateien holen und auf Unversehrtheit prüfen

Holen Sie das Backup genau von dem Ort, von dem Sie es im Ernstfall holen würden: vom externen Speicher, nicht von einer Kopie auf dem Webserver. Nur so testen Sie auch die Frage, ob Sie im Notfall überhaupt an die Dateien kommen, mit welchen Zugangsdaten und wie lange der Download dauert.

Liegt dem Backup eine Prüfsummendatei bei, kontrollieren Sie damit, ob die Dateien beim Speichern oder Übertragen beschädigt wurden. So legen Sie eine solche Datei beim Sichern an und prüfen sie später:

# beim Sichern
sha256sum db.sql wp-content.tar.gz > SHA256SUMS

# bei der Restore-Probe
sha256sum -c SHA256SUMS

Im Test lautete die Ausgabe db.sql: OK und wp-content.tar.gz: OK. Um den Fehlerfall zu zeigen, haben wir eine Zeile an den Dump angehängt; dann meldete der Befehl db.sql: FAILED und WARNING: 1 computed checksum did NOT match. Eine solche Datei verwenden Sie nicht, sondern greifen auf das vorherige Backup zurück und klären die Ursache.

Werfen Sie außerdem einen Blick in die Größe und den Anfang des Dumps. Eine SQL-Datei von wenigen Kilobyte bei einer Website mit Hunderten Beiträgen ist ein Warnsignal, ebenso eine Datei, die mit einer Fehlermeldung statt mit SQL-Befehlen beginnt.

Verifizieren: sha256sum -c meldet für jede Datei OK, und die Dateigrößen liegen im Bereich früherer Backups.

Schritt 3: wp-content und Datenbank zurückspielen

Sichern Sie auch die Testinstanz vorher, falls sie Daten enthält, die Sie behalten wollen. Dann ersetzen Sie den Ordner wp-content durch den Inhalt des Archivs. Im Testordner der Instanz, also im WordPress-Hauptverzeichnis:

rm -rf wp-content
tar -xzf /pfad/zum/backup/wp-content.tar.gz
chown -R www-data:www-data wp-content

Der Benutzer www-data gilt für Debian und Ubuntu mit Apache oder Nginx; bei anderen Systemen und bei Hostern heißt der Webserver-Benutzer anders. Ohne passende Rechte kann WordPress später keine Medien hochladen und keine Updates schreiben.

Danach leeren Sie die Datenbank der Testinstanz und importieren den Dump. wp db reset löscht alle Tabellen der in wp-config.php eingetragenen Datenbank, deshalb die Kontrolle aus Schritt 1 unmittelbar davor wiederholen:

wp config get DB_NAME
wp db reset --yes
wp db import /pfad/zum/backup/db.sql

Im Test meldete der Import Success: Imported from 'bk/db.sql'. Direkt danach zeigt die Website noch auf die Adresse der Live-Website:

wp option get siteurl

Die Ausgabe lautete im Test https://www.example.com, also die Adresse der Quelle. Rufen Sie die Testinstanz jetzt im Browser auf, leitet WordPress Sie deshalb auf die Live-Website weiter. Das behebt der nächste Schritt.

Verifizieren: wp core is-installed beendet sich ohne Fehler (Exit-Code 0), wp option get siteurl liefert die Adresse der Live-Website.

Schritt 4: Adresse umstellen und Testinstanz abschirmen

WordPress speichert die Adresse nicht nur in den Einstellungen, sondern auch in Beitragsinhalten, Menüs, Widget-Einstellungen und Plugin-Optionen. Viele dieser Werte sind serialisiert, also mit Längenangaben gespeichert. Eine einfache Ersetzung per SQL oder Texteditor verändert die Länge der Zeichenkette, ohne die Längenangabe anzupassen, und zerstört damit Einstellungen. wp search-replace berücksichtigt das. Starten Sie immer mit einem Probelauf:

wp search-replace 'https://www.example.com' 'https://test.example.com' --all-tables --dry-run
wp search-replace 'https://www.example.com' 'https://test.example.com' --all-tables --precise

Ersetzen Sie die Beispieladressen durch Ihre eigenen, jeweils ohne Schrägstrich am Ende und mit dem richtigen Protokoll. Der Probelauf meldete im Test Success: 10 replacements to be made., die echte Ersetzung änderte anschließend die gleichen Stellen. Danach leeren Sie Cache und Permalinks:

wp cache flush
wp rewrite flush

Schirmen Sie die Testinstanz nun ab. Unter Einstellungen > Lesen setzen Sie den Haken bei „Suchmaschinen davon abraten, diese Website zu indexieren“ und klicken „Änderungen speichern“, oder per WP-CLI:

wp option update blog_public 0

Im Test lieferte die Startseite danach <meta name='robots' content='noindex, nofollow' />. Das ist eine Bitte an Suchmaschinen, kein Zugriffsschutz. Eine Kopie mit echten Kundendaten gehört zusätzlich hinter einen Passwortschutz auf Webserver-Ebene oder ist nur intern erreichbar. Denken Sie daran, dass die Testinstanz personenbezogene Daten enthält: Nach der Probe löschen Sie sie wieder.

Verifizieren: wp option get home zeigt die Adresse der Testinstanz, im Quelltext der Startseite steht noindex, nofollow.

Schritt 5: Ergebnis prüfen und protokollieren

Jetzt zeigt sich, ob das Backup taugt. Prüfen Sie mindestens diese Punkte, idealerweise nach einer festen Liste, damit die Proben vergleichbar bleiben:

Im Test waren alle Tabellen in Ordnung, der vor dem Backup angelegte Beitrag „Restore-Probe“ war vorhanden, sein interner Link zeigte auf die neue Adresse, und eine Testdatei aus dem Upload-Ordner lieferte Status 200. Achten Sie besonders auf den jüngsten Inhalt: Er zeigt, wie viel Arbeit bei einer echten Wiederherstellung verloren wäre.

Notieren Sie im Protokoll das Datum des Backups, die Dauer von Download bis funktionierender Seite, alle Auffälligkeiten und die daraus folgenden Maßnahmen. Die gemessene Dauer ist der realistische Wert für Ihre Ausfallplanung. Löschen Sie danach Testinstanz und heruntergeladene Backup-Dateien. Wie Sie solche Proben als feste Routine im Unternehmen verankern, beschreibt die Anleitung Backup-Restore-Test als feste Routine etablieren.

Eine Restore-Probe ist keine einmalige Aufgabe. Plugins ändern ihre Tabellen, Backup-Ziele laufen voll, Zugangsdaten verfallen. Deshalb gehört die Probe regelmäßig in den Wartungsplan für WordPress, mindestens einmal im Quartal und nach jeder Änderung am Backup-Verfahren. Wer die laufende Sicherung nicht selbst organisieren möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt wöchentliche Backups auf externen Speicher mit vier Wochen Aufbewahrung sowie Updates von WordPress, Plugins und Themes.

Verifizieren: Alle Punkte der Tabelle sind erfüllt, das Protokoll enthält Backup-Datum und gemessene Dauer, die Testinstanz ist gelöscht.

Typische Fehler

„Your table prefix is 'xy_'. Found installation with table prefix: wp_.“: Diese Meldung erschien im Test, als der Präfix in der wp-config.php der Testinstanz nicht zum Dump passte. WP-CLI meldete zusätzlich Error: The site you have requested is not installed. Setzen Sie den Präfix mit wp config set table_prefix wp_ auf den Wert aus dem Dump.

Weiterleitung auf die Live-Website: Die Adresse wurde noch nicht umgestellt. Führen Sie Schritt 4 aus. Kommen Sie gar nicht an die Testinstanz heran, erledigen Sie das per WP-CLI, ohne Browser.

Kaputte Widgets, leere Menüs, verlorene Plugin-Einstellungen: Die Adresse wurde per SQL oder Texteditor ersetzt, und serialisierte Werte sind beschädigt. Importieren Sie den Dump erneut und nutzen Sie wp search-replace.

„FAILED“ bei sha256sum -c: Die Backup-Datei ist beschädigt oder verändert. Nutzen Sie das vorherige Backup und prüfen Sie Übertragung und Speicherziel.

Medien fehlen, Beiträge sind da: Das Archiv enthält wp-content/uploads nicht, häufig durch Ausschlussregeln im Backup-Plugin, die Speicherplatz sparen sollen. Das ist der typische Befund, den nur eine Restore-Probe aufdeckt.

Häufige Fragen

Warum nicht einfach das Restore-Werkzeug des Backup-Plugins nutzen?

Das können Sie, sofern es auf eine Testinstanz zurückspielen kann. Der manuelle Weg hat einen Vorteil: Er funktioniert auch dann, wenn die Website nicht mehr startet und das Plugin nicht erreichbar ist. Mindestens einmal sollten Sie ihn deshalb geübt haben.

Darf die Testinstanz auf demselben Server laufen?

Ja, mit eigener Datenbank, eigenem Verzeichnis und eigener Adresse. Getrennter Speicher ist aber aussagekräftiger, denn im Ernstfall ist der Live-Server oft genau das, was fehlt.

Was mache ich mit E-Mails aus der Testinstanz?

Formulare, Shop und Newsletter können aus der Kopie echte Kunden anschreiben. Leiten Sie ausgehende E-Mails auf der Testinstanz um oder unterbinden Sie sie, bevor Sie Formulare ausprobieren.

Testumfang

Wir haben den Ablauf am 30.09.2026 mit WordPress 7.1.2 in einer isolierten Testumgebung durchgespielt, mit einer simulierten Live-Website als Quelle. Geprüft haben wir vor allem Import und Adressersetzung per wp search-replace, außerdem den Fehler, der bei einem falschen Tabellenpräfix auftritt. Nicht geprüft haben wir die Wiederherstellung über einzelne Backup-Plugins und die Rechtevergabe bei Hostern. Testen Sie diese Punkte deshalb zuerst auf einer Kopie Ihrer Website.

Fazit

Eine Restore-Probe beantwortet die einzige Frage, die bei Backups zählt: Kommt die Website daraus vollständig zurück, und wie lange dauert das? Mit getrennter Testinstanz, Prüfsummen, wp db import, wp search-replace und einer festen Prüfliste ist sie in einer Stunde erledigt. Planen Sie die Probe regelmäßig ein und protokollieren Sie die Dauer. Wenn Sie die wöchentlichen Backups selbst nicht betreuen möchten, übernimmt die WordPress-Wartung von Marcel Schönfelder die Sicherung auf externen Speicher.

Weiterführende Anleitungen und Quellen

• Backup-Restore-Test als feste Routine etablieren
• Wartungsplan für WordPress
• Staging-Umgebung für WordPress einrichten
• WP-CLI-Handbuch: wp db import
• WP-CLI-Handbuch: wp search-replace
• Advanced Administration Handbook: Backups
• Entwicklerreferenz: wp_get_environment_type()