WordPress-Backups sind für Website-Betreiber beruhigend. Wenn ein Plugin-Update scheitert, ein Theme kaputtgeht, ein Angriff Dateien verändert oder ein Serverproblem auftritt, soll ein Backup die Website zurückholen. Genau deshalb gehören Backups zu den wichtigsten Sicherheitsmaßnahmen. Datenschutzrechtlich sind sie aber nicht nur Rettungsanker, sondern eigene Datenbestände.
In einem WordPress-Backup stecken oft mehr personenbezogene Daten, als Betreiber im Alltag vermuten: Datenbanktabellen, Nutzerkonten, Formularanfragen, Kommentare, Shopbestellungen, IP-Adressen, Logdaten, Newsletter-IDs, Medienuploads, Bewerbungsunterlagen oder alte Pluginreste. Wer Backups plant, muss daher nicht nur fragen, ob sie funktionieren. Wichtig ist auch, wie sie geschützt, gespeichert, gelöscht und getestet werden.
Verfügbarkeit ist Datenschutz
Die DSGVO denkt Sicherheit nicht nur als Vertraulichkeit. Art. 32 nennt auch Verfügbarkeit, Belastbarkeit und die Fähigkeit, personenbezogene Daten nach einem physischen oder technischen Zwischenfall wiederherzustellen. Für Website-Betreiber ist das ein klarer Hinweis: Backups sind Teil technischer und organisatorischer Maßnahmen. Eine Website mit Kundendaten, Formularen oder Mitgliederbereich braucht ein Wiederherstellungskonzept.
Das BSI betont in seinen Verbraucher- und Sicherheitsempfehlungen ebenfalls die Bedeutung regelmäßiger Datensicherung. Für Unternehmen ist der Gedanke noch praktischer: Ein Backup, das nie getestet wurde, ist nur eine Hoffnung. Entscheidend ist, ob die Website in einem realistischen Zeitfenster wieder online gehen kann und ob dabei keine Daten unnötig offengelegt werden.
Was ein WordPress-Backup enthalten kann
Viele Backup-Plugins sichern pauschal alles: Datenbank, Uploads, Plugins, Themes und Konfigurationsdateien. Das ist technisch bequem, erzeugt aber große Datenpakete. In der Datenbank liegen Beiträge, Benutzer, Kommentare, Pluginoptionen, Formularinhalte, Bestellungen, Sessiondaten und manchmal API-Tokens oder alte Protokolle. Im Upload-Ordner können PDFs, Rechnungen, Bewerbungen oder importierte Kundendateien liegen.
Deshalb sollte jedes Backup-Konzept mit einer Inhaltsprüfung beginnen. Welche Daten sind wirklich erforderlich, um die Website wiederherzustellen? Welche Ordner dürfen nicht in die Sicherung? Gibt es Uploadbereiche mit besonders sensiblen Dateien? Werden Staging-Kopien oder alte Migrationen versehentlich mitgesichert? Je genauer der Umfang, desto kleiner das Risiko.
Verschlüsselung und Zugriff trennen
Backups sind attraktive Ziele. Wer ein vollständiges WordPress-Backup erhält, kann oft Datenbankinhalte, Nutzerlisten und Konfigurationen auslesen. Deshalb sollten Backups verschlüsselt gespeichert werden, besonders wenn sie in Cloud-Speichern, externen Systemen oder auf transportablen Datenträgern landen. Das BSI weist bei Datensicherungen ebenfalls auf Schutz und Verschlüsselung sensibler Daten hin.
Wichtig ist auch die Zugriffstrennung. Nicht jede Person mit WordPress-Adminrechten sollte automatisch alle Backups herunterladen können. Nicht jeder Dienstleister braucht Zugriff auf produktive Kundendaten. Und ein Backup-Speicher sollte nicht mit denselben Zugangsdaten erreichbar sein wie die Website selbst. Sonst kann ein kompromittierter Adminzugang auch die Sicherungen gefährden.
Löschfristen gelten auch für Sicherungen
Viele Backups werden nach dem Motto „viel hilft viel“ aufbewahrt. Täglich, wöchentlich, monatlich, unbegrenzt. Datenschutzrechtlich ist das heikel, wenn personenbezogene Daten länger gespeichert werden als nötig. Gleichzeitig dürfen Backups nicht so kurz gehalten werden, dass ein Angriff oder schleichender Fehler nicht mehr rückgängig gemacht werden kann.
Die Lösung ist ein begründetes Aufbewahrungskonzept. Zum Beispiel tägliche Sicherungen für eine kurze Zeit, wöchentliche Sicherungen für einen mittleren Zeitraum und wenige Monatsstände für besondere Fälle. Die konkrete Dauer hängt von Website, Risiko, gesetzlichen Pflichten und Wiederherstellungsbedarf ab. Wichtig ist, dass die Entscheidung dokumentiert ist und technisch tatsächlich umgesetzt wird.
Restore-Tests sind keine Kür
Ein Backup ist erst dann belastbar, wenn eine Wiederherstellung getestet wurde. Bei WordPress heißt das: Datenbank einspielen, Dateien wiederherstellen, Permalinks prüfen, Login testen, Formulare testen, Shop- oder Mitgliederbereich prüfen, E-Mail-Versand kontrollieren und sicherstellen, dass keine alten Staging-URLs oder Debug-Einstellungen live gehen.
Restore-Tests sollten nicht auf der produktiven Website stattfinden. Besser ist eine isolierte Testumgebung. Dort kann geprüft werden, ob die Sicherung vollständig ist und wie lange die Wiederherstellung dauert. Gleichzeitig lässt sich dokumentieren, welche Person den Test durchgeführt hat, welche Version genutzt wurde und welche Probleme aufgetreten sind.
Backups und Betroffenenrechte
Backups berühren auch Lösch- und Auskunftsprozesse. Wenn personenbezogene Daten im Produktivsystem gelöscht werden, können sie technisch noch in Sicherungen vorhanden sein. Das ist nicht automatisch unzulässig, muss aber beherrscht werden. Betreiber sollten wissen, wann Sicherungen rotieren, ob einzelne Daten gezielt aus Backups entfernt werden können und was bei einer Wiederherstellung passiert.
Besonders kritisch ist der Restore alter Datenstände. Wenn ein Backup zurückgespielt wird, können bereits gelöschte Nutzerkonten, Formularanfragen oder Kommentare wieder auftauchen. Deshalb gehört zum Restore-Prozess eine Nachprüfung: Welche Datenschutzaktionen seit dem Backup müssen erneut angewendet werden? Welche Logdaten oder Formulare dürfen nicht wieder produktiv werden?
Plugin-Auswahl und Speicherorte prüfen
Backup-Plugins sind tief in WordPress integriert. Sie lesen Datenbanken, schreiben Archive, übertragen Dateien und verbinden sich mit Cloud-Speichern. Betreiber sollten daher nicht nur auf Funktionsumfang achten, sondern auch auf Wartung, Sicherheitsgeschichte, Speicherorte, Verschlüsselung, Rollenrechte und Dokumentation. Ein veraltetes Backup-Plugin kann selbst zum Risiko werden.
Wenn externe Speicher genutzt werden, stellt sich zusätzlich die Frage nach Auftragsverarbeitung und Drittlandtransfer. Wer Backups in einen Cloud-Dienst überträgt, verlagert nicht nur technische Dateien, sondern möglicherweise personenbezogene Daten. Das muss zur Datenschutzerklärung, zum AV-Verzeichnis und zu internen Sicherheitsmaßnahmen passen.
Prüfliste für Website-Betreiber
Eine praxistaugliche Prüfung beginnt mit fünf Fragen: Welche Daten werden gesichert? Wo werden Backups gespeichert? Wer hat Zugriff? Wie lange werden Sicherungen aufbewahrt? Wann wurde zuletzt erfolgreich wiederhergestellt? Wenn eine dieser Fragen nicht beantwortet werden kann, ist das Backup-Konzept noch nicht fertig.
Danach folgen die Details: Verschlüsselung aktivieren, getrennte Zugangsdaten verwenden, Backup-Speicher vor Löschung durch Angreifer schützen, Benachrichtigungen überwachen, Test-Restores planen, Staging-Umgebungen absichern und den Umgang mit gelöschten Daten dokumentieren. Auch Server-Logfiles sollten einbezogen werden; der Beitrag zu Server-Logfiles und Datenschutz zeigt, warum technische Daten schnell personenbezogen werden können.
Staging-Kopien nicht vergessen
Restore-Tests erzeugen häufig Staging- oder Testkopien. Diese Kopien sind praktisch, aber datenschutzrelevant. Wenn eine komplette WordPress-Datenbank in eine Testumgebung eingespielt wird, landen dort oft echte Nutzer-, Formular- oder Shopdaten. Die Testumgebung muss deshalb mindestens so gut geschützt sein wie die Produktivseite. Besser ist es, personenbezogene Daten zu reduzieren oder zu anonymisieren, sofern das für den Test möglich ist.
Auch die Lebensdauer solcher Kopien sollte begrenzt sein. Eine temporäre Restore-Umgebung, die nach dem Test vergessen wird, kann Monate später ein größeres Risiko darstellen als das ursprüngliche Backup. Deshalb gehört zum Restore-Test ein Cleanup-Schritt: Testumgebung löschen, Zugangsdaten entfernen, temporäre Dateien bereinigen und Ergebnis dokumentieren.
Notfallrollen vorher klären
Im Ernstfall ist selten Zeit für Grundsatzdiskussionen. Wer entscheidet, dass ein Backup zurückgespielt wird? Wer informiert Hoster, Agentur oder Datenschutzverantwortliche? Wer prüft, ob nach dem Restore Bestellungen, Formularanfragen oder Löschungen erneut berücksichtigt werden müssen? Diese Rollen sollten vor dem Vorfall feststehen.
Für kleine Teams reicht eine einfache Notfallkarte: primäre Kontaktperson, technischer Ersatzkontakt, Speicherort der Backup-Dokumentation, Zugang zum Hoster, erwartete Wiederherstellungszeit und Prüfliste nach dem Restore. Das klingt unspektakulär, spart aber im Vorfall wertvolle Zeit und verhindert Datenschutzfehler unter Druck.
Zusätzlich sollte jede Änderung am Backup-Konzept nachvollziehbar sein. Neue Plugins, ein anderer Cloud-Speicher oder geänderte Aufbewahrungszeiten können die Datenschutzbewertung verändern. Ein kurzes Änderungsprotokoll hilft, später zu verstehen, warum ein Backup so eingerichtet wurde und wann die nächste praktische Prüfung nötig ist.
Fazit: Ein gutes Backup ist ein geprüfter Prozess
WordPress-Backups sind unverzichtbar, aber sie sind kein reines Technikthema. Sie enthalten personenbezogene Daten, brauchen Schutz, klare Löschfristen und regelmäßige Restore-Tests. Wer nur ein Plugin installiert und auf grüne Häkchen vertraut, übersieht die wichtigsten Fragen.
Der nächste sinnvolle Schritt ist ein kurzer Backup-Test: Sicherung auswählen, in einer geschützten Umgebung wiederherstellen, Ergebnis dokumentieren und prüfen, ob personenbezogene Daten angemessen geschützt sind. Danach wissen Betreiber nicht nur, dass ein Backup existiert, sondern ob es im Ernstfall wirklich trägt.
