WordPress-Backups, die sich wirklich wiederherstellen lassen

Das übliche WordPress-Backup lässt Sie genau dann im Stich, wenn Sie es brauchen. Ein Plugin legt eine ZIP-Datei in wp-content ab, im selben Hosting-Konto wie die Website. Übernimmt ein Angreifer die Seite, verschlüsselt Ransomware den Server oder sperrt der Hoster das Konto, ist diese Kopie ebenfalls weg.

Ein Backup ist nur so viel wert wie die Wiederherstellung, die damit gelingt. Dieser Leitfaden zeigt, was hineingehört, wo die Kopien liegen sollten und wie oft Sie sichern. Außerdem geht es darum, wie Sie eine Wiederherstellung testen und nach einem Hack einen sauberen Wiederherstellungspunkt finden.

Was ein WordPress-Backup enthalten muss: Dateien und Datenbank

Eine WordPress-Website besteht aus zwei Hälften, und Sie brauchen beide. In der Datenbank liegen Beiträge, Seiten, Benutzer samt Passwort-Hashes, Einstellungen, WooCommerce-Bestellungen und Formulareinträge. Nehmen Sie ein Kontaktformular-Plugin, das Einträge in der Datenbank speichert. Ein reines Datei-Backup verliert jede Anfrage. Ein reines Datenbank-Backup bringt die Einträge zurück, aber kein Plugin, das sie lesen kann.

Bei den Dateien brauchen Sie wp-content (Uploads, Plugins, Themes), wp-config.php und .htaccess bzw. Ihre Serverkonfiguration. Den WordPress-Core können Sie jederzeit neu herunterladen, allerdings nur, wenn Sie wissen, welche Version lief.

Im WordPress-Hauptverzeichnis mit WP-CLI:

# Datenbank-Export, außerhalb des Web-Roots abgelegt
mkdir -p ~/backups
wp db export ~/backups/db-$(date +%F).sql

# Dateien: wp-content, wp-config.php und .htaccess (ohne Caches und alte Backup-Ordner)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/backups' \
    -czf ~/backups/files-$(date +%F).tar.gz \
    wp-content wp-config.php .htaccess

# Versionen festhalten, damit Core, Plugins und Themes aus offiziellen Quellen neu installiert werden können
wp core version > ~/backups/versions-$(date +%F).txt
wp plugin list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt
wp theme list --fields=name,version,status >> ~/backups/versions-$(date +%F).txt

Ersetzen Sie wp-content/backups durch den Ordner, den Ihr Backup-Plugin verwendet, denn Backups innerhalb von Backups blähen jedes Archiv weiter auf. Unter nginx gibt es keine .htaccess. Streichen Sie sie dann aus dem Befehl und sichern Sie stattdessen Ihre Serverkonfiguration. Die WP-CLI-Befehle für die Datenbank sind auf WordPress.org dokumentiert.

Die 3-2-1-Regel – und warum ein Backup im Hosting-Konto nicht zählt

Die Regel lautet: drei Kopien Ihrer Daten, auf zwei verschiedenen Speicherarten, eine davon extern. Die Live-Website ist die erste Kopie. Ein Backup im selben Hosting-Konto ist die zweite, hat aber denselben Login, denselben Server und denselben Anbieter wie die Website.

Wer auf Ihre Website schreiben kann, kann diese Kopie meist auch löschen. Ransomware, die den Web-Root verschlüsselt, erwischt auch die ZIP-Datei daneben. Eine Kontosperrung oder ein Ausfall beim Hoster trifft beides gleichzeitig. Snapshots des Hosters sind nützlich und schnell zurückgespielt, bleiben aber eine einzelne Kopie, über die Sie keine Kontrolle haben.

Entscheidend ist die dritte Kopie. Sie gehört zu einem anderen Anbieter, mit eigenen Zugangsdaten, die nicht in löschfähiger Form auf dem Webserver liegen. Zwei Einstellungen machen dabei einen großen Unterschied:

• Versionierung oder Unveränderbarkeit. Viele Object-Storage-Dienste bieten Versionierung, Object Lock oder eine anbieterseitige Aufbewahrungssperre. Versionierung hebt ältere Stände auf, doch wer Löschrechte hat, kann sie trotzdem entfernen. Eine Sperre im strengsten Modus (Compliance-Modus) hindert dagegen alle daran, ein Backup vor Ablauf der Frist zu löschen oder zu überschreiben, auch Sie selbst.
• Reine Schreibrechte für den Backup-Job. Kann der Schlüssel auf dem Server nur hochladen und schützen Versionierung oder Sperre die älteren Stände, kann ein Angreifer, der ihn stiehlt, Ihre Historie weder löschen noch überschreiben.

Wie oft sichern und wie lange aufbewahren

