Einzelne Beiträge und Medien aus einem WordPress-Backup zurückholen

Ein versehentlich gelöschter Beitrag, eine überschriebene Seite oder ein fehlendes Bild sind kein Grund, die gesamte Website auf den Stand von gestern zurückzusetzen. Ein vollständiges Restore würde alle Bestellungen, Kommentare und Formulareingänge seit dem Backup verwerfen. Diese Anleitung zeigt den gezielten Weg: Zuerst prüfen Sie die Bordmittel von WordPress, dann holen Sie einzelne Inhalte aus einem Backup, indem Sie es auf einer Testinstanz öffnen, die betroffenen Inhalte exportieren und nur diese in die Live-Website übernehmen. Alle Schritte wurden mit WordPress 7.1.2 und WP-CLI 2.12.0 durchgespielt.

Voraussetzungen

• WordPress: aktuelle Version, getestet mit WordPress 7.1.2 und PHP 8.4.
• Rolle: Administrator im WordPress-Backend der Live-Website.
• Backup: ein Datenbank-Export (.sql) und ein Archiv von wp-content/uploads aus der Zeit, als der Inhalt noch vorhanden war.
• Testinstanz: eine zweite WordPress-Installation, lokal oder beim Hoster, in die Sie das Backup einspielen können. Sie darf die Live-Datenbank nicht mitbenutzen.
• Zugriff: SSH mit WP-CLI auf Test- und Live-Instanz. Ohne SSH gehen Export und Import auch im Backend, Details stehen im jeweiligen Schritt.
• Aktuelle Sicherung der Live-Seite vor dem Import, damit Sie einen fehlerhaften Import zurücknehmen können.

Schritt 1: Papierkorb und Revisionen prüfen

Gelöschte Beiträge und Seiten landen in WordPress zunächst im Papierkorb. Unter „Beiträge > Alle Beiträge“ oder „Seiten“ finden Sie oben den Filter „Papierkorb“. Fahren Sie mit der Maus über den Eintrag und wählen Sie „Wiederherstellen“. WordPress leert den Papierkorb standardmäßig nach 30 Tagen, festgelegt durch die Konstante EMPTY_TRASH_DAYS. Bis dahin ist keine Sicherung nötig.

Beachten Sie: Ein wiederhergestellter Beitrag kommt als Entwurf zurück, nicht veröffentlicht. Im Labor lieferte wp_untrash_post() für einen zuvor veröffentlichten Beitrag den Status draft. Veröffentlichen Sie ihn danach bewusst erneut. Per WP-CLI sieht das so aus:

wp post list --post_status=trash --fields=ID,post_title
wp post update 8 --post_status=publish

Wurde ein Text überschrieben, statt gelöscht, helfen die Revisionen. Öffnen Sie den Beitrag im Editor, in der rechten Seitenleiste unter „Beitrag“ steht die Zahl der Revisionen. Dort vergleichen Sie Stände und klicken auf „Diese Revision wiederherstellen“. Revisionen gibt es nur, solange der Beitrag existiert: Mit dem endgültigen Löschen eines Beitrags verschwinden auch seine Revisionen, das zeigte sich im Labor, als nach dem Löschen keine Revision mehr zum Beitrag gelistet war.

Verifizieren: Der Beitrag ist wieder unter „Alle Beiträge“ sichtbar und hat den gewünschten Status. Falls nicht, weiter mit Schritt 2.

Schritt 2: Backup auf einer Testinstanz öffnen

Spielen Sie das Backup nie testweise auf der Live-Seite ein. Der Import eines Datenbank-Exports ersetzt alle Tabellen und damit alles, was seit dem Backup passiert ist. Nutzen Sie eine eigene Testinstanz. Wie Sie eine einrichten, beschreibt die Anleitung Staging-Umgebung für WordPress einrichten.

Prüfen Sie vor jedem Import, auf welcher Instanz WP-CLI gerade arbeitet. Der Befehl nutzt die wp-config.php des aktuellen Verzeichnisses:

wp option get siteurl
wp db import /pfad/zum/backup.sql

Die erste Zeile muss die Adresse der Testinstanz zeigen. Danach entpacken Sie das Uploads-Archiv in das wp-content-Verzeichnis der Testinstanz. Läuft die Testinstanz unter anderer Adresse als die Live-Seite, passen Sie die URLs mit wp search-replace an, nicht per SQL, da WordPress viele Einstellungen serialisiert speichert.

Wichtig für den DACH-Raum: Die Testinstanz enthält nun eine vollständige Kopie mit Kunden- und Benutzerdaten. Schützen Sie sie vor öffentlichem Zugriff und löschen Sie sie, sobald Sie die Inhalte übernommen haben.

Verifizieren: Die Testinstanz zeigt den gesuchten Beitrag im gewünschten Zustand, und wp option get siteurl gibt nicht die Live-Adresse aus.

Schritt 3: Gesuchte Inhalte exportieren

