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.
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * 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. Jeder Schritt lief im Test auf einer absichtlich zerstörten WordPress-Installation, einschließlich gelöschter Uploads, entfernter Plugins und einer gelöschten 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: getestet mit WordPress 7.1.2. Der Ablauf gilt für jede Version, solange Backup und Zielsystem zusammenpassen.
- PHP und Datenbank: im Test PHP 8.4 und MariaDB 11.8. 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 (getestet mit 2.12.0). 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.sqlIm Test lief der Export 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.
Verifizieren: 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. Im Test waren es 12 bei einer frischen Installation mit den Standardtabellen, eine Installation mit vielen Plugins hat 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.
Verifizieren: 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.
Verifizieren: 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. Im Test lieferte der Befehl vor dem Restore wegen einer zerstörten version.php noch Error: WP-CLI needs WordPress 3.7 or later to work properly., danach wieder 7.1.2.
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“, im Test mit dem Seitentitel „Database Error“.
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.
Verifizieren: 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 (im Test mit anderem Pfad):
Success: Imported from '/srv/backup/backup-db.sql'.Der Import funktionierte im Test auch in einem Zustand, in dem die Website selbst nur noch „Error establishing a database connection“ zeigte, weil die Tabelle wp_options gelöscht war. 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.
Verifizieren: wp post list --post_type=post,page --fields=ID,post_title zeigt die Inhalte zum Zeitpunkt des Backups. Im Test war der zuvor gelöschte Beitrag „Wichtiger Beitrag“ 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-onlyIm Test zeigte der Probelauf, 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.
Verifizieren: 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 flushIm Test meldeten beide Prüfungen Erfolg, die Website lieferte wieder Status 200, und das zuvor gelöschte Bild unter wp-content/uploads war 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.
Verifizieren: 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. Im Test genügte ein falschesDB_PASSWORDfür diese Meldung. Werte mitwp config getprüfen, siehe Schritt 4. Dieselbe Meldung erschien im Test auch bei fehlender Tabellewp_options, dann hilft der Import aus Schritt 5. Warning: File should not exist: ...beiwp core verify-checksums: Im Core-Verzeichnis liegt eine fremde Datei. Im Test war es eine Konfigurationsdatei des Docker-Images. 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.
Testumfang
Wir haben am 30.09.2026 eine Testinstanz mit WordPress 7.1.2 gezielt beschädigt, sowohl bei den Dateien als auch in der Datenbank. Anschließend haben wir die Dateien samt Korrektur der Rechte wiederhergestellt und die Datenbank neu importiert.
Nicht geprüft haben wir den Import über phpMyAdmin, die Wiederherstellung mit Backup-Plugins und die Bereinigung einer echten Kompromittierung. Wenn Sie einen dieser Wege gehen, testen Sie ihn bitte zuerst an einer Kopie.
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.
