Backup, das wirklich funktioniert: so testet man die Wiederherstellung einer WordPress-Seite

Sie haben ein Backup-Plugin installiert, die automatischen Backups laufen täglich und die Dateien landen irgendwo in der Cloud. Das fühlt sich sicher an. Aber hier ist die unbequeme Wahrheit: Ein Backup, das nie wiederhergestellt wurde, hat keinen nachgewiesenen Wert. Sie wissen nicht, ob die Daten vollständig sind, ob das Plugin bei der Wiederherstellung Fehler macht oder ob Ihre Datenbank tatsächlich dabei ist.

Genau das ist die Lücke, die fast alle WordPress-Betreiber haben. Die Backups laufen, aber der Restore-Test fehlt. In diesem Artikel zeige ich Ihnen, wie ich das bei Kundenprojekten angehe, was beim Test konkret geprüft wird und wie Sie im Ernstfall innerhalb von 30 Minuten wieder online gehen - vorausgesetzt, Sie haben einmal in Ruhe geübt.

Warum der Restore-Test der wichtigste Teil Ihrer Backup-Strategie ist

In meinen 13 Jahren als WordPress-Entwickler habe ich mehrfach erlebt, wie ein scheinbar laufendes Backup im Ernstfall versagte. Einmal bei einem Onlineshop-Kunden: Das Plugin hatte die Datenbank konsequent weggelassen, weil die Datenbankgröße das Limit der kostenlosen Plugin-Version überschritt. Die Fehlermeldung wurde nie gesehen, weil niemand die Backup-Logs prüfte. Ergebnis: sechs Monate Bestelldaten weg nach einem Serverausfall.

Laut einer Analyse aus 2024 werden bei 57 % der erfolgreichen Ransomware-Angriffe auf Unternehmensserver auch die Backups kompromittiert. Das ist kein Extremszenario mehr. Für KMU mit einer WordPress-Seite bedeutet das: Wer nur auf das Hoster-Backup vertraut, das auf derselben Infrastruktur liegt wie die Seite, setzt alles auf eine Karte.

Die 3-2-1-Strategie: Was sie bedeutet und warum die Offsite-Kopie entscheidend ist

Die 3-2-1-Regel ist kein Marketingbegriff, sondern ein Branchenstandard, den auch das BSI für kritische Systeme empfiehlt. Sie bedeutet:

• 3 Kopien der Daten insgesamt
• 2 verschiedene Speichermedien oder -dienste
• 1 Kopie an einem geografisch getrennten Ort

Für eine typische WordPress-Seite sieht das in der Praxis so aus: Das Hoster-Backup zählt als erste Kopie auf Medium eins. Ein Plugin wie UpdraftPlus sichert täglich in einen Cloud-Speicher (Google Drive, Dropbox oder Amazon S3) - das ist Kopie zwei auf Medium zwei. Zusätzlich läuft monatlich ein manueller Download des vollständigen Backups auf eine lokale Festplatte oder in einen zweiten Cloud-Account - das ist Kopie drei, Offsite.

Der springende Punkt: Nur die Offsite-Kopie ist wirklich unabhängig. Mehr zur Cloud-Strategie habe ich im Artikel zu Offsite-Backup für WordPress in der Cloud beschrieben.

Was ein vollständiges Backup tatsächlich enthält

Bevor Sie testen können, müssen Sie wissen, was Sie testen sollen. Ein vollständiges WordPress-Backup besteht aus vier Teilen, und alle vier müssen beim Restore vorhanden sein:

Die MySQL-Datenbank enthält alle Inhalte (Seiten, Beiträge, WooCommerce-Bestellungen), alle Einstellungen und alle Benutzerkonten. Fehlt die Datenbank, haben Sie zwar die Dateien, aber eine leere oder kaputte Installation.

Der Uploads-Ordner (/wp-content/uploads/) speichert alle Bilder, PDFs und hochgeladene Mediendateien. Ohne ihn sehen Ihre Seiten aus wie eine defekte Nachrichtenseite aus den 90ern.

Plugins und Theme aus /wp-content/plugins/ und /wp-content/themes/ bestimmen Funktionalität und Design. Bei aktiven Custom-Themes ist das besonders kritisch, weil das Theme nicht aus dem Repository wiederhergestellt werden kann.

Die Kerndateien (wp-config.php und der Rest von /) werden manchmal weggelassen, weil WordPress selbst neu installiert werden kann. Das stimmt, macht aber den Restore aufwendiger.

Backup auf einer Testumgebung wiederherstellen: Schritt für Schritt

Der einfachste Weg für einen Restore-Test ohne Risiko für die Live-Seite ist LocalWP - ein kostenloses Tool, das ich selbst täglich für die Entwicklung nutze. Es läuft komplett lokal auf Ihrem Rechner und braucht keine externe Domain.

