WordPress vor großen Änderungen sichern: Snapshot beim Hoster und eigenes Backup mit WP-CLI

Relaunch, Theme-Wechsel, neues Shop-Plugin, Umzug auf eine neue PHP-Version: Bei großen Änderungen an einer WordPress-Website ist das nächtliche Backup oft schon einen Tag alt und liegt nicht dort, wo Sie es in zehn Minuten zurückspielen können. Vor solchen Eingriffen brauchen Sie einen eigenen Sicherungspunkt, möglichst doppelt: einen Snapshot beim Hoster und ein eigenes Backup von Datenbank und Dateien. Diese Anleitung zeigt beides und übt den Rückweg. Den Ablauf mit WP-CLI haben wir in einer Testinstanz mit WordPress 7.1.2 vollständig durchgespielt, einschließlich einer Falle beim Zurückspielen der Datenbank.

Voraussetzungen

• WordPress in einer aktuellen Version (getestet mit 7.1.2) mit PHP in einer unterstützten Version (Test: PHP 8.4)
• Benutzerkonto mit der Rolle Administrator
• SSH-Zugang mit WP-CLI (getestet mit WP-CLI 2.12.0) für das eigene Backup; ohne SSH nutzen Sie das Backup-Werkzeug Ihres Hosters oder ein Backup-Plugin
• Zugang zum Kundenbereich des Hosters, falls Sie Snapshots nutzen wollen; prüfen Sie vorher, ob Ihr Tarif Snapshots anbietet
• Freier Speicherplatz mindestens in Höhe von Datenbank und wp-content, besser das Doppelte
• Ein bestehendes, regelmäßiges Backup. Der Sicherungspunkt ergänzt es, er ersetzt es nicht

Schritt 1: Änderung planen und Rückweg festlegen

Bevor Sie sichern, klären Sie drei Fragen. Was genau ändert sich? Ein Theme-Wechsel betrifft Dateien und Optionen, ein neues Shop-Plugin legt eigene Datenbanktabellen an, ein PHP-Wechsel betrifft den Server. Wie lange dauert die Änderung? Und bis zu welchem Zeitpunkt entscheiden Sie sich für den Rückweg?

Die letzte Frage ist die wichtigste. Ein Rücksprung auf den Sicherungspunkt stellt die ganze Datenbank auf den alten Stand. Alles, was seitdem passiert ist, geht verloren: Bestellungen, Formulareinsendungen, Kommentare, neue Benutzerkonten. Bei einer Visitenkarten-Seite ist das kein Problem. Bei einem Shop mit laufenden Bestellungen ist es eines. Deshalb gehören große Änderungen in ein Zeitfenster mit wenig Besuchern, bei Shops zusätzlich mit kurz pausiertem Bestellvorgang.

Schreiben Sie außerdem auf, woran Sie Erfolg messen: Startseite lädt, Kontaktformular sendet, Kasse funktioniert, keine Fehler im Log. Ohne solche Kriterien wird die Entscheidung für den Rückweg zur Gefühlsfrage, und dann wird sie meist zu spät getroffen.

Wenn die Änderung umfangreich ist, spielen Sie sie zuerst auf einer Kopie der Website durch. Wie Sie eine solche Kopie aufsetzen, beschreibt die Anleitung Staging-Umgebung für WordPress einrichten. Der Sicherungspunkt auf der Live-Website bleibt trotzdem Pflicht.

Verifizieren: Änderung, Zeitfenster, Erfolgskriterien und die späteste Rückroll-Entscheidung stehen schriftlich fest.

Schritt 2: Snapshot beim Hoster anlegen

Ein Snapshot friert den Zustand eines ganzen Servers oder Webspaces ein. Bei einem VPS umfasst er die komplette virtuelle Festplatte: Betriebssystem, Webserver, PHP, Datenbank und Dateien. Bei Webhosting-Tarifen heißt die Funktion oft Sicherungspunkt, Wiederherstellungspunkt oder manuelles Backup und umfasst Webspace und Datenbanken. Wo sie im Kundenbereich liegt und was genau gesichert wird, beschreibt die Dokumentation Ihres Hosters.

Der Vorteil eines Snapshots: Er ist schnell erstellt und im Ernstfall mit wenigen Klicks zurückgespielt. Die Nachteile sollten Sie kennen. Ein Snapshot liegt meist beim selben Anbieter, oft auf derselben Infrastruktur, und schützt deshalb nicht vor Problemen beim Hoster selbst. Das Zurückspielen setzt in der Regel den ganzen Server oder Webspace zurück, auch andere Websites im selben Tarif. Bei laufenden Datenbanken kann ein Snapshot im Betrieb einen Zustand mitten in einem Schreibvorgang erfassen. Viele Anbieter empfehlen deshalb für konsistente Snapshots einen gestoppten Server; die Anleitung netcup VPS-Snapshots: Offline- vs. Online-Snapshot zeigt diesen Unterschied am Beispiel eines Anbieters.

