WordPress-Backup: sichern und Rücksicherung testen

Ein WordPress-Backup besteht aus zwei Teilen, die getrennt gesichert werden: der Datenbank und den Dateien. In der Datenbank stehen Beiträge, Seiten, Kommentare, Einstellungen und Benutzer. In den Dateien liegen Kern, Themes, Plugins, die hochgeladenen Bilder und die wp-config.php. Die WordPress-Dokumentation sagt es ausdrücklich: Die Datenbank liegt außerhalb des Installationsverzeichnisses, wer nur die Dateien herunterlädt, hat sie nicht (WordPress Backups).

Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Das BSI macht daraus eine Basis-Anforderung: Es muss regelmäßig getestet werden, „ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können“ (IT-Grundschutz, CON.3.A15). Der Test steht deshalb unten als eigener Abschnitt, nicht als Fußnote.

Was in die Sicherung gehört#

Der Export unter „Werkzeuge → Daten exportieren“ ist keine Sicherung. Die XML-Datei enthält laut Dokumentation Beiträge, Seiten, Kommentare, eigene Felder, Kategorien, Schlagwörter und Benutzer (Tools Export Screen). Von Einstellungen, Plugins, Themes und den Mediendateien selbst steht dort nichts.

Sichern mit WP-CLI, in fünf Minuten#

Die Befehle laufen im Verzeichnis der Installation auf dem Server. Ich habe sie am 05.10.2026 an einer Testinstallation geprüft (WordPress 7.1.2, deutsch, MariaDB 11.4, WP-CLI 2.12).

# Datenbank: ein konsistenter Stand, auch während die Seite läuft
wp db export - --single-transaction | gzip > ~/sicherungen/$(date +%F)-db.sql.gz

# Dateien: das ganze Installationsverzeichnis
tar -czf ~/sicherungen/$(date +%F)-dateien.tar.gz -C /pfad/zu/wordpress .

wp db export ruft mysqldump beziehungsweise mariadb-dump auf, schreibt mit - auf die Standardausgabe und reicht jede zusätzliche Option an das Programm weiter (wp db export). --single-transaction setzt WP-CLI nicht von selbst, die Testinstallation zeigt das mit --debug. Die Option liest alle Tabellen innerhalb einer Transaktion, sodass ein Beitrag, der während der Sicherung gespeichert wird, nicht halb in der Datei landet (MySQL-Handbuch, mysqldump). Sie wirkt bei InnoDB-Tabellen, und mit dieser Speicher-Engine legen aktuelle MySQL- und MariaDB-Server die Tabellen von WordPress an; in der Testinstallation alle zwölf.

Ob die Datei vollständig ist, zeigt ein kurzer Blick: Eine frische Installation hat zwölf Tabellen, gunzip -c …-db.sql.gz | grep -c 'CREATE TABLE' muss mindestens diese Zahl liefern. Plugins legen weitere an. Die Größe der Datenbank vorher nennt wp db size --human-readable.

Ohne Shell geht dasselbe im Kundenmenü des Hosters: Datenbank in phpMyAdmin über „Exportieren“ als SQL, Dateien per SFTP herunterladen. Die Dokumentation beschreibt den phpMyAdmin-Weg Schritt für Schritt. Es dauert länger, das Ergebnis ist dasselbe.

Wohin die Sicherung gehört#

Die Dokumentation empfiehlt mindestens drei bis fünf aktuelle Stände an verschiedenen Orten, etwa einen beim Hoster, einen in einem Cloud-Speicher und einen auf dem eigenen Rechner. Wöchentlich für kleine Seiten, täglich für Seiten mit viel Bewegung. Automatische Sicherungen soll ab und zu eine manuelle ergänzen, „to guarantee that the process is working“.

Wichtiger als die Zahl ist, wer die Sicherung löschen kann. CON.3.A14 verlangt, dass Sicherungen „nicht absichtlich oder unbeabsichtigt überschrieben werden können“, und CON.3.A12, dass sie räumlich getrennt von den gesicherten Systemen liegen. Eine Sicherung auf demselben Server erfüllt beides nicht. Und eine, die der Server selbst per FTP-Zugang auf einen Speicher schiebt, auch nicht ganz: Wer den Server übernimmt, hat diesen Zugang mit.

Deshalb die Sicherung abholen, statt sie schicken zu lassen. Der Server legt die beiden Dateien in einem Ordner außerhalb des Webverzeichnisses ab, und der eigene Rechner oder ein NAS holt sie per SSH:

# auf dem eigenen Rechner, nicht auf dem Server
rsync -av benutzer@server.example:sicherungen/ ~/wp-sicherungen/

Kein --delete, sonst löscht ein geleerter Ordner auf dem Server auch die Kopie. Auf dem Server reicht eine kurze Aufbewahrung, etwa find ~/sicherungen -name '*.gz' -mtime +14 -delete, auf dem eigenen Rechner bleiben die älteren Stände.

