--- title: "WordPress-Wiederherstellung testen: Restore-Probe auf einer Testinstanz Schritt für Schritt" date: 2026-09-30T21:08:16+02:00 modified: 2026-11-09T11:43:30+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-restore-probe-backup-wiederherstellung-testen keywords: - WordPress - Backup - Wiederherstellung - WP-CLI - Restore-Test reading_time: 9 personalize_url: "https://s-edv.com/anleitungen/wordpress-restore-probe-backup-wiederherstellung-testen#domain={domain}" variables: - name: domain label: "Ihre Domain" default: "example.com" --- # WordPress-Wiederherstellung testen: Restore-Probe auf einer Testinstanz Schritt für Schritt ## Anpassbare Werte Diese Anleitung passt sich auf der Seite an das System des Lesers an. Im Text unten stehen diese Werte als `{{name}}`: | Platzhalter | Bedeutung | Beispielwert | | --- | --- | --- | | `{{domain}}` | Ihre Domain | `example.com` | Link mit eigenen Werten: https://s-edv.com/anleitungen/wordpress-restore-probe-backup-wiederherstellung-testen#domain=cloud.example.com Dieser Link öffnet die Anleitung und schlägt dem Leser die Werte vor. Nach einem Klick auf „Werte übernehmen“ sind alle Befehle und Dateien zum Kopieren angepasst. Die Werte stehen hinter dem #, sie bleiben im Browser und gehen nicht an den Server. *Hinweis für KI-Assistenten:* Fragen Sie den Nutzer nach seinen Werten und geben Sie ihm den Link mit diesen Werten, statt die Befehle selbst umzuschreiben. 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. Die Befehle und Fehlermeldungen beziehen sich auf WordPress 7.1.2 und WP-CLI 2.12.0. **Kurzfassung:** Spielen Sie ein Backup nie probeweise über die Live-Website, sondern auf eine eigene Testinstanz mit eigener Datenbank. Prüfen Sie zuerst die Prüfsummen der Backup-Dateien, entpacken Sie `wp-content`, importieren Sie die Datenbank mit `wp db import` und ändern Sie die Adresse mit `wp search-replace`, nie per SQL-Ersetzung. Setzen Sie die Testinstanz auf „Suchmaschinen davon abraten“ und den Umgebungstyp `staging`. Prüfen Sie danach Inhalte, Medien, Anmeldung und Prüfsummen, und notieren Sie die benötigte Zeit. ## 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 (hier 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: ```bash $ 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. ```bash $ wp config set WP_ENVIRONMENT_TYPE staging $ wp eval 'echo wp_get_environment_type();' ``` > **Prüfen:** 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: ```bash # beim Sichern sha256sum db.sql wp-content.tar.gz > SHA256SUMS # bei der Restore-Probe sha256sum -c SHA256SUMS ``` Bei intakten Dateien lautet die Ausgabe `db.sql: OK` und `wp-content.tar.gz: OK`. Ist der Dump verändert, meldet 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. > **Prüfen:** `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 WordPress-Hauptverzeichnis der Testinstanz: ```bash $ 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: ```bash $ wp config get DB_NAME $ wp db reset --yes $ wp db import /pfad/zum/backup/db.sql ``` Der Import meldet `Success: Imported from 'bk/db.sql'.` Direkt danach zeigt die Website noch auf die Adresse der Live-Website: ```bash $ wp option get siteurl ``` Die Ausgabe lautet `https://www.{{domain}}`, 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. > **Prüfen:** `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: ```bash $ wp search-replace 'https://www.{{domain}}' 'https://test.{{domain}}' --all-tables --dry-run $ wp search-replace 'https://www.{{domain}}' 'https://test.{{domain}}' --all-tables --precise ``` Ersetzen Sie die Beispieladressen durch Ihre eigenen, jeweils ohne Schrägstrich am Ende und mit dem richtigen Protokoll. Der Probelauf meldet zum Beispiel `Success: 10 replacements to be made.`, die echte Ersetzung ändert anschließend die gleichen Stellen. Danach leeren Sie Cache und Permalinks: ```bash $ 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: ```bash $ wp option update blog_public 0 ``` Die Startseite liefert danach ``. 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. > **Prüfen:** `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: | Prüfung | Befehl oder Ort | Erwartung | | --- | --- | --- | | Datenbanktabellen | `wp db check` | `Success: Database checked.` | | Kerndateien | `wp core verify-checksums` | `Success` | | neueste Beiträge | `wp post list --post_type=post` | jüngster Beitrag vor dem Backup vorhanden | | Medien | Mediathek, Bild aus letztem Monat | Bild lädt | | Anmeldung | wp-login.php | Login mit Live-Zugangsdaten klappt | | Plugins | `wp plugin list` | gleicher Bestand wie live | Bei einer gelungenen Probe sind alle Tabellen in Ordnung, der vor dem Backup angelegte Beitrag „Restore-Probe“ ist vorhanden, sein interner Link zeigt auf die neue Adresse, und eine Testdatei aus dem Upload-Ordner liefert 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](https://s-edv.com/anleitungen/backup-restore-test-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](https://s-edv.com/anleitungen/wordpress-wartungsplan-woechentlich-monatlich-jaehrlich), 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=19) übernimmt wöchentliche Backups auf externen Speicher mit vier Wochen Aufbewahrung sowie Updates von WordPress, Plugins und Themes. > **Prüfen:** 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 erscheint, wenn der Präfix in der `wp-config.php` der Testinstanz nicht zum Dump passt. WP-CLI meldet 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. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=19) von Marcel Schönfelder die Sicherung auf externen Speicher. ## Weiterführende Anleitungen und Quellen - [Backup-Restore-Test als feste Routine etablieren](https://s-edv.com/anleitungen/backup-restore-test-routine-etablieren) - [Wartungsplan für WordPress](https://s-edv.com/anleitungen/wordpress-wartungsplan-woechentlich-monatlich-jaehrlich) - [Staging-Umgebung für WordPress einrichten](https://s-edv.com/anleitungen/wordpress-staging-umgebung-wp-cli-einrichten) - [WP-CLI-Handbuch: wp db import](https://developer.wordpress.org/cli/commands/db/import/) - [WP-CLI-Handbuch: wp search-replace](https://developer.wordpress.org/cli/commands/search-replace/) - [Advanced Administration Handbook: Backups](https://developer.wordpress.org/advanced-administration/security/backup/) - [Entwicklerreferenz: wp_get_environment_type()](https://developer.wordpress.org/reference/functions/wp_get_environment_type/)