So läuft ein typischer Testdurchlauf ab:

Schritt 1: Backup herunterladen. In UpdraftPlus unter "Einstellungen - UpdraftPlus" wählen Sie das gewünschte Backup und laden alle Teile (Datenbank, Plugins, Themes, Uploads, Sonstiges) auf Ihren Rechner.

Schritt 2: Frische WordPress-Installation in LocalWP. Neue Site anlegen, Datenbank und Zugangsdaten notieren. Das dauert etwa zwei Minuten.

Schritt 3: UpdraftPlus auf der lokalen Seite installieren. Backup-Dateien in den UpdraftPlus-Backup-Ordner der lokalen Installation kopieren (unter Windows typisch in C:Users[Name]Local Sites[site-name]apppublicwp-contentupdraft).

Schritt 4: Restore starten. In UpdraftPlus erscheint das Backup unter "Vorhandene Backups". Klick auf "Wiederherstellen", alle Komponenten auswählen, Prozess abwarten.

Schritt 5: Ergebnis prüfen. Lädt die Startseite? Funktioniert das Backend? Sind Bilder sichtbar? Können Sie sich einloggen? Bei WooCommerce: Sind Produkte und Bestellungen vorhanden?

Der erste Testlauf dauert 30 bis 45 Minuten. Beim zweiten Mal sind es 15 bis 20.

Was beim Restore-Test konkret geprüft werden muss

Das Frontend lädt - das ist nur der erste Schritt. Ein echter Test prüft mehr:

Frontend: Startseite, eine Unterseite, eine Blogkategorie und eine Produktseite (bei WooCommerce) aufrufen. Bilder müssen laden, Links müssen funktionieren, keine weißen Seiten oder PHP-Fehler.

Backend: Login mit den Zugangsdaten aus dem Backup möglich? Alle Menüpunkte der installierten Plugins vorhanden? Bei WooCommerce: Bestellübersicht, Produktliste, Einstellungen prüfen.

Datenbank: Mit einem Tool wie phpMyAdmin (in LocalWP direkt über "Open Adminer" erreichbar) die Tabellenzahl und die neueste Bestellung oder den neuesten Inhalt prüfen. Stimmt das Datum mit dem Backup-Zeitpunkt überein?

Medien: Unter "Medien" im Backend mindestens zehn zufällige Dateien prüfen, ob die Vorschau lädt. Fehlende Thumbnails können auf einen unvollständigen Uploads-Upload hinweisen.

Formulare und externe Dienste: Für den lokalen Test nicht kritisch, aber notieren Sie, dass im Ernstfall API-Keys (Stripe, Klarna, Mailchimp) nach dem Restore auf die Zieldomäne aktualisiert werden müssen.

Backup-Rotation und Retention: Wie viele Kopien Sie aufbewahren sollten

Ein häufig unterschätztes Problem: Sie haben zwar täglich Backups, aber alle nur für die letzten drei Tage gespeichert. Ein Hack, der vor fünf Tagen stattfand und gestern erst sichtbar wurde, macht alle verfügbaren Backups unbrauchbar - alle enthalten bereits den Schadcode.

Meine Empfehlung für eine mittelgroße WordPress-Seite:

• Tägliche Backups: mindestens 14 Aufbewahrungstage
• Wöchentliche Backups: mindestens 8 Wochen (2 Monate)
• Monatliche Backups: mindestens 6 Monate

In UpdraftPlus Premium lässt sich das direkt konfigurieren. In der kostenlosen Version können Sie die Retention manuell verlängern, indem Sie wichtige Backups in einen separaten Cloud-Ordner verschieben. Mehr zum Thema WordPress-Wartung und regelmäßige Sicherheitsroutinen habe ich im Artikel zu WordPress-Wartung als Service zusammengefasst.

Konkretes Wiederherstellungs-Szenario: Was nach einem Crash zu tun ist

Stellen Sie sich folgendes vor: Montag morgen, 8:45 Uhr. Ein Kunde schreibt, seine Seite zeigt nur einen weißen Bildschirm. Das letzte erfolgreiche Update war Freitag, das Fehler-Log zeigt einen fatalen PHP-Fehler nach einem automatischen Plugin-Update.

Mit einem getesteten Backup-Prozess läuft das so ab:

1. Das zuletzt bekannte gute Backup identifizieren - das vom Donnerstag vor dem Update, also vor dem Problem.
2. Backup vom Cloud-Speicher herunterladen (je nach Größe 2-10 Minuten).
3. In UpdraftPlus Restore starten, nur Plugins und Datenbank auswählen (Uploads wurden nicht verändert).
4. Nach dem Restore: PHP-Fehler-Log prüfen, das problematische Plugin identifizieren und vorübergehend deaktivieren.
5. Seite ist wieder online.

