„Die Sicherung war erfolgreich“ ist eine wichtige Meldung. Ob Ihre WordPress-Website daraus wieder benutzbar wird, zeigt erst eine Wiederherstellungsprobe. Dabei wird eine vorhandene Sicherung in einer getrennten Testumgebung eingespielt und anhand vereinbarter Aufgaben geprüft. Ihre laufende Website bleibt das Original.

Als Unternehmer müssen Sie dafür keine Datenbankbefehle beherrschen. Sie sollten anschließend drei Antworten bekommen: Welcher Stand wurde wiederhergestellt? Welche wichtigen Funktionen haben nachweislich gearbeitet? Und was wurde noch nicht geprüft? Ein kurzer Ergebnisbericht ist dafür aussagekräftiger als ein Screenshot der Startseite.

Den Umfang vor der Probe festlegen

Wählen Sie zuerst die Aufgaben, die Ihr Betrieb nach einer Wiederherstellung tatsächlich braucht. Bei einer Firmenwebsite können das eine erreichbare Leistungsseite, ein herunterladbares Datenblatt und eine funktionierende Anfrage sein. Ein Shop benötigt zusätzlich andere Prüfungen als eine reine Unternehmenspräsentation.

Trennen Sie dabei WordPress von angrenzenden Diensten. Postfächer, Domainverwaltung, externe Terminbuchung oder ein Warenwirtschaftssystem sind nicht automatisch Bestandteil derselben Website-Sicherung. Schreiben Sie auf, was zur Probe gehört und welche Zugänge oder separaten Sicherungen dafür benötigt werden. Wie Backups in die laufende Betreuung passen, erklärt unser Beitrag zur WordPress-Wartung; hier geht es gezielt um den Nachweis der Wiederherstellung.

Dateien und Datenbank müssen zusammenpassen

Für die vollständige Wiederherstellung einer üblichen WordPress-Installation werden Dateien und Datenbank benötigt. Zu den Dateien gehören beispielsweise Theme, Plugins und hochgeladene Bilder; Inhalte und viele Einstellungen liegen in der Datenbank. Die offizielle WordPress-Dokumentation zu Backups empfiehlt, beides als zusammengehörigen Sicherungssatz zu behandeln und zeitlich aufeinander abzustimmen.

Lassen Sie im Protokoll die Kennung, Sicherungszeiten und den enthaltenen Umfang beider Teile festhalten. Wurde während der Sicherung weitergearbeitet, muss geklärt sein, wie ein konsistenter Stand entsteht. Ein Ordner voller aktueller Bilder mit einer deutlich älteren Datenbank ist kein nachvollziehbar zusammengehöriger Stand.

Prüfen Sie außerdem, ob die Sicherung tatsächlich abrufbar und gegebenenfalls entschlüsselbar ist. Der Zugang darf nicht ausschließlich in genau der WordPress-Installation liegen, die im Ernstfall ausfällt. Zugangsdaten und Schlüssel gehören in eine geschützte Ablage, nicht in einen frei weitergeleiteten Prüfbericht.

Die Testkopie vor dem ersten Aufruf isolieren

Eine andere Internetadresse allein trennt eine Kopie noch nicht zuverlässig vom laufenden Betrieb. Der technische Verantwortliche richtet ein eigenes Dateiverzeichnis und eine eigene Datenbank ein und prüft die Zielzuordnung. Die Testkopie darf nicht versehentlich auf die Live-Datenbank zugreifen. Ein Zugriffsschutz schützt die Kopie mit ihren möglicherweise enthaltenen Kundendaten vor unbefugten Besuchern. Ein bloßer „noindex“-Hinweis ersetzt diesen Schutz nicht.

Vor dem Start werden ausgehende E-Mails, automatische Aufgaben und Verbindungen zu produktiven Fremdsystemen kontrolliert. Formulare können etwa in einen internen Nachrichtenfänger schreiben; ein Zahlungsanbieter bekommt seine vorgesehene Testumgebung. Echte Empfänger, Rechnungsabläufe oder Kalender dürfen durch die Probe keine unbeabsichtigten Vorgänge erhalten.

Gerade bei Shops ist das konkret zu prüfen: Laut WooCommerce-Dokumentation zu Testbestellungen können auch Testbestellungen E-Mails auslösen und in Auswertungen erscheinen. Erweiterungen unterscheiden sie nicht zwangsläufig von echten Bestellungen. Ein Testmodus beim Zahlungsanbieter sperrt daher nicht automatisch alle anderen Verbindungen.

Die Schutzmaßnahmen und jede absichtlich abgeschaltete Verbindung gehören in den Bericht. Nur dann lässt sich später erklären, weshalb beispielsweise ein Formular lokal funktioniert, aber noch keine Zustellung an das wirkliche Büro-Postfach nachgewiesen wurde.

Vom eingespielten Archiv zu prüfbaren Aufgaben

Ein lesbares Archiv und eine passende Prüfsumme helfen, die Sicherungsdatei zu identifizieren und Übertragungsfehler zu erkennen. Sie belegen für sich weder einen vollständigen Sicherungsinhalt noch eine funktionierende Website. Auch eine Datenbankprüfung hat Grenzen: Der offizielle WP-CLI-Befehl zur Datenbankprüfung kontrolliert den Datenbankstatus und prüft ausdrücklich nicht einmal, ob WordPress installiert ist. Eine technische Erfolgsmeldung ersetzt somit keinen Funktionstest.

Nach dem Einspielen folgen die vereinbarten Aufgaben. Öffnen Sie wichtige Unterseiten direkt, nicht nur über die Startseite. Prüfen Sie Bilder und Downloads sowie die Anmeldung im Verwaltungsbereich. Eine kleine Textänderung und deren erneutes Laden zeigen, ob die Testkopie auch Änderungen speichern kann. Arbeiten Sie ausschließlich in der erkennbar beschrifteten Kopie.

