Eine Website ist kein einzelnes Verzeichnis
Eine WordPress-Seite setzt sich aus mehreren Beständen zusammen. In der Datenbank liegen unter anderem redaktionelle Inhalte und Einstellungen; im Dateisystem liegen beispielsweise hochgeladene Medien, Themes und Plugins. Die Konfiguration verbindet diese Teile mit der Umgebung. Für eine Migration oder Wiederherstellung müssen sie zusammenpassen.
Die wichtigste Übergabefrage lautet deshalb: Welcher vollständige Zustand wurde zu welchem Zeitpunkt gesichert? Eine heruntergeladene Medienbibliothek beantwortet diese Frage ebenso wenig wie ein einzelner Datenbankexport. Erfassen Sie zuerst die eigene Installation, ihr tatsächliches Webverzeichnis, die Datenbankzuordnung und zusätzliche Ablageorte. Dazu können individuell konfigurierte Verzeichnisse oder externe Dienste gehören. Diese Orte werden nur eingetragen, wenn sie im Projekt wirklich existieren. Ein allgemeines WordPress-Schema ist eine Orientierung und kein Inventar Ihres Hosts.
Bestände sichtbar zuordnen
| Bestand | Typische Aufgabe | Übergabenachweis |
|---|---|---|
| Datenbank | Inhalte und Einstellungen wiederherstellen | Eigene Zuordnung und nutzbarer Export |
| Medien | Bilder und Dokumente passend ausliefern | Dateibestand, Pfade und Stichproben |
| Theme und Plugins | Die benötigte Anwendung ausführen | Versionen und eigene Anpassungen |
| Konfiguration | Bestände sicher an die Umgebung binden | Geschützte Angaben und dokumentierter Zielhost |
WordPress selbst beschreibt Backups als Zusammenspiel von Datenbank und Dateien. Welche zusätzlichen Daten eine Erweiterung außerhalb dieser üblichen Orte ablegt, ist projektspezifisch. Fragen Sie besonders bei Imports, individuellen Schnittstellen und externen Medienablagen nach. Ein erfolgreich gestartetes Backupwerkzeug sagt noch nicht, ob diese Bestände enthalten sind. Für die Abnahme hilft ein tatsächlich sichtbares Inhaltsverzeichnis des Archivs.
Ein gemeinsamer Zeitpunkt ist wichtig
Während einer laufenden Websiteänderung können neue Inhalte und Dateien entstehen. Wird zuerst die Datenbank exportiert und später der Dateibestand kopiert, passen einzelne Änderungen möglicherweise nicht zum gewählten Stand. Bei einer weitgehend statischen Informationsseite ist das überschaubarer als bei einer Anwendung mit vielen Schreibvorgängen; trotzdem gehört die Annahme in den Plan.
Legen Sie fest, wann Änderungen pausieren und welcher Stand maßgeblich ist. Für einen Umzug sollte das Team wissen, bis wann redaktionell gearbeitet werden darf und wie später eingegangene Daten behandelt werden. Versprechen Sie keinen verlustfreien Wechsel allein auf Grundlage zweier erfolgreicher Kopiervorgänge. Im Projektprotokoll stehen Zeitpunkt, Quelle, Umfang und verantwortliche Person. Ein Archivhash belegt später, dass Sie dasselbe Archiv betrachten; er belegt keine inhaltliche Vollständigkeit oder erfolgreiche Wiederherstellung.
Die neue Umgebung muss die Anwendung tragen
Eine kopierte Anwendung benötigt am Ziel eine passende Laufzeit und gültige Rechte. Auch die Datenbankverbindung und die gewünschten URLs müssen zur neuen Umgebung gehören. Die offizielle WordPress-Migrationsdokumentation unterscheidet dabei die Adresse der Website von der Adresse der WordPress-Dateien. Diese Einstellungen können identisch sein, müssen es aber nicht.
Führen Sie vor der öffentlichen DNS-Umstellung einen geschützten Test durch. Prüfen Sie eine Inhaltsseite, Medien, Navigation und die tatsächlich vorhandenen Anwendungsfunktionen. Eine bloß sichtbare Startseite ist eine zu kleine Stichprobe. Das TLS-Dossier ergänzt die Prüfung der Namen und Ressourcen; das Dualstack-Dossier trennt die Netzwerkwege. Die technische Abnahme wird damit schrittweise ergänzt, ohne jede Fehlerart unter dem Sammelbegriff „Migration läuft“ zu verstecken.
Zugangsangaben geschützt übergeben
Konfigurationsdateien und Exporte können Zugangsdaten oder persönliche Inhalte enthalten. Halten Sie sie außerhalb öffentlich ausgelieferter Verzeichnisse und beschränken Sie den Zugriff. Die Übergabe enthält den sicheren Ablageort und die berechtigte Person; Passwörter werden nicht in einen allgemein lesbaren Projektbericht kopiert. Auch eine nachträglich heruntergeladene Sicherung bleibt ein schützenswerter Datenbestand.
Verwenden Sie beim Aufbau eines getrennten Projekts eigene Zugänge und eine eigene Datenbankzuordnung. Eine vorhandene Datenbank aus einem anderen Kundenprojekt ist keine Abkürzung. Für ein größeres Agenturvorhaben beschreibt das Managed-Server-Agency-Dossier die passenden Entscheidungsfragen. Aus dem Produktnamen folgt allerdings keine automatisch geregelte Zugangsübergabe. Diese muss im tatsächlichen Betrieb dokumentiert und bei Personal- oder Agenturwechseln aktualisiert werden.
Abhängigkeiten gehören auf das Übergabeblatt
Ein vollständig kopierter WordPress-Bestand kann trotzdem eine externe Abhängigkeit besitzen. Beispiele sind eine tatsächlich eingerichtete Schnittstelle, ein gesonderter Medienbestand oder eine bezogene Erweiterung mit eigener Berechtigung. Notieren Sie deren Zweck und Verantwortlichkeit. Legen Sie keine fremden Zugangsdaten in das Archiv, nur weil die Anwendung darauf verweist. Ein sicherer Übergabeweg muss zu jeder benötigten Berechtigung gehören.
Für den Wiederherstellungstest ist wichtig, welche dieser Verbindungen absichtlich deaktiviert bleiben. Eine Testumgebung sollte keine realen Bestellungen oder Nachrichten erzeugen. Prüfen Sie die lokalen Inhalte und den vorgesehenen Ersatz für externe Vorgänge. Kennzeichnen Sie anschließend, welche Funktion tatsächlich überprüft wurde und welche wegen einer ausgeschalteten Verbindung offen bleibt. Diese Trennung macht den Restorebericht genauer: Die Anwendung kann starten, während eine wichtige Integration noch einen gesonderten Nachweis benötigt. Das ist ein konkreter Anschlussauftrag, kein Grund für eine pauschale Erfolgsmeldung.
Aus einer Sicherung erst durch einen Test einen Nachweis machen
Ein vollständiger Wiederherstellungsnachweis entsteht erst, wenn der gewählte Stand in einer getrennten Umgebung eingesetzt und die Anwendung dort überprüft wurde. Halten Sie den verwendeten Archivstand, die Zielumgebung und die getesteten Funktionen fest. Wenn nur Download und Inhaltsprüfung durchgeführt wurden, lautet der Status „Sicherung vorhanden und geprüft“, nicht „Restore erfolgreich“.
- Eigenen Installations- und Datenbankumfang bestätigen.
- Gemeinsamen Sicherungszeitpunkt und mögliche Schreibpause festlegen.
- Archive geschützt ablegen und ihre Lesbarkeit prüfen.
- Wiederherstellung getrennt durchführen und tatsächliche Ergebnisse protokollieren.
- Rückkehrweg vor der öffentlichen Umstellung vorbereiten.
Dieser Ablauf ist bewusst unabhängig vom Namen eines Backupplugins. Für eine kleine Informationsseite kann die Liste kurz ausfallen; für mehrere Anwendungen benötigt sie getrennte Einträge. Entscheidend ist, dass das nächste Team nachvollziehen kann, welcher Zustand gesichert ist, was getestet wurde und wo noch ein praktischer Nachweis fehlt.