Gesamtzeit mit geübtem Prozess: 15 bis 25 Minuten. Ohne vorherigen Test und ohne klaren Prozess: mehrere Stunden, mit der Möglichkeit, dass das Backup beim ersten Versuch fehlschlägt, weil man nie geprüft hat, ob es vollständig ist.

Für Projekte, bei denen ich das WordPress-Hosting und die Wartung für Kunden übernehme, ist genau dieses Szenario Teil des Service-Vertrags. Der Prozess ist dokumentiert, die Backups werden monatlich getestet und die Reaktionszeit ist garantiert.

Auch im Artikel zu WordPress-Updates ohne Ausfall mit Staging und Rollback beschreibe ich, wie ein gutes Staging-Setup den Restore-Test quasi automatisch mitliefert.

Die häufigsten Fehler beim Restore-Test - und wie man sie vermeidet

Nach vielen Testläufen bei Kundenprojekten fallen immer wieder dieselben Probleme auf:

Fehler 1: Nur das Frontend prüfen. Die Startseite lädt, also scheint alles gut. Dabei fehlt die Hälfte der Datenbank. Immer Backend, Medien und Datenbankinhalt prüfen.

Fehler 2: Den Test mit der neuesten Backup-Version durchführen. Das sagt nichts über die Qualität älterer Backups aus. Testen Sie verschiedene Generationen.

Fehler 3: Kein Protokoll führen. Notieren Sie Datum und Ergebnis jedes Tests in einer einfachen Tabelle. Bei einem echten Crash wissen Sie sofort, welches Backup zuletzt verifiziert wurde.

Fehler 4: Den Test delegieren, ohne ein Schema zu hinterlassen. Wenn Sie als Agenturbetreiber den Test an Mitarbeiter oder Kunden weitergeben, brauchen diese eine klare Checkliste. Improvisation unter Stress führt zu Fehlern.

Fehler 5: Die Backup-Größe nicht prüfen. Ein typisches WordPress-Backup mit 200 Produkten und 2 Jahren Bildarchiv hat leicht 5-15 GB. Wenn Ihr Plugin-Backup plötzlich nur noch 50 MB hat, fehlt etwas.

Häufige Fragen

Wie oft sollte man einen WordPress-Restore-Test durchführen?

Mindestens einmal pro Quartal. Bei Shops oder Seiten mit täglichen Bestellungen empfehle ich monatliche Tests. Jedes Mal nach einem größeren Plugin-Update oder PHP-Versionswechsel beim Hoster lohnt sich ein zusätzlicher Testlauf.

Reicht das automatische Hoster-Backup als einzige Sicherung?

Nein. Hoster-Backups liegen auf derselben Infrastruktur wie Ihre Seite. Fällt der Server aus oder wird er kompromittiert, sind beide weg. Laut einer Analyse werden bei 57 % der Ransomware-Angriffe Server-Backups ebenfalls erfolgreich attackiert. Eine externe Kopie ist Pflicht.

Welche Dateien müssen bei einem vollständigen WordPress-Restore wiederhergestellt werden?

Vier Bereiche: die MySQL-Datenbank (Inhalte, Einstellungen, Benutzer), der Uploads-Ordner (Bilder, PDFs, Mediendateien), alle Plugins und das aktive Theme. Fehlt einer dieser Teile, funktioniert die Seite nicht korrekt oder gar nicht.

Wie lange dauert eine WordPress-Wiederherstellung im Ernstfall?

Mit einem getesteten Prozess und einem frischen Backup: 15-30 Minuten für eine mittelgroße WordPress-Seite. Ohne Vorbereitung kann es Stunden dauern, weil man erst das richtige Backup suchen und die Schritte improvisieren muss.

Was ist der Unterschied zwischen BackWPup, UpdraftPlus und WP Staging?

UpdraftPlus ist ein vollständiges Backup- und Restore-Plugin mit Cloud-Integration (Google Drive, Dropbox, S3). BackWPup konzentriert sich auf flexible Backup-Jobs mit mehr technischen Optionen. WP Staging ist primär für das Erstellen von Staging-Kopien gedacht und eignet sich gut als Restore-Testumgebung, macht aber selbst keine Offsite-Backups.

Muss ich für den Restore-Test eine zweite Domain haben?

Nein. LocalWP läuft komplett lokal auf Ihrem Rechner ohne Domain oder Hosting. Das reicht für 90 % der Restore-Tests aus. Wenn Sie eine echte Staging-Domain wollen, bieten viele Hoster (z.B. Raidboxes, WP Engine) eine Klick-Staging-Funktion an.