WordPress-Backup-Strategie: Dateien, Datenbank und Aufbewahrung richtig planen

Ein Backup ist erst dann etwas wert, wenn Sie daraus Ihre Website in vertretbarer Zeit und mit vertretbarem Datenverlust zurückholen können. Viele Unternehmenswebsites haben zwar „irgendein Backup“ beim Hoster, aber niemand weiß, was es enthält, wie lange es aufbewahrt wird und ob es sich zurückspielen lässt. Diese Anleitung hilft Ihnen, eine Backup-Strategie für WordPress schriftlich festzulegen: welche Bestandteile Sie sichern, wie oft, wo die Kopien liegen, wie lange Sie sie aufbewahren und wie Sie die Wiederherstellung prüfen.

Voraussetzungen

• WordPress: beliebige aktuelle Version. Die Beispiele wurden mit WordPress 7.1.2, PHP 8.4 und MariaDB 11.8 getestet.
• Rolle: Administrator im WordPress-Backend und Zugang zur Verwaltungsoberfläche des Hosters.
• Dateizugriff: FTP/SFTP oder SSH. Für die Beispielbefehle SSH mit WP-CLI.
• Externer Speicher: ein Ziel außerhalb des Webservers, etwa ein NAS im Büro, ein SFTP-Server oder ein S3-kompatibler Objektspeicher.
• Zeit: etwa 30 Minuten für Bestandsaufnahme und Plan, zusätzlich Zeit für den ersten Wiederherstellungstest.
• Eine vorhandene Sicherung vor allen Änderungen an der Website, etwa die des Hosters.

Schritt 1: Festlegen, was gesichert werden muss

Eine WordPress-Website besteht aus zwei Teilen, die an verschiedenen Orten liegen. Das offizielle Handbuch betont ausdrücklich, dass Sie beide brauchen, um eine Website vollständig wiederherzustellen.

Bestandteil	Inhalt	Warum wichtig
Datenbank	Beiträge, Seiten, Kommentare, Benutzer, Einstellungen, Plugin-Daten, Bestellungen	Ändert sich laufend, ist nicht aus anderen Quellen wiederherstellbar
wp-content/uploads	Bilder, PDFs, Medien	Eigene Inhalte, oft der größte Teil
wp-content/themes und plugins	Theme, Child-Theme, Plugins	Eigene Anpassungen und Premium-Plugins sind nicht öffentlich herunterladbar
wp-config.php	Datenbankzugang, Salts, Konstanten	Ohne sie startet die Website nicht; enthält Zugangsdaten
.htaccess bzw. Server-Konfiguration	Weiterleitungen, Permalinks, Schutzregeln	Wird bei Neuinstallation nicht mitgeliefert

Die Core-Dateien in wp-admin und wp-includes lassen sich laut Dokumentation jederzeit aus einem frischen Download ersetzen. Sie in jedes Backup aufzunehmen, schadet nicht, ist aber nicht zwingend. Der Ordner wp-content ist der eigentliche Kern. Prüfen Sie außerdem, ob Plugins Daten außerhalb von wp-content oder in einer zweiten Datenbank ablegen, etwa Shop-Erweiterungen mit eigenen Tabellen oder Formulare mit Datei-Uploads.

Welche Tabellen und wie viel Platz die Datenbank belegt, zeigt WP-CLI:

wp db size --human-readable
wp db size --tables --size_format=kb

Verifizieren: Sie haben eine Liste aller zu sichernden Bestandteile mit ungefährer Größe, und niemand im Team geht mehr davon aus, dass „die Dateien“ die Datenbank enthalten.

Schritt 2: Häufigkeit und zulässigen Datenverlust bestimmen

Die Frage ist nicht „wie oft ist üblich“, sondern „wie viele Stunden Arbeit oder Bestellungen dürfen im schlimmsten Fall verloren gehen“. Diese Zeitspanne ist der maximal tolerierbare Datenverlust. Das WordPress-Handbuch nennt als Orientierung wöchentliche Backups für kleinere Websites mit wenigen Beiträgen und tägliche für Websites mit hoher Aktivität. Außerdem soll die Datenbank vor jedem Upgrade gesichert werden.