Benennen Sie den Snapshot eindeutig, etwa mit Datum und Anlass. Notieren Sie, wie lange der Anbieter ihn aufbewahrt, und löschen Sie ihn nach erfolgreicher Änderung, wenn er Speicherkontingent belegt.

Verifizieren: Der Snapshot erscheint im Kundenbereich mit Status „fertig“ bzw. der entsprechenden Anzeige Ihres Hosters, Datum und Uhrzeit liegen unmittelbar vor der geplanten Änderung.

Schritt 3: Eigenes Backup von Datenbank und Dateien

Das eigene Backup ist unabhängig vom Hoster und lässt sich gezielt zurückspielen, ohne andere Websites zu berühren. Legen Sie zuerst einen Ordner außerhalb des öffentlichen Webverzeichnisses an. Das ist wichtig: Im Test haben wir den Ordner absichtlich im WordPress-Verzeichnis angelegt, und der Datenbank-Dump war danach über den Browser mit Status 200 abrufbar. Ein Dump enthält Benutzerdaten und Passwort-Hashes und darf niemals öffentlich erreichbar sein.

# Ordner außerhalb des Webroots, Pfad an Ihren Server anpassen
mkdir -p ~/sicherungspunkt
cd /var/www/html

# Datenbank
wp db export ~/sicherungspunkt/db-vorher.sql

# Dateien: wp-content, wp-config.php, .htaccess
tar -czf ~/sicherungspunkt/dateien-vorher.tar.gz wp-content wp-config.php .htaccess

Im Test meldete WP-CLI Success: Exported to 'sicherungspunkt/db-vorher.sql'. Die Kerndateien von WordPress brauchen Sie nicht zu sichern, sie lassen sich jederzeit mit wp core download in der passenden Version neu laden. Unter Nginx gibt es keine .htaccess; lassen Sie die Datei dann im tar-Befehl weg, sonst meldet tar einen Fehler und endet mit Exit-Code 2. Die Nginx-Konfiguration liegt außerhalb von WordPress und gehört gegebenenfalls separat gesichert.

Prüfen Sie das Ergebnis sofort, nicht erst im Ernstfall:

ls -lh ~/sicherungspunkt
grep -c "CREATE TABLE" ~/sicherungspunkt/db-vorher.sql
tar -tzf ~/sicherungspunkt/dateien-vorher.tar.gz | grep -c uploads

Die Zahl der CREATE TABLE-Zeilen muss der Zahl der Tabellen entsprechen, die wp db tables anzeigt, und im Archiv müssen Einträge aus uploads auftauchen. Wer auf Nummer sicher gehen will, kopiert beide Dateien zusätzlich auf den eigenen Rechner oder einen externen Speicher.

Verifizieren: Beide Dateien existieren mit plausibler Größe außerhalb des Webroots, die Tabellenanzahl stimmt, das Archiv enthält Uploads und Themes.

Schritt 4: Änderung durchführen

Führen Sie die Änderung jetzt durch. Für Eingriffe, bei denen Besucher kurzzeitig eine halbfertige Seite sähen, können Sie den Wartungsmodus nutzen:

wp maintenance-mode activate
# ... Änderung ...
wp maintenance-mode deactivate

Im Test lieferte die Startseite bei aktivem Wartungsmodus den Statuscode 503, danach wieder 200. Der Statuscode 503 signalisiert Suchmaschinen eine vorübergehende Nichtverfügbarkeit. Lassen Sie den Wartungsmodus nicht länger als nötig aktiv; falls er nach einem Abbruch hängen bleibt, hilft die Anleitung Wartungsmodus in WordPress beheben.

Prüfen Sie nach der Änderung Ihre Erfolgskriterien aus Schritt 1 der Reihe nach. Sehen Sie auch ins PHP-Fehlerprotokoll, denn manche Probleme zeigen sich nicht auf der Startseite, sondern erst in Unterseiten oder im Backend.

Verifizieren: Alle Erfolgskriterien aus Schritt 1 sind erfüllt, der Wartungsmodus ist aus, wp maintenance-mode status meldet Maintenance mode is not active.

Schritt 5: Rückweg im Fehlerfall

Sind die Erfolgskriterien nicht erfüllt und ist die späteste Entscheidungszeit erreicht, rollen Sie zurück. Mit dem Snapshot geht das über den Kundenbereich des Hosters. Mit dem eigenen Backup so:

cd /var/www/html
rm -rf wp-content
tar -xzf ~/sicherungspunkt/dateien-vorher.tar.gz wp-content
chown -R www-data:www-data wp-content

wp db reset --yes
wp db import ~/sicherungspunkt/db-vorher.sql
wp cache flush