Bei einer abweichenden Testadresse müssen auch gespeicherte Adressen berücksichtigt werden. Die WordPress-Anleitung zur Migration beschreibt, dass neben den Website-Einstellungen weitere gespeicherte Verweise betroffen sein können. Lassen Sie deshalb prüfen, ob Bilder oder Schaltflächen unbemerkt zurück zur Live-Seite führen. Eine Kopie, die ihre Inhalte noch vom Original lädt, kann einen unvollständigen Restore verdecken.

Beispiel: ein ausgefülltes Protokoll statt pauschaler Freigabe

Der folgende Fensterbaubetrieb, seine Sicherungen und alle Ergebnisse sind vollständig fiktiv. Das Muster zeigt, wie ein ehrlicher Prüfbericht aussehen kann. Es dokumentiert keine von PEMKO ausgeführte Wiederherstellung.

Fiktive Wiederherstellungsprobe einer Firmenwebsite
Prüfpunkt	Dokumentiertes Beispielergebnis
Sicherung und Ziel	Satz A-1510: `firma-dateien-A.zip` und `firma-db-A.sql`; gemeinsamer Sicherungsstand 15.10.2026, 18:00 MESZ. Ziel: eigene, zugriffsgeschützte Testinstallation `probe.example`.
Trennung vom Betrieb	Eigene Datenbank bestätigt. Ausgehende Nachrichten werden intern abgefangen; produktive Kalender- und Zahlungszugänge sind gesperrt.
Inhalte und Medien	Leistungsseite, Kontaktseite und sechs ausgewählte Projektbilder vorhanden. Ein älteres PDF fehlt im Sicherungssatz; Downloadprüfung nicht bestanden.
Verwaltung	Anmeldung mit einem vorgesehenen Prüfkonto möglich. Ein Probentext lässt sich speichern und nach erneutem Aufruf lesen.
Anfrageweg	Pflichtfeldprüfung und Bestätigung funktionieren; Nachricht im internen Nachrichtenfänger eingegangen. Zustellung an das echte Büro-Postfach ausdrücklich nicht getestet.
Weitere Grenzen	Externer Terminservice und Domainumschaltung nicht geprüft. Die Probe enthält keine Schadsoftwareanalyse und keinen Nachweis einer bestimmten Wiederanlaufzeit.
Bewertung und nächste Aufgabe	Teilweise bestanden. Fehlendes PDF und Ursache klären, betroffene Sicherung korrigieren und Download erneut prüfen. Offene Zustellungsprüfung separat planen.

Im wirklichen Bericht ergänzen Sie Datum, prüfende Person, genaue Adressen und Belege zu den einzelnen Aufgaben. Halten Sie Beginn, Unterbrechungen und Ende fest, wenn Sie die benötigte Zeit ermitteln wollen. Die Dauer einer einzelnen Probe wird dadurch noch nicht zu einer garantierten Wiederanlaufzeit im Ernstfall.

Was ein bestandenes Ergebnis aussagt

„Bestanden“ sollte bedeuten: Der benannte Sicherungssatz ließ sich unter den dokumentierten Bedingungen wiederherstellen, und die vereinbarten Aufgaben wurden erfüllt. „Teilweise bestanden“ benennt die offenen Punkte. Fehlt ein notwendiger Sicherungsteil oder ist keine sichere Trennung möglich, wird die Probe abgebrochen und die Ursache geklärt.

Ein Restore setzt den gesicherten Zustand zurück. Die WordPress-Anleitung zur Datenbankwiederherstellung weist darauf hin, dass die vorhandene Datenbank durch den Sicherungsstand ersetzt wird. Neuere Inhalte oder dort gespeicherte Vorgänge müssen bei einer echten Rücksetzung deshalb gesondert berücksichtigt werden. Eine erfolgreiche Probe übernimmt sie nicht automatisch.

Ebenso wenig bescheinigt eine funktionierende Kopie, dass sie frei von Schadsoftware ist. Besteht ein Angriffsverdacht, braucht es einen anderen Ablauf mit Ursachenklärung und Sicherheitsprüfung. Dafür ist unser Leitfaden zur Wiederherstellung nach einem WordPress-Hack gedacht.

Aus der Probe einen wiederholbaren Ablauf machen

Bewahren Sie Ergebnisbericht und Wiederherstellungsanleitung außerhalb der geprüften Website geschützt auf. Vereinbaren Sie einen passenden Wiederholungstermin und zusätzliche Proben nach wesentlichen Änderungen, etwa einem neuen Hosting, Sicherungsverfahren oder zentralen Formularsystem. Entscheidend ist, dass Anleitung, Zuständigkeit und tatsächliche Website noch zusammenpassen.

Nach Abschluss wird die Testkopie nach der vereinbarten Aufbewahrungsfrist entfernt; der ursprüngliche Sicherungssatz bleibt entsprechend Ihrer Sicherungsplanung erhalten. Eine Wiederherstellungsprobe ist kein Anlass, die Testdatenbank zurück über die laufende Website zu schreiben.

Wenn Sie eine solche Probe für Ihre WordPress-Website besprechen möchten, nennen Sie die wichtigsten Funktionen und das bisherige Sicherungsverfahren. Daraus lässt sich ein begrenzter Prüfauftrag ableiten: ein benannter Sicherungsstand, ein isoliertes Ziel und ein Bericht mit Ergebnissen und offenen Punkten.

WordPress-Backup testen: Was eine Wiederherstellungsprobe zeigen sollte