Website-Typ	Änderungen	Datenbank	Dateien
Visitenkarte, Firmenseite	selten, einige Male im Monat	wöchentlich und vor Updates	wöchentlich
Blog, Nachrichten, Stellenangebote	mehrmals pro Woche	täglich	täglich oder wöchentlich
Shop, Buchungen, Mitgliederbereich	laufend durch Kunden	täglich oder häufiger	täglich

Die Datenbank ist meist klein und ändert sich oft, Uploads sind groß und ändern sich seltener. Deshalb lohnt es sich, beide getrennt zu planen. Bei Shops mit laufenden Bestellungen reicht ein nächtliches Backup oft nicht: Eine Wiederherstellung am Nachmittag würde alle Bestellungen seit der Nacht verwerfen. Klären Sie in diesem Fall mit dem Hoster, ob er häufigere Datenbanksicherungen anbietet.

Planen Sie Backups in verkehrsarme Zeiten. Große Sicherungen belasten den Server, auf kleinen Hosting-Paketen können sie Zeitlimits überschreiten.

Verifizieren: Für Datenbank und Dateien steht je ein Intervall fest, und Sie können den maximal möglichen Datenverlust in Stunden benennen.

Schritt 3: Speicherorte und Aufbewahrung festlegen

Das WordPress-Handbuch empfiehlt, mindestens drei bis fünf aktuelle Backups aufzubewahren und die Kopien an verschiedenen Orten abzulegen, damit ein einzelner Ausfall nicht alle Sicherungen trifft. Für Unternehmen bewährt sich die 3-2-1-Regel: drei Kopien der Daten, auf zwei verschiedenen Speichern, davon eine außer Haus. Die Anleitung Immutable Backups gegen Ransomware nach 3-2-1-1-0 erklärt die erweiterte Regel mit unveränderlichen Kopien.

Für die Aufbewahrung hat sich ein gestaffeltes Schema bewährt, zum Beispiel sieben tägliche, vier wöchentliche und drei monatliche Stände. So erkennen Sie auch Probleme, die erst nach Wochen auffallen, etwa eine unbemerkte Schadcode-Infektion oder versehentlich gelöschte Seiten. Rechnen Sie die Speichermenge grob durch: Anzahl der Stände mal Größe von Datenbank und Dateien.

Zwei Regeln sind nicht verhandelbar:

• Nicht nur auf dem Webserver: Wird der Server kompromittiert oder fällt der Speicher aus, sind dortige Backups mit betroffen.
• Nie im öffentlichen Webverzeichnis: Im Labor war ein Datenbank-Export unter wp-content/db-test.sql ohne Anmeldung per HTTP abrufbar, der Server antwortete mit Status 200. Ein solcher Export enthält Benutzerkonten mit Passwort-Hashes, E-Mail-Adressen und Kundendaten.

Schützen Sie externe Backups zusätzlich durch Verschlüsselung und durch getrennte Zugangsdaten, damit ein Angreifer mit Zugriff auf die Website nicht auch die Backups löschen kann. Die Anleitung KeyHelp-Backups mit externer Sicherung und Rotation zeigt das am Beispiel eines eigenen Servers.

Verifizieren: Mindestens eine Kopie liegt außerhalb des Webservers, der Speicherort ist nicht öffentlich erreichbar, und die Aufbewahrungsdauer je Stufe ist festgelegt.

Schritt 4: Sicherung umsetzen und protokollieren

Für die Umsetzung gibt es drei Wege, die sich kombinieren lassen: das Backup des Hosters, ein Backup-Plugin mit externem Ziel oder ein Skript per WP-CLI und Cronjob auf dem eigenen Server. Wichtig ist, dass Sie für jeden Weg wissen, was er enthält. Hoster-Backups sind oft nur eine bestimmte Anzahl Tage verfügbar und liegen im selben Rechenzentrum. Lesen Sie die Leistungsbeschreibung Ihres Tarifs.

