--- title: "WordPress nach Datenverlust wiederherstellen: Dateien und Datenbank Schritt für Schritt aus dem Backup" date: 2026-09-30T21:09:54+02:00 modified: 2026-11-08T22:36:09+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-wiederherstellen-datenverlust-backup-restore keywords: - WordPress - Backup - Wiederherstellung - WP-CLI - Datenbank reading_time: 9 --- # WordPress nach Datenverlust wiederherstellen: Dateien und Datenbank Schritt für Schritt aus dem Backup 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. **Kurzfassung:** Sichern Sie zuerst den defekten Zustand, damit Sie nichts endgültig verlieren. Prüfen Sie dann das Backup auf Vollständigkeit, verschieben Sie die alten Dateien beiseite, entpacken Sie das Datei-Backup und korrigieren Sie die Besitzrechte. Importieren Sie danach die Datenbank mit `wp db import`. Kontrollieren Sie zum Schluss Prüfsummen, Permalinks, Medien und wichtige Seiten und schließen Sie bei einem Angriff die Lücke, bevor die Website wieder öffentlich läuft. ## Voraussetzungen - [ ] **Backup:** ein Datei-Backup des WordPress-Verzeichnisses (mindestens `wp-config.php` und `wp-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: ```bash $ cd /var/www/html $ sudo -u www-data wp db export /var/backups/wordpress/kaputt-vor-restore.sql ``` Der 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. > **Prüfen:** 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: ```bash $ 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.sql ``` Das 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. > **Prüfen:** `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: ```bash $ 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/html ``` Der 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. > **Prüfen:** `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“. ```bash $ sudo -u www-data wp config get DB_NAME $ sudo -u www-data wp config get DB_HOST $ sudo -u www-data wp db check ``` Korrigieren 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. > **Prüfen:** `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`: ```bash $ sudo -u www-data wp db import /srv/backup/backup-db.sql ``` Die Ausgabe: ```plaintext 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](https://s-edv.com/anleitungen/wordpress-updates-wp-cli-core-plugins-themes) 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. > **Prüfen:** `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. ```bash $ sudo -u www-data wp search-replace 'https://alte-domain.de' 'https://neue-domain.de' --dry-run --report-changed-only ``` Der 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`. > **Prüfen:** `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: ```bash $ 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 flush ``` Danach 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=22) erstellt wöchentliche Backups auf externem Speicher mit vier Wochen Aufbewahrung, spielt Updates ein und richtet die Firewall ein. > **Prüfen:** 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.php` passen nicht zur Datenbank. Schon ein falsches `DB_PASSWORD` genügt für diese Meldung. Werte mit `wp config get` prüfen, siehe Schritt 4. Dieselbe Meldung erscheint auch bei fehlender Tabelle `wp_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/uploads` aus. 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-data` korrigieren. **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](https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-kritischer-fehler). ## 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](https://s-edv.com/anleitungen/immutable-backups-ransomware-3-2-1-1-0-restic-hetzner). ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=22) wöchentliche externe Backups und betreute Updates. ## Weiterführende Anleitungen und Quellen - [WordPress-Update-Fehler beheben: weiße Seite und kritischer Fehler](https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-kritischer-fehler) - [WordPress-Updates per WP-CLI einspielen](https://s-edv.com/anleitungen/wordpress-updates-wp-cli-core-plugins-themes) - [Immutable Backups gegen Ransomware](https://s-edv.com/anleitungen/immutable-backups-ransomware-3-2-1-1-0-restic-hetzner) - [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/) - [WP-CLI-Handbuch: wp config shuffle-salts](https://developer.wordpress.org/cli/commands/config/shuffle-salts/) - [Advanced Administration Handbook: WordPress Backups](https://developer.wordpress.org/advanced-administration/security/backup/)