--- title: "WordPress-Datenbank mit WP-CLI sichern und wiederherstellen" date: 2026-09-30T21:08:17+02:00 modified: 2026-11-08T22:36:12+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-datenbank-wp-cli-sichern-wiederherstellen keywords: - WordPress - WP-CLI - Backup - Datenbank - MariaDB reading_time: 10 --- # 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, darunter eine Sicherung, die öffentlich herunterladbar sein kann. **Kurzfassung:** `wp db export` liest die Zugangsdaten aus der `wp-config.php` und schreibt einen vollständigen SQL-Dump. Legen Sie die Datei außerhalb des Webroots ab, sonst kann sie jeder per Browser laden. Prüfen Sie den Dump auf die Zeile „Dump completed“ und komprimieren Sie ihn. Zurück geht es mit `wp db import`. Achtung: Der Import löscht keine Tabellen, die erst nach dem Backup entstanden sind, und die Datenbank allein ist kein vollständiges Backup, denn Medien, Themes und Plugins liegen im Dateisystem. ## Voraussetzungen - [ ] **WordPress:** Die Befehle hängen kaum von der WordPress-Version ab. - [ ] **WP-CLI:** 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: ```bash $ 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. > **Prüfen:** `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: ```bash $ 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. Ein Dump enthält auch ohne diese Option oft 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. Sie heißt dann etwa `wp_w3-2026-09-30-ca88bca.sql` und liegt 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: ```bash $ 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. > **Prüfen:** 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: ```bash $ head -n 3 ~/wp-backup/db-*.sql $ tail -n 1 ~/wp-backup/db-*.sql $ grep -c "CREATE TABLE" ~/wp-backup/db-*.sql ``` Bei MariaDB beginnt der Dump mit `-- MariaDB dump 10.19-11.8.8-MariaDB` und endet 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. So komprimieren und prüfen Sie: ```bash $ 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. > **Prüfen:** `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. Ein Dump im WordPress-Verzeichnis ist in der Regel sofort per Browser abrufbar. `curl` auf `/wp_w3-2026-09-30-ca88bca.sql` liefert dann HTTP 200 und die komplette Datei, ebenso bei einer 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: ```bash $ 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](https://s-edv.com/anleitungen/mysql-postgresql-backup-automatisieren-cron-cloud) 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. > **Prüfen:** `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. ```bash $ 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 ``` Beim Zurückspielen verschwindet jeder Beitrag, der erst nach dem Dump entstanden ist. Die Ausgabe lautet `Success: Imported from 'wp-content/backup-test.sql'.`, und der Beitrag ist danach nicht mehr vorhanden. `wp cache flush` leert einen eventuell vorhandenen Objekt-Cache, damit WordPress keine veralteten Werte ausliefert. Ein wichtiges Detail: `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. Eine nachträglich angelegte Tabelle wie `wp_neu_test` überlebt 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: ```bash $ 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 und kann auf die Installation umleiten. Führen Sie beide Befehle daher direkt nacheinander aus und nur mit einem geprüften Dump. > **Prüfen:** `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: ```bash #!/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](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten). 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=17) übernimmt wöchentliche Backups auf externen Speicher mit vier Wochen Aufbewahrung sowie die Updates von WordPress, Plugins und Themes. > **Prüfen:** 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. Das kann etwa der Webserver-Benutzer sein. 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, etwa bei `--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](https://s-edv.com/anleitungen/wordpress-plugin-update-rollback-vorherige-version). ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=17) von Marcel Schönfelder. ## Weiterführende Anleitungen und Quellen - [MySQL und PostgreSQL Backup automatisieren mit cron](https://s-edv.com/anleitungen/mysql-postgresql-backup-automatisieren-cron-cloud) - [WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten) - [WordPress-Plugin nach fehlerhaftem Update zurücksetzen](https://s-edv.com/anleitungen/wordpress-plugin-update-rollback-vorherige-version) - [WP-CLI-Handbuch: wp db export](https://developer.wordpress.org/cli/commands/db/export/) - [WP-CLI-Handbuch: wp db import](https://developer.wordpress.org/cli/commands/db/import/) - [WP-CLI-Handbuch: wp db check](https://developer.wordpress.org/cli/commands/db/check/) - [WP-CLI-Handbuch: wp search-replace](https://developer.wordpress.org/cli/commands/search-replace/)