Mit WP-CLI erzeugen Sie einen Datenbank-Export und ein Archiv der Dateien. Legen Sie beides außerhalb des Webverzeichnisses ab, hier im Beispiel unter ~/backups:

mkdir -p ~/backups
wp db export ~/backups/db-$(date +%F).sql --add-drop-table
tar -czf ~/backups/files-$(date +%F).tar.gz --exclude=wp-content/cache wp-content wp-config.php .htaccess

Im Labor meldete der Export „Success: Exported to …“, die Datei enthielt alle zwölf Tabellen der Standardinstallation. Die Option --add-drop-table sorgt dafür, dass beim Einspielen vorhandene Tabellen ersetzt werden. Übertragen Sie beide Dateien anschließend auf den externen Speicher und löschen Sie alte Stände nach Ihrem Aufbewahrungsschema. Wie Sie das zeitgesteuert ausführen, beschreibt die Anleitung WordPress Cron Job mit echtem System-Cron einrichten.

Protokollieren Sie jede Sicherung mit Datum, Größe und Ergebnis. Ein Backup, dessen Größe plötzlich stark schrumpft, deutet auf einen Fehler hin. Richten Sie eine Benachrichtigung ein, wenn eine Sicherung ausbleibt.

An dieser Stelle zeigt sich, dass eine Backup-Strategie kein einmaliges Projekt ist: Sicherungen müssen laufen, kontrolliert und aufgeräumt werden, Woche für Woche. Wer das nicht selbst im Kalender halten möchte, kann es 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.

Verifizieren: Auf dem externen Speicher liegen Datenbank-Export und Datei-Archiv mit aktuellem Datum, und das Archiv lässt sich mit tar -tzf DATEI > /dev/null ohne Fehlermeldung lesen.

Schritt 5: Wiederherstellung testen

Das WordPress-Handbuch empfiehlt, automatische Backups gelegentlich durch eine manuelle Sicherung zu ergänzen, um sicherzugehen, dass der Prozess funktioniert. Noch aussagekräftiger ist eine echte Wiederherstellung. Spielen Sie dafür niemals ein Backup testweise auf die Produktivseite ein, sondern nutzen Sie eine Testinstanz. Wie Sie eine einrichten, zeigt die Anleitung Staging-Umgebung für WordPress einrichten.

Auf der Testinstanz entpacken Sie das Datei-Archiv, passen die Datenbankzugangsdaten in der wp-config.php an und spielen den Export ein:

wp db import db-2026-09-30.sql

Im Labor stellte wp db import einen zuvor gelöschten Beitrag vollständig wieder her. Läuft die Testinstanz unter einer anderen Adresse, passen Sie die URLs mit wp search-replace an und nicht per SQL, weil WordPress viele Einstellungen serialisiert speichert und ein einfaches Ersetzen diese Daten beschädigt.

Messen Sie die Zeit vom Start bis zur funktionierenden Seite. Diese Dauer ist Ihre realistische Wiederherstellungszeit. Liegt sie über dem, was Ihr Geschäft verträgt, brauchen Sie schnellere Wege, etwa Snapshots beim Hoster.

Verifizieren: Die Testinstanz zeigt Startseite, einen aktuellen Beitrag und ein Bild aus der Mediathek, die Anmeldung im Backend funktioniert, und die gemessene Wiederherstellungszeit ist notiert.

Schritt 6: Backup-Plan dokumentieren

Halten Sie die Ergebnisse auf einer Seite fest und legen Sie diese dort ab, wo Sie im Notfall ohne die Website darauf zugreifen können. Der Plan enthält:

• gesicherte Bestandteile und Ausnahmen
• Intervalle für Datenbank und Dateien sowie Sicherung vor Updates
• Speicherorte mit Zugangsweg, Verschlüsselung und Aufbewahrungsschema
• Verantwortliche Person und Vertretung
• Termin und Ergebnis des letzten Wiederherstellungstests
• Löschfristen, falls Backups personenbezogene Daten enthalten

