WordPress-Datenbank mit WP-CLI sichern und wiederherstellen

Die Datenbank ist das Gedächtnis Ihrer WordPress-Website: Beiträge, Seiten, Einstellungen, Benutzer, Formulareingänge und bei Shops auch Bestellungen liegen dort. Mit WP-CLI sichern Sie sie in einem Befehl und spielen sie ebenso schnell zurück, ohne phpMyAdmin und ohne Zugangsdaten abzutippen. Diese Anleitung zeigt Export, Prüfung, sichere Ablage und Wiederherstellung und nennt die Fallstricke, die im Labor tatsächlich aufgetreten sind, darunter eine Sicherung, die öffentlich herunterladbar war.

Voraussetzungen

• WordPress: geprüft mit WordPress 7.1.2. Die Befehle hängen kaum von der WordPress-Version ab.
• WP-CLI: geprüft mit WP-CLI 2.12.0. Mit wp cli version sehen Sie Ihre Version. Viele Hoster haben WP-CLI vorinstalliert, oft auch als Befehl wp im SSH-Zugang.
• PHP und Datenbank: PHP ab 7.4, MySQL oder MariaDB. Auf dem Server müssen die Kommandozeilenprogramme mysqldump oder mariadb-dump sowie mysql oder mariadb vorhanden sein, denn WP-CLI ruft sie auf. wp cli info zeigt in der Zeile „MySQL binary“, was gefunden wurde.
• Zugriff: SSH auf den Server und ein Benutzer mit Schreibrechten im WordPress-Verzeichnis. Für die Kontrolle im Backend ein Konto mit der Rolle Administrator.
• Backup: Vor einer Wiederherstellung gilt: zuerst den aktuellen Stand sichern (Schritt 5). Eine Wiederherstellung überschreibt Daten unwiderruflich.
• Speicherplatz: freier Platz mindestens in Größe der Datenbank, zu sehen mit wp db size --human-readable.

Schritt 1: Umgebung prüfen

Wechseln Sie per SSH in das WordPress-Verzeichnis, also den Ordner mit der wp-config.php. WP-CLI findet die Installation von dort aus selbst, alternativ geben Sie --path=/pfad/zu/wordpress an. Prüfen Sie dann, ob WP-CLI die Datenbank erreicht:

cd /var/www/html
wp cli info
wp config get DB_NAME
wp db size --tables --human-readable
wp db check

wp db check ruft mysqlcheck auf und prüft jede Tabelle. Beschädigte Tabellen sollten Sie reparieren, bevor Sie eine Sicherung als „gut“ ablegen, sonst sichern Sie den Fehler mit. Das Tabellenpräfix sehen Sie mit wp db prefix. Es ist wichtig, wenn mehrere Installationen eine Datenbank teilen.

Verifizieren: wp cli info zeigt eine Zeile „MySQL binary“ mit Pfad, wp config get DB_NAME liefert den Datenbanknamen, und wp db check endet mit Success: Database checked..

Schritt 2: Datenbank exportieren

Der Grundbefehl ist kurz. WP-CLI übernimmt Host, Datenbank, Benutzer und Passwort aus der wp-config.php, das Passwort steht also weder in der Befehlszeile noch in der Shell-Historie:

mkdir -p ~/wp-backup
wp db export ~/wp-backup/db-$(date +%F-%H%M).sql --add-drop-table

Die Option --add-drop-table schreibt vor jede Tabelle ein DROP TABLE IF EXISTS. Beim Zurückspielen ersetzt der Import dann vorhandene Tabellen sauber, statt an bereits vorhandenen Tabellen zu scheitern. Im Labor enthielt der Dump auch ohne diese Option bereits die DROP TABLE-Zeilen, weil mariadb-dump sie standardmäßig setzt. Mit der Option sind Sie unabhängig von der Voreinstellung des Servers.

Ohne Dateinamen legt WP-CLI die Datei im aktuellen Verzeichnis nach dem Muster {dbname}-{Y-m-d}-{hash}.sql an. Im Labor hieß sie wp_w3-2026-09-30-ca88bca.sql und lag damit im Webroot. Warum das gefährlich ist, zeigt Schritt 4. Mit --porcelain gibt der Befehl nur den Dateinamen aus, praktisch für Skripte.