Richten Sie die Häufigkeit danach aus, wie schnell sich Ihre Daten ändern. Für eine Visitenkarten-Website, die einmal im Monat bearbeitet wird, reicht ein wöchentliches Backup. Ein Shop, der täglich Bestellungen annimmt, braucht mindestens tägliche Datenbank-Backups, oft auch häufigere. Die Dateien ändern sich meist seltener als die Datenbank und können deshalb nach einem eigenen Zeitplan laufen.

Bei der Aufbewahrungsdauer müssen Sie abwägen. Kompromittierungen fallen oft erst Wochen nach ihrem Beginn auf. Wer nur sieben Tage vorhält, hat womöglich in jeder Kopie schon die Hintertür. Umgekehrt halten alte Backups personenbezogene Daten am Leben, auch Konten, deren Löschung Nutzer verlangt haben.

Legen Sie eine feste Aufbewahrungsfrist und eine Rotation fest, etwa tägliche Kopien für einige Wochen plus monatliche Kopien für einen begrenzten Zeitraum. Halten Sie diese Frist schriftlich fest. Das hilft auch bei Löschanfragen: Die Daten verschwinden aus den Backups, sobald die Kopien ablaufen, und bis dahin stellen Sie sicher, dass sie weder wiederhergestellt noch genutzt werden. Archive für jede einzelne Anfrage umzuschreiben ist selten praktikabel. Prüfen Sie, was Ihre Aufsichtsbehörde zu Backups sagt.

Backups sind personenbezogene Daten: Verschlüsselung, Zugriff und Verträge

Ein WordPress-Backup enthält Benutzerkonten, Passwort-Hashes, Kunden- und Bestelldaten sowie Formulareinträge. Geht es verloren, wiegt das genauso schwer wie der Verlust der Live-Datenbank.

• Verschlüsseln Sie bei der Übertragung und im Ruhezustand. Verschlüsselung ist eine der Maßnahmen, die Art. 32 Abs. 1 lit. a DSGVO ausdrücklich nennt. Bewahren Sie den Schlüssel nicht auf dem Speicher auf, den er schützt.
• Beschränken Sie den Zugriff. Backups herunterladen sollten nur die Personen können, die Websites wiederherstellen. Entfernen Sie alte geteilte Download-Links und abgelaufene Benutzerkonten auf dem Speicher.
• Schließen Sie Verträge. Ein Anbieter für Backup-Speicher oder eine Agentur, die Kopien vorhält, ist Auftragsverarbeiter nach Art. 28 und braucht einen Auftragsverarbeitungsvertrag (AVV).

Ein unverschlüsseltes Backup, das verloren geht oder öffentlich erreichbar ist, kann selbst eine Datenpanne sein. Für diesen Fall lesen Sie unseren Leitfaden zur 72-Stunden-Meldung.

Wiederherstellung testen, bevor Sie sie brauchen

Stellen Sie auf einer Staging-Umgebung oder einer lokalen Kopie wieder her, niemals über die Live-Website. Nehmen Sie dafür die externe Kopie, nicht die bequeme lokale, denn nach einem echten Vorfall haben Sie nur noch die externe.

# In einem leeren Web-Root auf Staging; WP_VERSION stammt aus Ihrer Versionsdatei
wp core download --version="$WP_VERSION" --skip-content
tar -xzf files-2026-10-23.tar.gz
# wp-config.php anpassen: Zugangsdaten der Staging-Datenbank, dann:
wp db import db-2026-10-23.sql
wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid
wp option update blog_public 0

blog_public 0 bittet Suchmaschinen lediglich, fernzubleiben. Schützen Sie Staging zusätzlich mit HTTP-Authentifizierung. Verhindern Sie, dass die Kopie echte Kunden anschreibt oder Payment-Webhooks auslöst, und setzen Sie während des Tests am besten define( 'DISABLE_WP_CRON', true );.

Prüfen Sie anschließend:

• Der Admin-Login funktioniert
• Ein Formular lässt sich absenden
• Die jüngste Bestellung bzw. der jüngste Beitrag ist vorhanden
• Bilder und Downloads laden
• Plugin-Liste und Versionen stimmen mit Ihrer Aufzeichnung überein
• Die Gesamtdauer vom Start bis zur funktionierenden Website ist notiert

Diese Dauer ist Ihre tatsächliche Wiederherstellungszeit, und sie ist oft länger als gedacht. Dokumentieren Sie Datum, verwendetes Backup, Ergebnis und aufgetretene Probleme. Ein Backup, das nie zurückgespielt wurde, beweist nichts: weder Ihnen selbst noch jemandem, der wissen will, wie Sie Art. 32 Abs. 1 lit. c und d oder die Rechenschaftspflicht nach Art. 5 Abs. 2 erfüllen.

Wiederherstellen nach einem Hack: den letzten sauberen Stand finden

