WordPress nach Datenverlust wiederherstellen: Dateien und Datenbank Schritt für Schritt aus dem Backup
WordPress nach Datenverlust oder Angriff aus dem Backup zurückholen: defekten Zustand sichern, Backup prüfen, Dateien und Datenbank per WP-CLI wiederherstellen, kontrollieren und Ursache beseitigen.
Werbung Mit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Mehr dazu
Ein gehacktes Plugin, ein versehentlich gelöschter Ordner oder ein Update, das die Datenbank beschädigt hat: Irgendwann muss fast jede Unternehmenswebsite aus einem Backup zurückgeholt werden. In dieser Situation zählen eine feste Reihenfolge und ein kühler Kopf mehr als das richtige Plugin. Diese Anleitung führt Sie durch eine vollständige Wiederherstellung von Dateien und Datenbank auf einem Server mit SSH-Zugang, vom Sichern des defekten Zustands bis zur Kontrolle danach. Sie deckt typische Schäden ab, etwa gelöschte Uploads, entfernte Plugins oder eine gelöschte Datenbanktabelle.
Voraussetzungen
- Backup: ein Datei-Backup des WordPress-Verzeichnisses (mindestens
wp-config.phpundwp-content) und ein Datenbank-Dump als SQL-Datei, beide vom selben Zeitpunkt. - WordPress: Der Ablauf gilt für jede Version, solange Backup und Zielsystem zusammenpassen.
- PHP und Datenbank: Stellen Sie auf dem Zielsystem mindestens die PHP-Version bereit, mit der die Website vorher lief.
- Zugriff: SSH auf den Server mit Rechten für den Webserver-Benutzer, dazu WP-CLI. Ohne SSH funktioniert der Ablauf sinngemäß mit SFTP und der Datenbankverwaltung des Hosters.
- Rolle: Administratorkonto im Backend für die Kontrolle nach dem Restore.
- Speicherplatz: freier Platz für mindestens eine weitere vollständige Kopie der Website, denn Sie heben den defekten Zustand auf.
Schritt 1: Den defekten Zustand sichern und eingrenzen
Der häufigste Fehler bei Wiederherstellungen ist, den kaputten Zustand sofort zu überschreiben. Danach lässt sich nicht mehr klären, was passiert ist, und Inhalte, die nach dem letzten Backup entstanden sind, sind endgültig weg. Sichern Sie deshalb zuerst die Datenbank so, wie sie jetzt ist, auch wenn einzelne Tabellen fehlen:
$ cd /var/www/html
$ sudo -u www-data wp db export /var/backups/wordpress/kaputt-vor-restore.sqlDer Export läuft auch mit gelöschter Tabelle wp_posts durch. Klären Sie dann die Ursache grob: Wurden Dateien gelöscht, ist die Datenbank beschädigt oder wurde die Website angegriffen? Bei einem Angriff brauchen Sie ein Backup von einem Zeitpunkt vor dem Einbruch, nicht einfach das neueste. Hinweise liefern Änderungsdaten von Dateien, Zugriffsprotokolle des Webservers und neue Administratorkonten.
Setzen Sie die Website während der Arbeiten in Wartung, etwa über eine Sperre beim Hoster oder im Webserver. Eine halb wiederhergestellte Website sollte keine Besucher und keine Suchmaschinen bedienen.
Die Datei kaputt-vor-restore.sql existiert, wp db export meldete Success: Exported to ..., und Sie haben den Zeitpunkt notiert, auf den Sie zurückgehen wollen.
Schritt 2: Das Backup auf Vollständigkeit prüfen
Ein Restore aus einem unvollständigen Backup macht die Lage schlimmer. Prüfen Sie deshalb vor jeder Änderung, ob Archiv und Dump lesbar sind und das Erwartete enthalten:
$ gzip -t /srv/backup/wp-files.tar.gz && echo "Archiv ok"
$ tar -tzf /srv/backup/wp-files.tar.gz | grep -c "wp-content/uploads"
$ tar -tzf /srv/backup/wp-files.tar.gz | grep -E "wp-config.php$"
$ head -3 /srv/backup/backup-db.sql
$ grep -c "DROP TABLE IF EXISTS" /srv/backup/backup-db.sqlDas Archiv muss den Test ohne Meldung bestehen, wp-config.php und Einträge unter wp-content/uploads müssen auftauchen. Der Dump beginnt bei MariaDB mit einer Kopfzeile wie -- MariaDB dump 10.19-11.8.8-MariaDB. Die Zahl der DROP TABLE IF EXISTS-Zeilen entspricht ungefähr der Zahl der Tabellen. Eine frische Installation mit den Standardtabellen hat 12, eine Installation mit vielen Plugins deutlich mehr.
Diese Zeilen haben eine wichtige Folge: Beim Import werden nur Tabellen ersetzt, die im Dump enthalten sind. Tabellen, die ein Plugin erst nach dem Backup angelegt hat, bleiben unverändert in der Datenbank stehen.
Legen Sie Kopien der Backup-Dateien an, bevor Sie damit arbeiten. Das Original bleibt so unangetastet, falls beim Entpacken etwas schiefgeht.
gzip -t meldet keinen Fehler, die Liste zeigt Uploads und wp-config.php, und der Dump enthält für jede erwartete Tabelle ein DROP TABLE IF EXISTS.
Schritt 3: Dateien wiederherstellen
Entpacken Sie das Backup nicht einfach über die vorhandenen Dateien. Dabei bleiben Dateien stehen, die es im Backup nicht gibt, bei einem Angriff also gerade die eingeschleusten Hintertüren. Verschieben Sie den alten Inhalt stattdessen in einen Ordner außerhalb des Webroots und entpacken Sie in ein leeres Verzeichnis:
$ sudo mkdir -p /srv/defekt/html-kaputt
$ cd /var/www/html
$ sudo find . -mindepth 1 -maxdepth 1 -exec mv -t /srv/defekt/html-kaputt/ {} +
$ sudo tar -xzf /srv/backup/wp-files.tar.gz -C /var/www/html
$ sudo chown -R www-data:www-data /var/www/htmlDer Befehl mit find verschiebt auch versteckte Dateien wie .htaccess. Passen Sie die Pfade an Ihren Server an, der Webroot liegt nicht überall unter /var/www/html. Die Besitzrechte sind entscheidend: Entpackt root das Archiv, gehören die Dateien je nach Archiv root, und WordPress kann danach keine Updates und keine Uploads mehr schreiben.
Ohne SSH laden Sie die entpackten Dateien per SFTP hoch. Auch dann gilt: Die alten Dateien vorher in einen anderen Ordner verschieben, nicht überschreiben.
ls -A /var/www/html zeigt wp-config.php, wp-admin, wp-content, wp-includes und .htaccess, und sudo -u www-data wp core version gibt die erwartete Version aus. Vor dem Restore liefert der Befehl bei einer zerstörten version.php noch Error: WP-CLI needs WordPress 3.7 or later to work properly., danach wieder die erwartete Version.
Schritt 4: Datenbankverbindung prüfen
Die wp-config.php aus dem Backup enthält die Zugangsdaten zum Zeitpunkt der Sicherung. Wurde das Datenbankpasswort seitdem geändert oder stellen Sie auf einem neuen Server wieder her, passen sie nicht mehr. Die Website zeigt dann nur „Error establishing a database connection“.
$ sudo -u www-data wp config get DB_NAME
$ sudo -u www-data wp config get DB_HOST
$ sudo -u www-data wp db checkKorrigieren Sie abweichende Werte mit wp config set, etwa wp config set DB_HOST localhost. Das Passwort tragen Sie besser direkt im Editor ein, damit es nicht in der Shell-Historie landet. Bei einem Angriff erzeugen Sie außerdem neue Sicherheitsschlüssel mit wp config shuffle-salts. Das meldet alle angemeldeten Benutzer ab, auch einen Angreifer mit gestohlenem Sitzungscookie.
wp db check endet mit Success: Database checked.
Schritt 5: Datenbank importieren
Importieren Sie jetzt den Dump. WP-CLI liest die Zugangsdaten aus der wp-config.php:
$ sudo -u www-data wp db import /srv/backup/backup-db.sqlDie Ausgabe:
Success: Imported from '/srv/backup/backup-db.sql'.Der Import funktioniert auch in einem Zustand, in dem die Website selbst nur noch „Error establishing a database connection“ zeigt, weil die Tabelle wp_options gelöscht ist. WP-CLI braucht für wp db import keine funktionierende WordPress-Installation, nur eine gültige wp-config.php. Wie Sie Datenbank-Dumps regelmäßig per WP-CLI erstellen, zeigt die Anleitung WordPress-Updates per WP-CLI im Abschnitt zur Sicherung.
Ohne SSH importieren Sie den Dump über die Datenbankverwaltung des Hosters, oft phpMyAdmin. Große Dumps scheitern dort an Upload-Grenzen, dann hilft nur der Support des Hosters oder ein Zugang per SSH.
wp post list --post_type=post,page --fields=ID,post_title zeigt die Inhalte zum Zeitpunkt des Backups. Ein zuvor gelöschter Beitrag ist wieder vorhanden.
Schritt 6: Adresse anpassen, falls sich die Domain geändert hat
Stellen Sie auf derselben Domain wieder her, entfällt dieser Schritt. Ziehen Sie auf eine neue Adresse um, etwa auf eine Ersatzdomain, weil der alte Server nicht mehr erreichbar ist, müssen alle URLs in der Datenbank ersetzt werden. Verwenden Sie dafür niemals ein einfaches SQL-Replace: Viele Einstellungen sind serialisiert gespeichert, und eine geänderte Zeichenlänge macht sie unlesbar. wp search-replace berücksichtigt das.
$ sudo -u www-data wp search-replace 'https://alte-domain.de' 'https://neue-domain.de' --dry-run --report-changed-onlyDer Probelauf zeigt, dass die Ersetzungen in wp_options als Typ PHP behandelt werden, also serialisiert, und in wp_posts als SQL. Wenn die Liste plausibel ist, starten Sie den Befehl ohne --dry-run.
wp option get siteurl und wp option get home zeigen die richtige Adresse.
Schritt 7: Kontrollieren und die Ursache beseitigen
Ein erfolgreicher Import heißt noch nicht, dass die Website vollständig ist. Prüfen Sie Core und Plugins gegen die offiziellen Prüfsummen, erzeugen Sie die Permalinks neu und leeren Sie den Objekt-Cache:
$ sudo -u www-data wp core verify-checksums
$ sudo -u www-data wp plugin verify-checksums --all
$ sudo -u www-data wp rewrite flush
$ sudo -u www-data wp cache flushDanach melden beide Prüfungen Erfolg, die Website liefert wieder Status 200, und gelöschte Bilder unter wp-content/uploads sind wieder abrufbar. Öffnen Sie danach im Backend Einstellungen > Permalinks und klicken Sie auf „Änderungen speichern“, falls Unterseiten mit 404 antworten. Testen Sie Kontaktformular, Shop und Anmeldung.
War ein Angriff die Ursache, ist die Arbeit jetzt nicht fertig. Das Backup enthält dieselbe Lücke, durch die der Angreifer gekommen ist. Aktualisieren Sie Core, Plugins und Themes, entfernen Sie nicht mehr genutzte Plugins und ändern Sie alle Administratorpasswörter sowie das Datenbankpasswort. Prüfen Sie mit wp user list --role=administrator, ob unbekannte Konten existieren.
Wiederherstellungen zeigen, wie viel an regelmäßiger Vorarbeit hängt: aktuelle Backups an einem externen Ort, eingespielte Updates und eine Firewall. Wer das nicht selbst organisieren möchte, kann es abgeben: Die WordPress-Wartung von wordpressupdate.de erstellt wöchentliche Backups auf externem Speicher mit vier Wochen Aufbewahrung, spielt Updates ein und richtet die Firewall ein.
Prüfsummen ohne Fehlermeldung, Startseite und Unterseiten liefern Status 200, Bilder werden angezeigt, und die Administratorliste enthält nur bekannte Konten.
Typische Fehler
- „Error establishing a database connection“ nach dem Restore
Die Zugangsdaten in der wiederhergestellten
wp-config.phppassen nicht zur Datenbank. Schon ein falschesDB_PASSWORDgenügt für diese Meldung. Werte mitwp config getprüfen, siehe Schritt 4. Dieselbe Meldung erscheint auch bei fehlender Tabellewp_options, dann hilft der Import aus Schritt 5.Warning: File should not exist: ...bei
wp core verify-checksums: Im Core-Verzeichnis liegt eine fremde Datei. Bei Docker-Installationen kann es eine Konfigurationsdatei des Images sein. Nach einem Angriff prüfen Sie jede gemeldete Datei, bevor Sie die Website freigeben.- Uploads fehlen, Beiträge sind aber da
Datei-Backup und Datenbank stammen nicht vom selben Zeitpunkt, oder das Datei-Backup schloss
wp-content/uploadsaus. Prüfen Sie die Liste aus Schritt 2.- Nach dem Restore lassen sich keine Plugins aktualisieren
Die Dateien gehören root. Mit
chown -R www-data:www-datakorrigieren.- Die Website ist wieder da, wird aber erneut kompromittiert
Die Lücke wurde nicht geschlossen, oder das Backup stammt von einem Zeitpunkt nach dem Einbruch. Früheres Backup wählen und Schritt 7 vollständig abarbeiten.
- Weiße Seite oder „kritischer Fehler“ nach dem Restore
Meist passt die PHP-Version nicht zu Plugins aus dem Backup. Hinweise zur Analyse finden Sie in WordPress-Update-Fehler beheben.
Häufige Fragen
Kann ich nur die Datenbank zurückspielen und die Dateien behalten?
Ja, wenn die Dateien nachweislich in Ordnung sind, etwa nach einem fehlerhaften Import von Inhalten. Nach einem Angriff oder einem abgebrochenen Update stellen Sie immer beides wieder her, weil Code und Datenbankschema zusammenpassen müssen.
Was passiert mit Bestellungen und Kommentaren seit dem letzten Backup?
Sie fehlen nach dem Restore. Deshalb sichern Sie in Schritt 1 den defekten Zustand. Daraus lassen sich einzelne Datensätze gezielt übernehmen. Das ist Handarbeit und bei Shops ein Grund, die Datenbank häufiger als einmal täglich zu sichern.
Wie oft sollte ich eine Wiederherstellung üben?
Mindestens nach jeder Änderung am Backup-Verfahren und sonst regelmäßig auf einer Testinstanz. Ein Backup, dessen Wiederherstellung nie geprüft wurde, ist eine Annahme. Warum ein Teil der Backups getrennt und unveränderbar liegen sollte, erklärt Immutable Backups gegen Ransomware.
Fazit
Eine Wiederherstellung gelingt, wenn Sie in fester Reihenfolge arbeiten: defekten Zustand sichern, Backup prüfen, Dateien sauber ersetzen, Datenbank importieren, kontrollieren und die Ursache beseitigen. Die wichtigste Voraussetzung entsteht aber vorher, durch aktuelle, geprüfte Backups an einem externen Ort. Wer diese Vorsorge dauerhaft abgeben möchte, findet bei der WordPress-Wartung von Marcel Schönfelder wöchentliche externe Backups und betreute Updates.