Einzelne Tabellen sichern Sie mit --tables, zum Ausschließen dient --exclude_tables. Das ist nützlich, um etwa vor einer Massenänderung nur Beiträge zu sichern:

wp db export ~/wp-backup/posts.sql --tables=wp_posts,wp_postmeta
wp db tables --format=csv

Zusätzliche Optionen reicht WP-CLI an mysqldump durch. Bei großen InnoDB-Datenbanken sind --single-transaction --quick üblich; im Labor liefen sie fehlerfrei durch.

Verifizieren: Die Ausgabe lautet Success: Exported to '…/db-2026-09-30-2103.sql'., und ls -lh ~/wp-backup zeigt eine Datei, deren Größe grob zu wp db size passt.

Schritt 3: Dump prüfen und komprimieren

Ein Dump kann abbrechen, etwa wenn die Platte voll ist oder die Verbindung abreißt. Eine abgebrochene Datei sieht auf den ersten Blick normal aus. Prüfen Sie deshalb Anfang und Ende:

head -n 3 ~/wp-backup/db-*.sql
tail -n 1 ~/wp-backup/db-*.sql
grep -c "CREATE TABLE" ~/wp-backup/db-*.sql

Im Labor begann der Dump mit -- MariaDB dump 10.19-11.8.8-MariaDB und endete mit -- Dump completed on 2026-09-30 19:03:18. Fehlt die Schlusszeile, ist die Datei unvollständig. Die Zahl der CREATE TABLE-Zeilen sollte der Zahl der Tabellen aus wp db tables entsprechen, bei einer frischen Installation 12.

SQL-Dumps lassen sich gut komprimieren. Im Labor schrumpfte ein Dump von 93.885 Byte mit gzip auf 17.736 Byte. Komprimieren und prüfen Sie so:

gzip ~/wp-backup/db-2026-09-30-2103.sql
gzip -t ~/wp-backup/db-2026-09-30-2103.sql.gz && echo "Archiv ok"

Alternativ schreiben Sie direkt komprimiert: wp db export - | gzip > ~/wp-backup/db.sql.gz. Das Minuszeichen leitet den Dump auf die Standardausgabe um.

Verifizieren: tail -n 1 zeigt „Dump completed on …“, und gzip -t meldet keinen Fehler.

Schritt 4: Sicherung sicher ablegen

Ein Datenbank-Dump enthält alles, was ein Angreifer sucht: E-Mail-Adressen, Passwort-Hashes aller Benutzer und die Inhalte von Formularen. Im Labor war ein Dump, der im WordPress-Verzeichnis lag, sofort per Browser abrufbar. curl auf /wp_w3-2026-09-30-ca88bca.sql lieferte HTTP 200 und die komplette Datei, ebenso eine Datei unter /wp-content/. Legen Sie Dumps daher nie im Webroot ab, sondern in einem Verzeichnis darüber oder im Home-Verzeichnis, und sperren Sie den Zugriff für andere Benutzer:

chmod 700 ~/wp-backup
chmod 600 ~/wp-backup/*.sql.gz

Eine Sicherung auf demselben Server schützt nur vor Bedienfehlern, nicht vor einem Plattenausfall, einem kompromittierten Konto oder dem Ende des Hosting-Vertrags. Kopieren Sie die Datei deshalb regelmäßig auf einen zweiten Speicherort, etwa per scp auf ein NAS oder per rclone in einen Cloud-Speicher. Die Anleitung MySQL- und PostgreSQL-Backups mit cron automatisieren zeigt Rotation und Upload im Detail. Für personenbezogene Daten in Backups gilt die DSGVO: Legen Sie eine Aufbewahrungsfrist fest und löschen Sie ältere Sicherungen.

Verifizieren: curl -I https://ihre-domain.de/DATEINAME.sql liefert 404, und ls -ld ~/wp-backup zeigt drwx------.

Schritt 5: Datenbank wiederherstellen

Die Wiederherstellung überschreibt alle Tabellen, die im Dump enthalten sind. Alles, was seit der Sicherung geschrieben wurde, geht verloren: neue Beiträge, Kommentare, Bestellungen. Sichern Sie deshalb unmittelbar vorher den aktuellen Stand, auch wenn er fehlerhaft ist. So können Sie einzelne neue Daten später noch herausholen.

wp db export ~/wp-backup/vor-restore-$(date +%F-%H%M).sql
gunzip -k ~/wp-backup/db-2026-09-30-2103.sql.gz
wp db import ~/wp-backup/db-2026-09-30-2103.sql
wp cache flush

Im Labor legte der Test zuerst einen Dump an, erstellte danach den Beitrag „Testbeitrag nach Backup“ und spielte den Dump zurück. Die Ausgabe lautete Success: Imported from 'wp-content/backup-test.sql'., und der Testbeitrag war verschwunden. wp cache flush leert einen eventuell vorhandenen Objekt-Cache, damit WordPress keine veralteten Werte ausliefert.

Ein wichtiges Detail aus dem Test: wp db import führt nur die SQL-Befehle der Datei aus und legt laut WP-CLI-Handbuch auch keine Datenbank an. Tabellen, die erst nach der Sicherung entstanden sind, etwa durch ein neu installiertes Plugin, bleiben stehen. Im Labor überlebte eine nachträglich angelegte Tabelle wp_neu_test den Import. Meist stört das nicht. Wollen Sie exakt den alten Stand, löschen Sie vor dem Import alle Tabellen mit dem WordPress-Präfix:

wp db clean --yes
wp db import ~/wp-backup/db-2026-09-30-2103.sql

wp db clean entfernt alle Tabellen mit dem Präfix aus der wp-config.php. Zwischen beiden Befehlen ist die Website nicht erreichbar, im Labor leitete sie auf die Installation um. Führen Sie beide Befehle daher direkt nacheinander aus und nur mit einem geprüften Dump.

Verifizieren: wp db check endet mit Success: Database checked., wp post list --post_type=post --fields=ID,post_title,post_date zeigt den erwarteten Stand, und die Startseite lädt mit HTTP 200.

Schritt 6: Sicherung automatisieren

Eine Sicherung, an die man denken muss, fehlt genau dann, wenn man sie braucht. Ein kurzes Skript fasst Export, Prüfung, Kompression und Aufräumen zusammen:

#!/bin/sh
set -eu
ZIEL="$HOME/wp-backup"
DATEI="$ZIEL/db-$(date +%F-%H%M).sql"
cd /var/www/html
wp db export "$DATEI" --add-drop-table --quiet
tail -n 1 "$DATEI" | grep -q "Dump completed"
gzip "$DATEI"
find "$ZIEL" -name "db-*.sql.gz" -mtime +14 -delete

Speichern Sie es als ~/bin/wp-db-backup.sh, machen Sie es mit chmod 700 ausführbar und tragen Sie es per crontab -e ein, zum Beispiel täglich um 3:15 Uhr: 15 3 * * * $HOME/bin/wp-db-backup.sh. Durch set -eu bricht das Skript beim ersten Fehler ab, ein unvollständiger Dump wird also nicht komprimiert und nicht als gültig abgelegt. find … -mtime +14 -delete löscht Sicherungen, die älter als 14 Tage sind. Wie Cronjobs mit WP-CLI grundsätzlich eingerichtet werden, zeigt die Anleitung WP-Cron durch echten System-Cron ersetzen.

Mit dem Skript ist die Arbeit nicht erledigt: Jemand muss prüfen, ob die Sicherungen ankommen, sie extern ablegen und ab und zu eine Wiederherstellung auf einer Testinstanz ausprobieren. Wer diese Aufgaben 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 die Updates von WordPress, Plugins und Themes.

Verifizieren: Führen Sie das Skript einmal von Hand aus. Danach liegt eine neue Datei db-….sql.gz im Zielordner, und echo $? direkt nach dem Aufruf gibt 0 aus.

Typische Fehler

• mariadb-dump: Can't create/write to file '/root/wp-backup/db.sql' (Errcode: 13 "Permission denied"): Der Benutzer, unter dem WP-CLI läuft, darf im Zielordner nicht schreiben. Im Labor lief WP-CLI als Webserver-Benutzer. Wählen Sie einen Ordner, der diesem Benutzer gehört.
• Got error: 1045: "Access denied for user …" when trying to connect: Benutzer oder Passwort stimmen nicht, im Labor provoziert mit --dbpass=falsch. Prüfen Sie wp config get DB_USER und DB_HOST und lassen Sie --dbuser und --dbpass weg, damit die Werte aus der wp-config.php gelten.
• Error: Import file missing or not readable: gibtsnicht.sql: Pfad falsch oder Datei nicht lesbar. Relative Pfade beziehen sich auf das aktuelle Verzeichnis.
• Komprimierte Sicherung zurückspielen: wp db import erwartet laut Handbuch eine SQL-Datei oder mit - die Standardeingabe. Entpacken Sie vorher mit gunzip -k oder übergeben Sie per Pipe: gunzip -c db.sql.gz | wp db import -.
• Nach wp db clean zeigt die Website die Installationsseite: WP-CLI meldet danach Run `wp core install` to create database tables. Führen Sie nicht wp core install aus, sondern sofort wp db import mit dem Dump.
• Neue Domain nach dem Import: Stammt der Dump von einer anderen Adresse, etwa einer Staging-Umgebung, ersetzen Sie URLs mit wp search-replace 'https://alt.example' 'https://neu.example' --dry-run und danach ohne --dry-run. Ein SQL-Replace zerstört serialisierte Daten.

Häufige Fragen

Reicht ein Datenbank-Backup?

Nein. Bilder und Dokumente in wp-content/uploads, Themes, Plugins und die wp-config.php liegen im Dateisystem. Sichern Sie diese zusätzlich, etwa mit tar. Die Datenbank ist aber der Teil, der sich täglich ändert, und verdient deshalb häufigere Sicherungen.

Wie oft sollte ich sichern?

So oft, wie Sie Datenverlust verkraften. Eine Firmenwebsite mit seltenen Änderungen kommt mit einer täglichen Sicherung aus. Bei einem Shop mit laufenden Bestellungen ist der Abstand zwischen zwei Sicherungen der Zeitraum, dessen Bestellungen im Ernstfall fehlen.

Kann ich einen Dump aus phpMyAdmin mit WP-CLI importieren?

Ja, sofern es eine SQL-Datei ist. wp db import führt beliebige SQL-Befehle aus. Achten Sie darauf, dass Tabellenpräfix und Zeichensatz zur Zielinstallation passen.

Ersetzt das die Sicherung beim Hoster?

Nein, es ergänzt sie. Hoster-Backups liegen meist in derselben Infrastruktur, und Sie wissen nicht immer, wie schnell eine Rücksicherung möglich ist. Ein eigener Dump vor jedem Update ist in einer Minute erstellt und sofort verfügbar, etwa für ein Rollback nach einem fehlgeschlagenen Plugin-Update.

Testumfang

Wir haben Export und Import am 30.09.2026 in einer Laborinstanz mit WordPress 7.1.2 durchgespielt, der erfolgreiche Import ließ sich über einen Testbeitrag nachweisen. Das Backup-Skript aus Schritt 6 lief fehlerfrei, erzeugte ein gültiges Archiv und löschte eine absichtlich zurückdatierte Altdatei. Den Cron-Eintrag selbst haben wir nicht getestet, prüfen Sie deshalb nach dem Einrichten, ob er wirklich ausgeführt wird.

Fazit

Mit wp db export und wp db import sichern und restaurieren Sie die WordPress-Datenbank schnell und ohne Passwort in der Befehlszeile. Den Unterschied machen die Details: Dumps außerhalb des Webroots ablegen, auf „Dump completed“ prüfen, vor jedem Import den aktuellen Stand sichern und die Sicherung auf einen zweiten Speicherort kopieren. Wer externe Backups und Updates lieber abgibt, findet das in der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• MySQL und PostgreSQL Backup automatisieren mit cron
• WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen
• WordPress-Plugin nach fehlerhaftem Update zurücksetzen
• WP-CLI-Handbuch: wp db export
• WP-CLI-Handbuch: wp db import
• WP-CLI-Handbuch: wp db check
• WP-CLI-Handbuch: wp search-replace