So sichern Sie eine WordPress-Website

Ein vollständiges WordPress-Backup besteht aus einer gemeinsam erfassten Kopie zweier Komponenten: Ihrer Dateien und Ihrer MySQL-Datenbank. Fehlt eine der beiden, schlägt die Wiederherstellung fehl. Dieser Leitfaden beschreibt den zuverlässigen Weg, dies über die Kommandozeile zu erreichen — mit mysqldump, tar und einem Cron-Job, der Archive extern speichert — damit Sie das Backup selbst kontrollieren, anstatt es von einem Plugin abhängig zu machen. Außerdem werden Host- und Plugin-Optionen sachlich bewertet, und es werden die Wiederherstellungsbefehle gezeigt, mit denen Sie beweisen können, dass ein Backup tatsächlich funktioniert.

Was umfasst ein vollständiges WordPress-Backup?

Eine WordPress-Website besteht aus zwei separaten Systemen, und ein Backup muss beide erfassen. Die Dateien umfassen den WordPress-Core, alles unter wp-content — Ihre Themes, Plugins und den uploads-Ordner (in der Regel der größte Teil) — sowie die wp-config.php im Stammverzeichnis. Unter Apache sollten Sie auch .htaccess sichern; unter nginx oder Caddy gibt es keine .htaccess-Datei, da Rewrites in der Serverkonfiguration außerhalb des Web-Roots definiert sind. Die Datenbank ist eine MySQL-Datenbank, die Ihre Beiträge, Seiten, Kommentare, Benutzer, Taxonomien sowie alle Plugin- und Theme-Einstellungen enthält.

Der häufigste Anfängerfehler ist das Sichern von Dateien über FTP, ohne die Datenbank zu berücksichtigen. Themes und Core können erneut heruntergeladen werden — Ihre Inhalte nicht. Wenn ein „Backup” nur aus Dateien besteht, startet die wiederhergestellte Website ohne Beiträge und ohne Einstellungen.

Welche drei Methoden gibt es, um WordPress zu sichern?

Es gibt drei praktische Ansätze, die Komfort gegen Kontrolle abwägen.

Host-Backups sind praktisch, sollten aber nicht Ihre einzige Kopie sein — Aufbewahrungsfristen sind kurz, und wenn der Server kompromittiert wird oder ausfällt, können die darauf gespeicherten Backups ebenfalls verloren gehen. Plugins wie UpdraftPlus übernehmen Zeitplanung und Cloud-Upload über das Dashboard und sind eine vernünftige Wahl für Nicht-Entwickler. Der CLI-Ansatz ist derjenige, den ein Entwickler versionieren, planen und überprüfen kann.

WordPress über die Kommandozeile sichern

Das Kommandozeilen-Backup besteht aus drei Schritten über SSH: Datenbank sichern, Dateien archivieren und beides vom Server übertragen. Verbinden Sie sich zunächst:

ssh user@example.com -p 2222

Archivieren Sie dann die Dateien und sichern Sie die Datenbank:

# Archivierung der Website-Dateien aus dem Verzeichnis oberhalb des Web-Roots
tar -zcf files.tar.gz public_html

# Datenbank mit konsistentem Snapshot sichern
mysqldump --single-transaction -u DB_USER -p DB_NAME > db.sql

Das Flag --single-transaction macht den Dump auf einer laufenden Website zuverlässig. Nur InnoDB-Tabellen werden in einem konsistenten Zustand gesichert; MyISAM- oder MEMORY-Tabellen können sich während des Dumps noch ändern. Da WordPress standardmäßig auf InnoDB läuft, ist --single-transaction eine deutlich bessere Option als --lock-tables, da die Tabellen dabei überhaupt nicht gesperrt werden müssen — Ihre Website bleibt während des Vorgangs erreichbar. Verwenden Sie mysqldump, nicht mysqlpump — letzteres wurde in MySQL 8.4 entfernt, sodass Skripte, die es aufrufen, auf aktuellen Servern schlicht fehlschlagen.

Übertragen Sie beide Dateien mit scp:

scp -P 2222 user@example.com:~/files.tar.gz .
scp -P 2222 user@example.com:~/db.sql .

Ein Fallstrick, den viele Anleitungen übergehen: scp verwendet für den Port ein großgeschriebenes -P, während ssh und mysqldump ein kleingeschriebenes -p verwenden (für Port bzw. Passwort). Diese zu verwechseln ist ein klassischer Fehler bei der Befehlsausführung.