WordPress exportiert Inhalte im WXR-Format, einer XML-Datei mit Beiträgen, Seiten, Kategorien, Schlagwörtern, Autoren und Metadaten. Suchen Sie auf der Testinstanz zuerst die ID des Beitrags und exportieren Sie ihn dann gezielt. --with_attachments nimmt die zugehörigen Mediathek-Einträge mit:

wp post list --post_type=post,page --fields=ID,post_title,post_date
wp export --post__in=8 --with_attachments --dir=/pfad/export --filename_format=wiederherstellung.xml

Im Labor meldete der Befehl „Success: All done with export.“ und die Datei enthielt zwei Einträge: den Beitrag und das zugehörige Bild. Mehrere Beiträge geben Sie mit Komma getrennt an. Mit --post_type, --start_date und --end_date lässt sich der Export auch nach Typ und Zeitraum eingrenzen, etwa für alle Seiten einer Woche.

Ohne SSH nutzen Sie im Backend der Testinstanz „Werkzeuge > Export“. Dort können Sie nur nach Inhaltstyp, Kategorie, Autor, Zeitraum und Status filtern, nicht nach einzelnen IDs. Exportieren Sie in dem Fall einen möglichst engen Zeitraum.

Verifizieren: Die XML-Datei existiert, und ein Blick hinein zeigt den Titel des gesuchten Beitrags sowie bei Bildern eine Zeile <wp:attachment_url>.

Schritt 4: Bilder und Dateien zurückkopieren

Der Importer kann Bilder nur übernehmen, wenn er sie von der ursprünglichen Adresse herunterladen kann. Ist die Datei auf der Live-Seite gelöscht oder die Testinstanz nicht aus dem Internet erreichbar, schlägt das fehl. Im Labor lautete die Meldung „Failed to import Medien “Büro”“, der Beitrag wurde trotzdem importiert, aber ohne Bild. Zuverlässiger ist deshalb, die Bilddateien direkt aus dem Backup-Archiv zu holen.

Die Pfade stehen in der XML-Datei in der Zeile <wp:attachment_url>. Entpacken Sie auf der Live-Seite im WordPress-Verzeichnis nur diese Datei aus dem Archiv:

tar -tzf uploads-backup.tar.gz | grep buero
tar -xzf uploads-backup.tar.gz wp-content/uploads/2026/09/buero.jpg

Der erste Befehl listet die passenden Pfade im Archiv, der zweite stellt genau eine Datei wieder her, ohne andere Uploads zu überschreiben. Die verkleinerten Varianten wie buero-300x225.jpg brauchen Sie nicht, WordPress erzeugt sie im nächsten Schritt neu. Achten Sie darauf, dass die Datei dem Benutzer des Webservers gehört, sonst kann WordPress sie später nicht bearbeiten.

Verifizieren: Die Bilddatei liegt wieder unter demselben Pfad in wp-content/uploads.

Schritt 5: Inhalte in die Live-Website übernehmen

Sichern Sie jetzt die Live-Datenbank. Der Import fügt Inhalte hinzu, ändert aber nichts Bestehendes. Die Sicherung erlaubt Ihnen dennoch, einen verunglückten Import vollständig zurückzunehmen.

wp db export vor-import.sql

Für den Import brauchen Sie das Plugin WordPress Importer (im Labor Version 0.9.6). Im Backend installieren Sie es über „Werkzeuge > Import“, per WP-CLI so:

wp plugin install wordpress-importer --activate
wp import wiederherstellung.xml --authors=skip --skip=attachment

--authors=skip ordnet keine Autoren aus der Datei zu und legt keine neuen Benutzer an. Mit --authors=create würde der Importer fehlende Benutzer neu anlegen, was auf einer Unternehmensseite selten gewollt ist. --skip=attachment überspringt die Mediathek-Einträge, weil Sie die Dateien in Schritt 4 selbst zurückgeholt haben. Existiert ein Beitrag mit gleichem Titel und Datum bereits, überspringt der Importer ihn; im Labor blieb dadurch bei einem zweiten Import der vorhandene Beitrag unverändert, es entstand kein Duplikat.

Registrieren Sie das zurückkopierte Bild anschließend in der Mediathek und hängen Sie es wieder an den Beitrag. --skip-copy nutzt die Datei an ihrem Ort, statt eine Kopie anzulegen, --featured_image setzt sie als Beitragsbild:

wp media import wp-content/uploads/2026/09/buero.jpg --skip-copy --post_id=8 --featured_image --title="Büro"

Im Labor entstand so ein neuer Mediathek-Eintrag mit neuer ID, die Vorschaubilder wurden neu erzeugt und das Beitragsbild war gesetzt. Weil die ID sich ändert, prüfen Sie Bildblöcke im Beitrag: Die Adresse der Datei stimmt wieder, der Block verweist aber auf die alte ID. Öffnen Sie den Beitrag im Editor und wählen Sie das Bild bei Bedarf neu aus der Mediathek aus.