Spielen Sie nicht blind das neueste Backup ein. Es enthält sehr wahrscheinlich die Hintertür. Das älteste Backup ist vielleicht sauber, dafür fehlen Wochen an Bestellungen. Sichern Sie, bevor Sie irgendetwas ändern, eine Kopie des infizierten Zustands, damit Sie den Vorfall später untersuchen können.

Schätzen Sie dann ein, wann die Kompromittierung begann. Werten Sie Server- und Zugriffslogs aus, achten Sie auf Änderungsdaten von Dateien, unbekannte Admin-Konten und Dateien, die von einem älteren Backup abweichen. Wählen Sie dann ein Backup von davor. Eine Integritäts-Baseline der Dateien hilft dabei. Das Plugin Security Audit & Compliance legt eine solche Baseline an und meldet geänderte Dateien sowie Kompromittierungsindikatoren. So lässt sich eingrenzen, wann sich etwas verändert hat. Backups erstellt oder wiederherstellt es nicht.

Sauberer als eine Komplettwiederherstellung ist dieses Vorgehen:

1. Core, Plugins und Themes aus offiziellen Quellen in bekannten Versionen neu installieren.
2. Nur Uploads und Datenbank vom sauberen Stand übernehmen. Uploads auf PHP-Dateien prüfen (so finden Sie Web-Shells in Uploads).
3. Die Datenbank auf eingeschleuste Admins (wp user list --role=administrator) und Spam-Inhalte prüfen.
4. Bestellungen und Daten, die seit diesem Stand entstanden sind, nachtragen oder migrieren.

Eine Wiederherstellung schließt die Lücke nicht. Bevor die Website wieder online geht, aktualisieren oder entfernen Sie die verwundbare Komponente und tauschen alle Passwörter, Schlüssel und Salts aus. Sonst kommt der Angreifer auf demselben Weg wieder herein. Das vollständige Vorgehen beschreibt unser Plan zur Malware-Entfernung. Mit dem Abgleich der Core-Prüfsummen stellen Sie sicher, dass der Core sauber ist.

Was DSGVO und NIS2 von Ihren Backups erwarten

Die DSGVO verlangt in Art. 5 Abs. 1 lit. f eine angemessene Sicherheit, einschließlich Integrität und Vertraulichkeit. Art. 32 Abs. 1 lit. c fordert die Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen nach einem Zwischenfall rasch wiederherzustellen, lit. d die regelmäßige Überprüfung Ihrer Maßnahmen. Gehen Kundendaten verloren und lassen sich nicht wiederherstellen, kann das eine Verletzung der Verfügbarkeit sein.

Für wichtige und besonders wichtige Einrichtungen, die unter das nationale Umsetzungsgesetz fallen, nennt NIS2 in Art. 21 Abs. 2 lit. c die Aufrechterhaltung des Betriebs, darunter Backup-Management und Wiederherstellung nach einem Notfall. Auch wenn NIS2 für Sie selbst nicht gilt, können Ihre NIS2-pflichtigen Kunden Sie als Zulieferer oder Agentur um Nachweise bitten. Das Gesamtbild liefert unsere Übersicht zu Art. 32 DSGVO.

Führen Sie eine einseitige Backup-Dokumentation: was gesichert wird, wo, wie oft, mit welcher Aufbewahrungsfrist und welcher Verschlüsselung, wer Zugriff hat sowie Datum und Ergebnis des letzten Restore-Tests. Ihr nächster Schritt: Planen Sie den ersten Restore-Test noch diese Woche ein, und zwar mit der externen Kopie.

FAQ

Reicht das tägliche Backup meines Hosters?

Für sich allein meist nicht. Es ist eine einzelne Kopie beim selben Anbieter und wird oft nur kurz aufbewahrt. Klären Sie, wie lange es vorgehalten wird, und ergänzen Sie eine externe Kopie unter Ihrer eigenen Kontrolle.

Muss ich den WordPress-Core mitsichern?

Nicht unbedingt, wenn Sie die Versionen von Core, Plugins und Themes festhalten. Eine Neuinstallation von WordPress.org liefert Ihnen außerdem nachweislich saubere Core-Dateien.

Wie gehe ich mit einer Löschanfrage um, wenn die Daten auch in Backups stecken?

Löschen Sie die Daten auf der Live-Website und stützen Sie sich bei den Backups auf Ihre dokumentierte Aufbewahrungsfrist. Falls Sie je wiederherstellen, sorgen Sie dafür, dass die Daten dieser Person nicht zurück in die Live-Website gelangen.

Wie oft sollte ich eine Wiederherstellung testen?

Regelmäßig, und immer nach größeren Änderungen am Hosting, an der Website oder am Backup-Tool. Wählen Sie ein Intervall, das Sie tatsächlich einhalten, und dokumentieren Sie jeden Test.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.