Wenn Sie WP-CLI installiert haben, ist wp db export die sauberere Lösung: Es führt das mysqldump-Dienstprogramm mit den in wp-config.php angegebenen Zugangsdaten DB_HOST, DB_NAME, DB_USER und DB_PASSWORD aus und akzeptiert alle gültigen mysqldump-Flags.

wp db export --single-transaction db.sql

Auf verwalteten Hosts und cPanel-Hosts kann ein einfaches mysqldump beim Sichern von Tablespaces mit einem PROCESS-Berechtigungsfehler fehlschlagen. WP-CLI behandelt dies bereits: wp db export fügt mysqldump standardmäßig --no-tablespaces hinzu. Bei der direkten Verwendung von mysqldump auf einem verwalteten Host fügen Sie --no-tablespaces selbst hinzu.

WordPress-Backups mit Cron und rclone automatisieren

Automatisieren Sie den gesamten Prozess mit einem kurzen Shell-Skript in einem Cron-Zeitplan, das die Datenbank sichert, wp-content mit tar archiviert und das Archiv auf einen externen Server überträgt. rclone — „rsync für Cloud-Speicher” — unterstützt unter anderem S3, Backblaze B2 und Google Drive.

#!/usr/bin/env bash
set -euo pipefail

SITE_DIR="/var/www/example.com"
DEST="b2remote:example-backups"     # ein konfiguriertes rclone-Remote
STAMP="$(date +%F)"
WORK="$(mktemp -d)"

cd "$SITE_DIR"

# Datenbank — WP-CLI liest Zugangsdaten aus wp-config.php
wp db export --single-transaction "$WORK/db-$STAMP.sql"

# Dateien — Themes, Plugins, Uploads sowie Konfiguration
tar -zcf "$WORK/wp-content-$STAMP.tar.gz" wp-content wp-config.php

# Extern übertragen
rclone copy "$WORK" "$DEST/$STAMP"

rm -rf "$WORK"

Planen Sie die Ausführung mit einer Crontab-Zeile, die täglich um 03:15 Uhr ausgeführt wird und die Ausgabe protokolliert:

15 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

Das ist der eigentliche Vorteil des „eigene Backups kontrollieren”-Ansatzes: kein Dashboard, kein Plugin, kein manueller Schritt. Falls WP-CLI nicht installiert ist, ersetzen Sie die Export-Zeile durch mysqldump --single-transaction --no-tablespaces -u DB_USER -pPASS DB_NAME > "$WORK/db-$STAMP.sql".

Backups nach der 3-2-1-Regel speichern

Befolgen Sie die 3-2-1-Regel: Halten Sie mindestens drei Kopien Ihrer Website vor, auf zwei verschiedenen Speichermedien, wobei eine Kopie extern aufbewahrt wird. Lassen Sie niemals das einzige Backup auf demselben Server wie die Website liegen — ein Angriff oder ein Festplattenausfall vernichtet beides gleichzeitig. Genau deshalb überträgt das obige Automatisierungsskript die Daten in einen Objektspeicher, anstatt das Archiv im Web-Root zu belassen. Da das Archiv eine vollständige Kopie Ihrer Website enthält, einschließlich sensibler Daten in wp-config.php, sichern Sie das Ziel mit starken Zugangsdaten und Zwei-Faktor-Authentifizierung für das Speicherkonto.

Wiederherstellung testen und häufige Fehler vermeiden

Ein ungetestetes Backup ist kein Backup. Stellen Sie Ihre .sql- und Dateiarchive regelmäßig auf einer Staging- oder lokalen Website wieder her, um zu beweisen, dass die Kopie tatsächlich eine funktionsfähige Website aufbaut:

tar -xzf wp-content-2026-07-06.tar.gz
wp db import db-2026-07-06.sql          # oder, ohne WP-CLI:
mysql -u DB_USER -p DB_NAME < db-2026-07-06.sql

Drei Fehlerszenarien sind für den Großteil verlorener Websites verantwortlich: Dateien ohne Datenbank sichern, das Backup auf demselben Server wie die Website aufbewahren und sich ausschließlich auf automatische Host-Backups verlassen. Jedes davon lässt sich mit dem oben beschriebenen Workflow vermeiden.