Zwei Dinge, die oft übersehen werden. Erstens enthält die Sicherung die wp-config.php mit dem Datenbankpasswort und die Datenbank mit Kundendaten aus Formularen und Bestellungen. Sie gehört verschlüsselt abgelegt, etwa mit gpg -c vor dem Hochladen in einen Cloud-Speicher. Zweitens hat sie im Webverzeichnis nichts verloren. Eine backup.sql oder ein Archiv unter wp-content, das sich per Adresse abrufen lässt, ist eine Datenpanne. Der Security-Scan prüft von außen unter anderem, ob Dateien wie /backup.sql offen liegen.

Die Rücksicherung proben#

Geprobt wird nicht auf der Live-Seite, sondern in einer Probe-Umgebung: eine Subdomain mit Passwortschutz beim Hoster oder eine lokale Installation. In der Testinstallation, einer fast leeren Seite, liefen die Befehle in Sekunden. Bei einer echten Seite mit einigen Gigabyte Uploads bestimmt die Übertragung die Zeit, und genau diese Zahl soll die Probe liefern.

1. Dateien entpacken. tar -xzf 2026-10-21-dateien.tar.gz -C /pfad/zur/probe

2. Eigene Datenbank eintragen. In der entpackten wp-config.php stehen die Zugangsdaten der Live-Datenbank. Bevor irgendetwas importiert wird, müssen dort die Daten der Probe-Datenbank stehen: wp config set DB_NAME probe_db und entsprechend DB_USER und DB_PASSWORD. Wer diesen Schritt auslässt, spielt die Sicherung in die Live-Datenbank.

3. Datenbank einspielen. gunzip -c 2026-10-21-db.sql.gz | wp db import -, das - liest von der Standardeingabe (wp db import).

4. Adresse umschreiben. Zuerst nur ansehen, dann ausführen:

wp search-replace 'https://www.deine-domain.at' 'https://probe.deine-domain.at' --skip-columns=guid --dry-run
wp search-replace 'https://www.deine-domain.at' 'https://probe.deine-domain.at' --skip-columns=guid

Der Befehl behandelt serialisierte PHP-Daten richtig, ein Suchen-und-Ersetzen im SQL-Text mit dem Editor nicht (wp search-replace).

5. Prüfen. wp core verify-checksums vergleicht den Kern mit WordPress.org, danach Startseite, eine Unterseite, ein Bild, das Kontaktformular und die Anmeldung durchklicken. Bei einem Shop eine Bestellung im Backend öffnen.

6. Notieren. Datum, Dauer, was gefehlt hat. Fehlt etwas, ist die Sicherung unvollständig, nicht die Probe.

Die Reihenfolge Dateien vor Datenbank stammt aus der Dokumentation. Danach die Probe löschen oder zumindest gesperrt lassen, denn sie ist eine vollständige Kopie mit allen Daten.

Was nicht hilft#

Nur die Sicherung des Hosters. Sie liegt beim selben Anbieter, die Aufbewahrung ist oft kurz, und ob sie sich zurückspielen lässt, hat niemand probiert. Frag nach drei Dingen: wie lange sie aufbewahrt wird, ob sich Datenbank und Dateien einzeln zurückholen lassen und ob die Rücksicherung etwas kostet.

Ein Sicherungs-Plugin, das in wp-content speichert. Das Plugin ist nicht das Problem, der Speicherort schon. Das Archiv liegt auf demselben Server und im schlechtesten Fall im Webverzeichnis.

Nur die Dateien per FTP. Ohne Datenbank fehlen sämtliche Inhalte. Umgekehrt fehlen ohne Dateien alle Bilder.

Die Sicherung von gestern nach einem Einbruch. Sie kann den Schadcode schon enthalten. Welcher Sicherung man nach einem Angriff noch trauen kann, steht in WordPress gehackt: was tun.

Einmal einrichten, viermal im Jahr proben#

Sicherungen fallen erst auf, wenn man sie braucht, und dann ist es für einen Test zu spät. Einmal einrichten, wohin sie gehen und wer sie löschen kann, dann viermal im Jahr eine Probe mit Stoppuhr. Die Sicherung ist auch Punkt 9 der Prüfliste in WordPress-Sicherheit prüfen und die Voraussetzung für jedes größere WordPress-Update. Wer das nicht selbst machen will: In der WordPress-Wartung laufen die Sicherungen täglich außerhalb des Servers, und vor jedem Update gibt es eine frische.

Stand 21.10.2026. Befehle am 05.10.2026 an einer Testinstallation geprüft (WordPress 7.1.2 de_DE, MariaDB 11.4.13, PHP 8.3, WP-CLI 2.12.0), einschließlich Rücksicherung in eine zweite Datenbank. Dokumentation von WordPress.org und BSI am selben Tag gelesen.