Solche Rettungsaktionen sind nur möglich, wenn regelmäßig passende Backups entstehen und jemand sie im Blick behält. Wer diese Aufgabe nicht selbst im Kalender halten 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: Der Beitrag erscheint unter „Beiträge > Alle Beiträge“, zeigt Text und Bild im Frontend, und die Mediathek enthält das Bild mit Vorschau.

Schritt 6: Nacharbeiten und aufräumen

Prüfen Sie nach dem Import Status, Kategorie, Autor, Permalink und Beitragsbild. Importierte Beiträge behalten ihren ursprünglichen Status aus der Datei. Stimmt der Permalink nicht mehr, weil zwischenzeitlich ein anderer Beitrag denselben Slug belegt hat, korrigieren Sie ihn, damit externe Links wieder funktionieren.

Deaktivieren Sie den WordPress Importer, wenn Sie ihn nicht mehr brauchen. Löschen Sie die Export-Datei und die Testinstanz samt Datenbank. Beide enthalten Inhalte und bei vollständigem Backup auch personenbezogene Daten.

wp plugin deactivate wordpress-importer
wp plugin delete wordpress-importer

Verifizieren: Der Beitrag ist öffentlich unter seiner alten Adresse erreichbar, der Importer ist entfernt, und von der Testinstanz existiert keine erreichbare Kopie mehr.

Typische Fehler

• „Failed to import Medien …“: Der Importer konnte die Bilddatei nicht herunterladen. Im Labor trat das auf, weil die Quelladresse nicht erreichbar war. Holen Sie die Datei wie in Schritt 4 aus dem Archiv.
• Beitrag nach Wiederherstellung aus dem Papierkorb nicht sichtbar: Er ist als Entwurf zurückgekommen. Filtern Sie in „Alle Beiträge“ nach Entwürfen und veröffentlichen Sie ihn.
• Backup versehentlich auf der Live-Seite eingespielt: Alle Änderungen seit dem Backup sind überschrieben. Spielen Sie sofort die in Schritt 5 angelegte Sicherung vor-import.sql ein, falls vorhanden. Deshalb immer erst wp option get siteurl prüfen.
• „Permission denied“ beim Export: Im Labor scheiterte wp db export mit „Can't create/write to file … (Errcode: 13 "Permission denied")“, weil das Zielverzeichnis einem anderen Benutzer gehörte. Wählen Sie ein Verzeichnis, in das der ausführende Benutzer schreiben darf.
• Bild im Beitrag fehlt trotz Mediathek-Eintrag: Der Bildblock verweist auf die alte Anhang-ID. Bild im Editor neu auswählen.

Häufige Fragen

Kann ich einzelne Tabellen aus dem SQL-Backup direkt einspielen?

Technisch ja, praktisch riskant. Ein Beitrag verteilt sich auf mehrere Tabellen (Beitrag, Metadaten, Begriffe, Zuordnungen), und IDs können sich mit neuen Inhalten überschneiden. Der Weg über Testinstanz und WXR-Export ist langsamer, aber kontrollierbar.

Funktioniert das auch mit Seiten und Produkten?

wp export exportiert alle Inhaltstypen, auch eigene wie Produkte. Ob alle Zusatzdaten eines Shop-Plugins im Export stecken, hängt vom Plugin ab. Prüfen Sie das Ergebnis auf der Testinstanz, bevor Sie live importieren.

Was ist mit Kommentaren?

Kommentare zu exportierten Beiträgen sind in der WXR-Datei enthalten und werden mit importiert, solange Sie nicht --skip_comments beim Export setzen.

Wie lange nach dem Löschen geht das noch?

So lange, wie ein Backup mit dem Inhalt existiert. Die Aufbewahrungsdauer legen Sie in Ihrer Backup-Strategie fest, siehe WordPress-Backup-Strategie planen.

Testumfang

Wir haben das Ganze mit WordPress 7.1.2 im Labor durchgespielt, vom Papierkorb bis zum erneuten Import per WP-CLI. Auffällig war, dass wiederhergestellte Beiträge als Entwurf zurückkommen und nach dem endgültigen Löschen auch die Revisionen weg sind. Ein erneuter Import legte keine Duplikate an. Den Import über die Backend-Oberfläche und Shop-Plugins haben wir nicht geprüft, probieren Sie das deshalb zuerst auf einer Kopie aus.

Fazit

Einzelne Inhalte holen Sie am sichersten in drei Stufen zurück: Papierkorb und Revisionen, dann Testinstanz mit gezieltem Export, zuletzt Import auf der Live-Seite mit getrennt zurückkopierten Bildern. So bleibt alles erhalten, was seit dem Backup hinzugekommen ist. Voraussetzung sind regelmäßige, geprüfte Sicherungen; wer diese Pflege auslagern möchte, findet sie bei der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Backup-Strategie: Dateien, Datenbank und Aufbewahrung richtig planen
• Staging-Umgebung für WordPress einrichten
• WordPress-Update fehlgeschlagen: weiße Seite und kritischen Fehler beheben
• WP-CLI: wp export
• WP-CLI: wp import
• WP-CLI: wp media import
• WordPress Importer auf wordpress.org