Das zuverlässige Muster ist schlicht und unspektakulär: ein Cron-Job, der die Datenbank konsistent sichert, die Dateien archiviert, beides extern überträgt und eine Wiederherstellung, die Sie tatsächlich testen. Schreiben Sie das Skript einmal, richten Sie es auf einen Objektspeicher aus, fügen Sie die Crontab-Zeile hinzu und führen Sie diese Woche einen Test-Restore durch — das ist ein Backup, das Sie kontrollieren, anstatt eines, von dem Sie nur hoffen, dass es läuft.

Häufig gestellte Fragen

Was ist der Unterschied zwischen wp db export und dem direkten Ausführen von mysqldump?

wp db export ist ein schlanker Wrapper um mysqldump. Es führt das mysqldump-Dienstprogramm mit den bereits in wp-config.php gespeicherten Zugangsdaten DB_HOST, DB_NAME, DB_USER und DB_PASSWORD aus, sodass Sie keine Verbindungsdetails nachschlagen oder übergeben müssen. Es akzeptiert außerdem alle gültigen mysqldump-Flags und fügt standardmäßig --no-tablespaces hinzu, wodurch der auf verwalteten Hosts häufige PROCESS-Berechtigungsfehler vermieden wird. Rohes mysqldump liefert denselben Dump, erfordert jedoch die manuelle Angabe von Zugangsdaten und Flags.

Warum wirft mysqldump auf verwalteten Hosts einen PROCESS-Berechtigungsfehler, und wie behebe ich ihn?

Auf verwalteten Hosts und cPanel-Hosts versucht mysqldump, Tablespace-Informationen zu sichern, was die PROCESS-Berechtigung erfordert, die gemeinsam genutzte Datenbankbenutzer in der Regel nicht besitzen. Dies führt zur Fehlermeldung 'Access denied; you need the PROCESS privilege'. Fügen Sie das Flag --no-tablespaces hinzu, um diesen Schritt zu überspringen — der Dump wird dann normal abgeschlossen. WP-CLIs wp db export fügt --no-tablespaces automatisch hinzu. In den meisten Fällen gelingt der Export trotz des Fehlers, prüfen Sie den Dump jedoch, indem Sie sicherstellen, dass Ihre Tabellen vorhanden sind.

Kann ich Datei-Backups überspringen, da WordPress-Core und Plugins erneut heruntergeladen werden können?

Sie können den Umfang des Archivs reduzieren, aber Dateien niemals vollständig weglassen. WordPress-Core, Themes und Plugins können aus ihren Quellen erneut heruntergeladen werden, weshalb manche Backup-Tools nur die Datenbank und den uploads-Ordner speichern. Der uploads-Ordner enthält jedoch alle Mediendateien, die nicht erneut heruntergeladen werden können, wp-config.php enthält Ihre Datenbankzugangsdaten und Schlüssel, und alle benutzerdefinierten oder modifizierten Dateien sind unersetzlich. Die Sicherung von wp-content und wp-config.php erfasst die Teile, die für Ihre Website wirklich einzigartig sind.

Wie stelle ich eine WordPress-Website aus einem mysqldump- und tar-Backup wieder her?

Entpacken Sie das Dateiarchiv mit tar -xzf archive.tar.gz in das Website-Verzeichnis und importieren Sie anschließend die Datenbank. Mit WP-CLI führen Sie wp db import db.sql aus, das die Zugangsdaten aus wp-config.php liest. Ohne WP-CLI führen Sie mysql -u DB_USER -p DB_NAME < db.sql gegen eine bestehende Datenbank aus. Stellen Sie beide Teile gemeinsam wieder her, und wenn sich die Domain geändert hat, führen Sie ein Search-Replace in der Datenbank durch, um gespeicherte URLs zu aktualisieren. Testen Sie die Wiederherstellung immer auf einer Staging- oder lokalen Website, bevor Sie ihr in der Produktion vertrauen.

Ist mysqldump noch sicher zu verwenden, oder sollte ich auf mysqlpump umsteigen?

Verwenden Sie mysqldump, nicht mysqlpump. Das mysqlpump-Dienstprogramm wurde in MySQL 8.0.34 als veraltet markiert und in MySQL 8.4 vollständig entfernt, sodass Skripte, die es aufrufen, auf aktuellen Servern fehlschlagen. mysqldump wird weiterhin unterstützt und gepflegt; MySQL empfiehlt mysqldump oder die MySQL Shell Dump Utilities als Ersatz. Für einen konsistenten Snapshot einer laufenden InnoDB-Website führen Sie mysqldump mit dem Flag --single-transaction aus, das das Sperren von Tabellen während des Dumps vermeidet.