Der letzte Punkt ist für den DACH-Raum relevant: Backups enthalten Kunden- und Kontaktdaten und unterliegen damit der DSGVO. Wie Löschpflichten und Aufbewahrung zusammenpassen, behandelt die Anleitung DSGVO-Löschpflichten und Backups.

Verifizieren: Der Plan existiert außerhalb der Website, und eine zweite Person könnte anhand dieses Dokuments eine Wiederherstellung anstoßen.

Typische Fehler

• Nur Dateien gesichert: Ein FTP-Download des WordPress-Ordners enthält keine Beiträge und Einstellungen. Die Datenbank muss separat exportiert werden.
• Backup im Webverzeichnis: Exporte unter wp-content sind oft öffentlich abrufbar, im Labor mit Status 200. Legen Sie Exporte außerhalb des Document Root ab.
• Nur ein Stand: Überschreibt jede Sicherung die vorige, ist eine Infektion oder ein Bedienfehler nach der nächsten Sicherung dauerhaft enthalten.
• Nie getestet: Abgebrochene Archive, fehlende Tabellen oder vergessene Zugangsdaten fallen erst im Ernstfall auf.
• Import in die falsche Datenbank: wp db import nutzt die Zugangsdaten der wp-config.php im aktuellen Verzeichnis. Prüfen Sie vor dem Import mit wp option get siteurl, auf welcher Instanz Sie arbeiten.

Häufige Fragen

Reicht das Backup meines Hosters?

Als eine von mehreren Kopien ja. Als einzige Sicherung nein, weil sie meist im selben Rechenzentrum liegt, nur wenige Tage zurückreicht und Sie keinen Einfluss auf Umfang und Aufbewahrung haben.

Muss ich die WordPress-Core-Dateien mitsichern?

Nicht zwingend, weil sie sich aus dem offiziellen Download ersetzen lassen. Notieren Sie dann aber die WordPress-Version, damit Sie genau diese wiederherstellen.

Wie groß wird das Backup?

Das hängt vor allem von der Mediathek ab. Die Datenbank der Testinstanz war unter einem Megabyte groß, das Datei-Archiv lag durch mitgelieferte Themes und Sprachdateien bei rund 14 MB. Die Werte Ihrer eigenen Website liefert wp db size, den Platzbedarf der Dateien zeigt der Dateimanager Ihres Hosters für den Ordner wp-content.

Wie oft sollte ich die Wiederherstellung testen?

Mindestens nach jeder Änderung am Backup-Verfahren und in einem festen Rhythmus, etwa quartalsweise. Tragen Sie den Termin in den Backup-Plan ein.

Testumfang

Wir haben die Sicherung unter WordPress 7.1.2 im Labor durchgespielt und einen gelöschten Beitrag mit wp db import erfolgreich zurückgeholt. Auffällig war, dass ein Datenbankexport im Webverzeichnis für jeden öffentlich abrufbar war. Hoster-Backups und Backup-Plugins haben wir nicht geprüft, testen Sie diese Wege daher zuerst auf einer Kopie Ihrer Website.

Fazit

Eine gute WordPress-Backup-Strategie beantwortet fünf Fragen schriftlich: was, wie oft, wohin, wie lange und wie zurück. Datenbank und Dateien gehören zusammen, mehrere Stände an getrennten Orten schützen vor Einzelausfällen, und erst ein erfolgreicher Wiederherstellungstest macht aus Dateien ein Backup. Wer den laufenden Betrieb von Sicherung und Updates abgeben möchte, findet dafür die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Staging-Umgebung für WordPress einrichten
• Immutable Backups gegen Ransomware: 3-2-1-1-0 mit restic
• DSGVO-Löschpflichten und Backups
• WordPress Cron Job mit echtem System-Cron einrichten
• WordPress Advanced Administration: WordPress Backups
• WordPress Advanced Administration: Backing Up Your WordPress Files
• WordPress Advanced Administration: Backing Up Your Database
• WP-CLI: wp db export