Der Befehl wp db reset vor dem Import ist kein Versehen. Im Test hatten wir nach dem Sicherungspunkt eine zusätzliche Tabelle angelegt, wie es ein neu installiertes Plugin tut. Ein Import ohne vorheriges Leeren stellte zwar alle alten Tabellen wieder her, die neue Tabelle blieb aber stehen, denn der Dump löscht nur die Tabellen, die er selbst enthält. Solche Reste stören meist nicht sofort, können aber bei einer späteren Neuinstallation des Plugins zu verwirrendem Verhalten führen. Mit wp db reset vorher war die Tabelle verschwunden. Prüfen Sie vor diesem Befehl mit wp config get DB_NAME, dass Sie in der richtigen Installation arbeiten.

Der Benutzer www-data gilt für Debian und Ubuntu; bei anderen Systemen heißt der Webserver-Benutzer anders. Im Test waren nach dem Rückweg das ursprüngliche Theme wieder aktiv, das neue Plugin verschwunden, ein gelöschter Beitrag zurück und der geänderte Seitentitel wieder auf dem alten Wert.

Sicherungspunkte vor großen Änderungen sind Teil einer laufenden Aufgabe: Auch zwischen den Relaunches braucht die Website regelmäßige Backups und Updates. 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 Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung.

Verifizieren: wp theme list --status=active und wp plugin list zeigen den Stand vor der Änderung, der jüngste Beitrag vor dem Sicherungspunkt ist vorhanden, die Erfolgskriterien sind wieder erfüllt.

Typische Fehler

Datenbank-Dump im Browser abrufbar: Der Sicherungsordner liegt im Webroot. Im Test lieferte der Aufruf des Dumps Status 200. Verschieben Sie den Ordner aus dem öffentlichen Verzeichnis und löschen Sie die Dateien dort.

Tabellen eines neuen Plugins bleiben nach dem Rückweg erhalten: Die Datenbank wurde ohne wp db reset importiert. Wiederholen Sie den Rückweg mit Reset oder entfernen Sie die Tabellen gezielt, nachdem Sie deren Herkunft geprüft haben.

Bestellungen oder Formulareinsendungen fehlen nach dem Rückweg: Sie wurden zwischen Sicherungspunkt und Rückweg angelegt. Exportieren Sie solche Daten vor dem Rücksprung aus dem Backend, etwa als CSV, und tragen Sie sie danach nach.

Snapshot setzt mehr zurück als gedacht: Der Snapshot umfasste den ganzen Server oder Webspace, also auch andere Websites oder E-Mail-Postfächer. Prüfen Sie vorher, was Ihr Hoster sichert.

tar meldet „Cannot stat: No such file or directory“: Eine der angegebenen Dateien fehlt, häufig .htaccess unter Nginx. Entfernen Sie sie aus dem Befehl.

Häufige Fragen

Reicht nicht einfach das nächtliche Backup?

Nur, wenn es unmittelbar vor der Änderung entstanden ist und Sie es schnell zurückspielen können. Meist liegen Stunden dazwischen, und alle Änderungen dieses Zeitraums wären beim Rückweg verloren.

Snapshot oder eigenes Backup, wenn ich mich entscheiden muss?

Das eigene Backup, weil es unabhängig vom Hoster ist und gezielt nur WordPress betrifft. Der Snapshot ist die bequemere, schnellere Ergänzung für Änderungen am Server selbst.

Wann lösche ich den Sicherungspunkt?

Wenn die Änderung einige Tage stabil läuft und das reguläre Backup den neuen Stand gesichert hat. Löschen Sie die Dateien dann auch vom Server, sie enthalten personenbezogene Daten.

Testumfang

Wir haben die Sicherung mit wp db export und einem tar-Archiv am 30.09.2026 in einer isolierten Testinstanz mit WordPress 7.1.2 durchgespielt. Den Rückweg nach mehreren Änderungen haben wir mit und ohne vorheriges Zurücksetzen der Datenbank geprüft. Außerdem haben wir kontrolliert, ob ein Dump im Webroot öffentlich abrufbar ist.

Snapshots bei Hostern haben wir nicht getestet, weil Funktion und Umfang je Anbieter verschieden sind. Probieren Sie diese deshalb zuerst an einer Kopie aus.

Fazit

Große Änderungen an WordPress brauchen einen frischen Sicherungspunkt und einen geübten Rückweg. Der Snapshot beim Hoster ist schnell, das eigene Backup mit wp db export und tar ist unabhängig und gezielt. Legen Sie die Dateien außerhalb des Webroots ab, leeren Sie die Datenbank vor dem Import und bestimmen Sie vorher, bis wann Sie zurückrollen. Für die regelmäßigen Backups zwischen den großen Änderungen können Sie die WordPress-Wartung von Marcel Schönfelder beauftragen.

Weiterführende Anleitungen und Quellen

• Staging-Umgebung für WordPress einrichten
• WordPress-Wiederherstellung testen: Restore-Probe
• netcup VPS-Snapshots: Offline- vs. Online-Snapshot
• Wartungsmodus in WordPress beheben und nutzen
• WP-CLI-Handbuch: wp db export
• WP-CLI-Handbuch: wp db import
• WP-CLI-Handbuch: wp maintenance-mode
• Advanced Administration Handbook: Backups