Zum Inhalt springen
Betrieb

Kaltstart statt Backup: eine Website in 30 Minuten neu aufbauen

Vor ein paar Tagen war meine Firmenwebsite weiß. Kein Inhalt, keine Fehlermeldung, kein Admin-Login. Nach 30 Minuten lief sie wieder, allerdings nicht über ein Backup, sondern über einen vollständigen Neuaufbau von null. Dieser Artikel beschreibt diesen Kaltstart Schritt für Schritt: was gelöscht wird, in welcher Reihenfolge, was danach wieder entsteht und welche Voraussetzungen das überhaupt möglich machen. Am Ende steht die Einordnung, warum ein Kaltstart ein Backup nicht ersetzt, sondern etwas anderes leistet.

Inhalt

Die Seite war weiß

Der Aufruf der Startseite lieferte eine leere Antwort. Kein Layout, kein Text, keine Fehlermeldung im Browser, denn die Anzeige von PHP-Fehlern ist auf einem produktiven Server zu Recht abgeschaltet. Das Backend unter /wp-admin verhielt sich identisch: weiße Seite, kein Formular, keine Möglichkeit, sich anzumelden.

Die Seite lief davor wochenlang ohne Beanstandung, und in diesen Wochen gab es keinen Deploy, also auch keine neue Codezeile, die als Ursache in Frage kam. Was auch immer passiert war, es war nicht durch eine Änderung von mir ausgelöst worden.

Der naheliegende Ausweg war das Backup des Hosters. Es ließ sich nicht zu einer funktionierenden Seite zurückführen. Damit fiel der bequeme Weg aus, und die eigentliche Frage stand im Raum: reparieren oder neu bauen?

Der Einsatz dabei ist höher, als es bei einer Firmenwebsite zunächst klingt. Auf dieser Seite liegen Impressum und Datenschutzerklärung, und beide müssen erreichbar sein, solange das Angebot online ist. Eine Seite, die nichts ausliefert, ist deshalb nicht nur ein Imageproblem.

Warum die Fehlersuche die Falle ist

Der professionell klingende Reflex ist Diagnose. Plugins der Reihe nach deaktivieren, das Theme gegen ein Standard-Theme tauschen, WP_DEBUG einschalten, das Speicherlimit erhöhen, die Logs des Hosters durchsehen. Das alles ist richtig, wenn die Ursache innerhalb von Minuten auftaucht.

Es ist falsch, wenn sie das nicht tut. Eine Fehlersuche hat keine Obergrenze. Sie liefert kein Ergebnis zu einem Zeitpunkt, den man zusagen kann, und genau das ist im Störungsfall die entscheidende Eigenschaft. Ein Neuaufbau dagegen hat eine bekannte Dauer. Wer beide Zahlen kennt, muss nicht diskutieren: dauert der Neuaufbau eine halbe Stunde, darf die Suche keine zwei Stunden verschlingen.

Dazu kommt ein Argument, das schwerer wiegt. Eine weiße Seite ohne erkennbare Ursache kann eine Kompromittierung sein. In diesem Fall ist Reparatur die falsche Antwort, weil niemand weiß, was noch im Dateisystem und in der Datenbank liegt. Löschen ist dann der einzige saubere Weg.

Die Reihenfolge, die sich daraus ergibt: erst neu bauen, damit die Seite wieder online ist. Danach, ohne Zeitdruck und an einer Kopie, die Ursache untersuchen, wenn man sie wissen will.

Was ein Kaltstart voraussetzt

Ein Kaltstart ist kein Kunststück, sondern die Folge einer Entscheidung, die lange vorher getroffen wird. Er funktioniert nur, wenn die Seite nicht ausschließlich auf dem Server existiert.

Die Inhalte liegen versioniert vor, also Seitenstruktur, Texte und Bilder als Dateien in einem Repository und nicht nur als Datenbankzeilen. Die Konfiguration ist beschrieben statt geklickt, also Menüs, Startseite, Permalink-Struktur und Theme-Optionen. Die Liste der Plugins ist Teil dieser Beschreibung und nicht Teil meines Gedächtnisses. Die Rechtstexte sind ebenfalls versioniert. Und es gibt einen wiederholbaren Deploy-Schritt, der aus dieser Beschreibung die vollständige Seite herstellt.

Damit ändert sich der Status der laufenden Installation. Man darf sie wegwerfen, weil sie sich jederzeit wieder herstellen lässt, ohne dass jemand nachdenken muss.

Das Prinzip ist nicht neu, es ist die Website-Fassung von unveränderlicher Infrastruktur: Server werden ersetzt statt gepflegt. Neu ist bestenfalls, wie selten das auf Websites angewendet wird. Die meisten Firmenseiten sind gewachsene Einzelstücke, deren Entstehung niemand mehr rekonstruieren kann, und deshalb bleibt dort das Backup die einzige Hoffnung.

Warum das Design der unangenehmste Teil ist

Seiten und Beiträge lassen sich exportieren, dafür bringt WordPress selbst ein Werkzeug mit. Schwer macht den Kaltstart das Aussehen, und der Grund ist struktureller Natur: das Design liegt in der Datenbank und nicht in Dateien.

Die Theme-Einstellungen stehen als ein einziger serialisierter Wert in der Optionstabelle, unter einem Namen, der den Theme-Namen enthält. Menüs sind Einträge einer Taxonomie plus eigene Datensätze, die auf Seiten-IDs zeigen. Die Belegung der Widget-Bereiche ist wieder eine Option. Und wenn ein Seitenbaukasten im Spiel ist, liegt das gesamte Layout jeder einzelnen Seite als großer serialisierter Block in den Metadaten dieser Seite, mit absoluten URLs und numerischen IDs mitten darin.

Nach einer Neuinstallation sind die Inhalte zurück und das Aussehen ist nackt. Farben, Schriftgrößen, Abstände, Kopf- und Fußbereich, die Zuordnung der Startseite und jede Einstellung, die irgendwann in einem Regler gesetzt wurde, sind Voreinstellungen. Das per Hand nachzubauen ist kein Zehn-Minuten-Vorgang, sondern ein Nachmittag, und identisch wird es nie, weil niemand den Wert jedes Reglers erinnert.

Dazu sind die IDs neu. Ein frisch installiertes WordPress verteilt neue Nummern für Seiten und Medien. Wer die Design-Daten eines Baukastens einfach zurückkopiert, bekommt keine Fehlermeldung, sondern verschwundene Bilder und Verweise, die auf die falsche Seite zeigen. Daran scheitern naive Umzüge, still und ohne Warnung.

Entweder das Design liegt als Code im Theme, also Templates und CSS in einem Repository, dann ist es beim Deploy einfach da. Oder die Design-Einstellungen werden als Dateien exportiert und beim Import wieder eingesetzt, dann muss der Import die alten IDs auf die neu vergebenen umschreiben, üblicherweise über eindeutige Namen statt über Nummern.

Mit einem baukasten-getriebenen Design ist ein Kaltstart deutlich schwerer, weil die Daten des Baukastens das Design sind. Wer diesen Weg geht, sollte wissen, dass er sich damit an sein Backup bindet. Für unsere eigene Seite war das einer der Gründe, das Aussehen als Code ins Theme zu ziehen, und dieser Vorfall war die Rechnung, die dafür ausgestellt wurde.

Schritt 1: Bestandsaufnahme, was nur auf dem Server lebt

Vor dem ersten Löschvorgang steht eine Frage, die man nicht gerne stellt. Was existiert ausschließlich auf diesem Server und nirgends sonst? Alles, was darunter fällt, ist nach dem Löschen weg, und die Entscheidung darüber fällt jetzt und nicht später.

Typische Kandidaten sind der Uploads-Ordner mit Medien, die nie im Repository gelandet sind, Einsendungen aus dem Kontaktformular, Kommentare, Zugriffsstatistiken und Texte, die irgendwann direkt im Backend geändert wurden. Der letzte Punkt ist der gefährlichste, weil er unsichtbar ist. Eine im Backend korrigierte Formulierung sieht online genauso aus wie eine versionierte, verhält sich beim Kaltstart aber gegenteilig.

Praktisch dauert dieser Schritt wenige Minuten: den Uploads-Ordner per FTP herunterladen, einen Datenbank-Dump ziehen und die Plugin-Liste sichern. Der Dump ist auch dann sinnvoll, wenn er sich nicht einspielen lässt, denn er ist das Material für die spätere Ursachenanalyse.

Schritt 2: die Domain vom Webspace trennen

Dieser Schritt kommt vor dem Löschen, und die Reihenfolge ist kein Detail. Solange die Domain auf das defekte Verzeichnis zeigt, arbeitet man am öffentlich erreichbaren System. Besucher, Crawler und Monitoring sehen dann jeden Zwischenzustand: die halb geleerte Installation, eine nackte Verzeichnisliste, im schlimmsten Fall den Installationsassistenten von WordPress.

Der letzte Fall ist der ernste, und er ist schlimmer, als er zunächst klingt. Ein WordPress ohne wp-config.php schickt jeden Besucher in die Einrichtung, und die verlangt nichts weiter als eine erreichbare Datenbank. Ein Angreifer gibt seine eigene an, der Installer schreibt diese Zugangsdaten in die wp-config.php, und danach läuft unter deiner Domain eine funktionierende Seite auf einer fremden Datenbank. Ein einzelner Request genügt dafür. Wordfence hat die Masche 2017 als WPSetup-Attack beschrieben, und sie funktioniert weiter, weil sie keine Lücke ausnutzt, sondern den vorgesehenen Ablauf. Ein Wartungsfenster von zehn Minuten reicht dafür aus.

Entweder du löst die Zuordnung der Domain im Hosting-Panel und lässt sie auf eine statische Wartungsseite zeigen, oder du baust die neue Installation parallel in einem zweiten Verzeichnis auf und schaltest die Domain erst am Ende um. Der zweite Weg ist der bessere, weil die Ausfallzeit auf einen einzigen Klick zusammenschrumpft.

Eine Änderung an der Domain-Zuordnung kann eine Neuausstellung des Zertifikats nach sich ziehen, und die braucht ihre Minuten. Und wer dabei am DNS dreht statt am Verzeichnis, wartet zusätzlich die Gültigkeitsdauer des alten Eintrags ab. Deshalb bleibt der DNS-Eintrag am besten unangetastet.

Schritt 3: alle Dateien löschen, wirklich alle

Im Dokumentverzeichnis steht danach nichts mehr.

wp-admin/
wp-includes/
wp-content/          komplett, samt uploads, plugins, themes, mu-plugins
wp-config.php
wp-config-sample.php
index.php
xmlrpc.php
wp-*.php             alle weiteren Dateien mit diesem Muster
.htaccess
.user.ini            und alle weiteren versteckten Dateien

Der Reflex, wp-content zu behalten, ist verständlich und genau der Punkt, an dem ein Kaltstart aufhört, einer zu sein. Dort liegen nicht nur Bilder und Plugins. Dort liegen auch mu-plugins, die WordPress ohne Aktivierung lädt, Drop-ins wie object-cache.php und advanced-cache.php, die sich in den Kern einhängen, generierte Cache-Verzeichnisse und im Fall einer Kompromittierung die interessantesten Dateien überhaupt. Wer diesen Ordner mitnimmt, hat neu installiert und den alten Zustand behalten.

Ohne SSH-Zugang läuft das über FTP oder den Dateimanager des Hosters, und beide sind bei tausenden kleinen Dateien langsam. Schneller ist es, das Dokumentverzeichnis als Ganzes zu löschen und danach neu anzulegen, wenn der Hoster das zulässt. Und der FTP-Client muss versteckte Dateien anzeigen, sonst bleibt die alte .htaccess liegen und schreibt Weiterleitungsregeln für eine Installation, die es nicht mehr gibt.

Schritt 4: die Datenbank löschen, nicht leeren

Tabellen zu leeren fühlt sich sauber an und ist es nicht. Zurück bleiben die Tabellenstrukturen alter Plugin-Versionen, verwaiste Einträge in wp_options, Optionen mit gesetztem autoload, die bei jedem einzelnen Request mitgeladen werden, abgelaufene Transients und defekt serialisierte Werte, an denen PHP still scheitert. Bei einer Kompromittierung kommen Einträge in wp_users und wp_usermeta dazu, die auf den ersten Blick unauffällig aussehen.

Die Datenbank wird deshalb verworfen und neu angelegt, mit neuem Benutzer und neuem Passwort. Der neue Benutzer ist wichtig, weil die alten Zugangsdaten selbst die Ursache gewesen sein können.

DROP DATABASE alte_datenbank;

CREATE DATABASE neue_datenbank
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_520_ci;

CREATE USER 'neuer_benutzer'@'localhost' IDENTIFIED BY 'frisch-erzeugtes-passwort';
GRANT ALL PRIVILEGES ON neue_datenbank.* TO 'neuer_benutzer'@'localhost';
FLUSH PRIVILEGES;

Auf gemieteten Webspaces ist das häufig nicht so umsetzbar, weil DROP DATABASE und das Anlegen von Benutzern über die Weboberfläche gar nicht angeboten werden. Dann löscht man die Datenbank im Panel des Hosters und legt eine neue an. Das Ergebnis ist dasselbe, der Weg ist Handarbeit. Auf den Punkt kommt der Artikel weiter unten noch einmal zurück.

Die Zeichensatz-Angabe ist kein Beiwerk. Wer hier von der bisherigen Einstellung abweicht, bekommt beim Import der Inhalte kaputte Umlaute, und der Schaden zeigt sich nicht auf der Startseite, sondern in älteren Texten, die selten aufgerufen werden.

Schritt 5: WordPress frisch installieren

Jetzt kommt die aktuelle WordPress-Version in das leere Verzeichnis. Drei Dinge werden dabei bewusst gesetzt statt übernommen.

Die PHP-Version wählst du selbst, statt die Voreinstellung des Hosters zu akzeptieren. Ein Kaltstart ist der günstigste Moment, hier auf einen aktuellen Stand zu gehen, weil ohnehin alles neu dazukommt und sich Inkompatibilitäten sofort zeigen statt in sechs Monaten.

Die wp-config.php wird neu geschrieben und nicht aus der Sicherung zurückgeholt. Sie enthält die neuen Datenbankdaten und frische Sicherheitsschlüssel. Neue Schlüssel entwerten jede bestehende Sitzung und jedes gesetzte Anmelde-Cookie, und genau das ist erwünscht. Dazu kommen die Einstellungen, die dieser Hoster braucht, etwa eine feste Methode für Dateisystemzugriffe, damit Installationen nicht nach FTP-Daten fragen.

Am häufigsten übersehen wird die Sichtbarkeit für Suchmaschinen. Eine frische Installation kann so konfiguriert werden, dass sie das Indexieren unterbindet, und diese Einstellung überlebt den gesamten Wiederaufbau unbemerkt. Ebenso wichtig ist die Permalink-Struktur. Steht sie nicht so wie vorher, antworten alle Unterseiten mit 404, obwohl die Inhalte vollständig da sind.

Schritt 6: den Deploy ausführen

Der Teil, der die 30 Minuten überhaupt erst möglich macht, ist der kürzeste. Ein Deploy-Schritt bringt Theme, Seitenstruktur, Texte, Bilder, Menüs und Einstellungen zurück, weil alles davon als Beschreibung vorliegt.

Welche Technik dahintersteht, ist für diesen Artikel zweitrangig. Der Schritt ist wiederholbar, liefert also bei gleichem Ausgangsstand dasselbe Ergebnis, und er ist idempotent, ein zweiter Durchlauf ändert nichts mehr. Das klingt akademisch und zahlt sich im Störungsfall aus, weil man dann selten sicher weiß, was schon gelaufen ist und was nicht.

Ein Backup stellt einen Zustand her, dessen Entstehung niemand kennt. Ein Deploy stellt einen Zustand her, dessen Entstehung als Beschreibung vorliegt und deshalb prüfbar ist.

Eine Reihenfolge gibt es innerhalb dieses Schritts trotzdem, und sie ist nicht beliebig. Medien kommen vor den Inhalten, weil Inhalte auf Medien-IDs verweisen. Inhalte kommen vor den Menüs, weil Menüeinträge auf Seiten-IDs zeigen. Die Einstellungen kommen zuletzt. Wer die Reihenfolge dreht, bekommt keinen Fehler, sondern stille Verweise ins Leere, und das ist die schlechtere von beiden Varianten.

Das Aussehen kommt in diesem Schritt mit, weil es im Theme als Code liegt und nicht in der Optionstabelle. Genau das ist der Unterschied, der die 30 Minuten von einem Nachmittag trennt.

Die Plugin-Liste ist an dieser Stelle keine Erinnerungsübung. Sie steht in der Beschreibung, und sie wird in einer bestimmten Reihenfolge wieder aufgebaut.

Zuerst das Consent-Management, also das Banner und die Regeln, welche Dienste vor einer Einwilligung blockiert bleiben. In Deutschland ist die Einwilligung für den Zugriff auf Endgeräte in Paragraf 25 TDDDG geregelt, und das Gesetz trägt diesen Namen seit dem 13. Mai 2024, vorher hieß es TTDSG. Technisch notwendige Dinge wie ein Session-Cookie bleiben davon ausgenommen, alles Weitere braucht eine aktive Zustimmung. Ein Banner, das erst nach dem Setzen der Cookies erscheint, erfüllt den Zweck nicht.

Dann die Rechtstexte. Impressum und Datenschutzerklärung gehören zum Kaltstart und nicht in einen Nachtrag am Abend. Die Impressumspflicht steht seit dem 14. Mai 2024 in Paragraf 5 DDG, an der Stelle, an der vorher Paragraf 5 TMG stand. Falls die Texte über eine Kanzlei oder einen Dienst kommen, muss diese Verknüpfung wieder aufgebaut werden. Der Textstand selbst gehört ins Repository, sonst ist er nach dem Löschen genau so weg wie alles andere aus der Datenbank.

Danach kommen Kontaktformular und Mailversand. Der Versand über einen SMTP-Zugang muss neu konfiguriert werden, inklusive Zugangsdaten und Absenderadresse. Das ist erfahrungsgemäß der Punkt, der beim ersten Kaltstart vergessen wird, weil er sich nicht anschauen lässt. Man sieht nichts, es kommt einfach keine Mail an.

Bewusst nicht dabei ist alles, was du bei dieser Gelegenheit loswerden wolltest. Ein Kaltstart ist der billigste Zeitpunkt, eine Plugin-Liste zu kürzen, weil nichts deinstalliert werden muss. Es wird einfach nicht wieder installiert.

Der Grund, warum diese Reihenfolge vor der Umschaltung der Domain abgeschlossen sein muss, steht in Schritt 2: die Seite darf nicht ohne Impressum und ohne Consent-Banner öffentlich erreichbar sein, auch nicht für zehn Minuten.

Schritt 8: die Abnahme-Checkliste

Fertig ist die Seite nicht, wenn die Startseite aussieht wie vorher. Fertig ist sie, wenn eine Liste abgearbeitet ist. Beim Ansehen übersieht man genau die Dinge, die man nicht sehen kann.

Startseite antwortet mit 200
drei Unterseiten antworten mit 200
eine erfundene URL antwortet mit 404, nicht mit 200
Impressum und Datenschutzerklärung erreichbar und im Footer verlinkt
Consent-Banner erscheint im privaten Fenster
Ablehnen setzt keine optionalen Cookies
Kontaktformular verschickt eine Mail, und die kommt an
alle Bilder laden über https, keine Mixed-Content-Warnung
Zertifikat gültig, auch für die www-Variante
keine noindex-Angabe im Quelltext
Sitemap erreichbar
Weiterleitungen alter URLs greifen
Admin-Login mit den neuen Zugangsdaten

Zwei dieser Punkte lassen sich in Sekunden prüfen und werden trotzdem am häufigsten übersehen:

curl -s -o /dev/null -w "%{http_code}n" https://deine-domain.de/
curl -s https://deine-domain.de/ | grep -i "noindex"

Die zweite Zeile darf nichts ausgeben. Gibt sie etwas aus, ist die Seite online und für Suchmaschinen unsichtbar, und dieser Zustand fällt sonst erst auf, wenn die Zugriffszahlen einbrechen.

Die 30 Minuten im Detail

Die Zeit steckt nicht dort, wo man sie erwartet. Aufgeteilt sah der Durchlauf ungefähr so aus:

Schritt Dauer
Bestandsaufnahme und Sicherung 5 Minuten
Domain vom Verzeichnis lösen 2 Minuten
Dateien löschen 6 Minuten
Datenbank verwerfen und neu anlegen 2 Minuten
WordPress installieren und konfigurieren 4 Minuten
Deploy 3 Minuten
Plugins, Rechtstexte, Consent, Mailversand 5 Minuten
Abnahme und Domain zurückschalten 3 Minuten

Der langsamste Posten ist das Löschen über FTP, nicht der Wiederaufbau. Der Deploy selbst ist der kürzeste Teil des ganzen Vorgangs, und das ist der eigentliche Punkt der Übung.

In dieser Tabelle fehlt eine Zeile, die bei den meisten Seiten die größte wäre: das Design. Wäre es nicht als Code im Theme beschrieben, sondern in der Datenbank geklickt, müsste hier ein Posten von mehreren Stunden stehen, und die 30 Minuten wären eine andere Zahl.

Was in dieser Rechnung nicht steckt, ist die Ursachenanalyse. Die kam danach, an einer Kopie, ohne Zeitdruck und ohne dass eine öffentlich erreichbare Seite davon abhing.

Was der Kaltstart nicht wiederherstellt

Alles, was ausschließlich in der Datenbank lebte, ist weg. Formular-Einsendungen, Kommentare, Zugriffsstatistiken und jeder Text, der irgendwann direkt im Backend geändert wurde. Ein Kaltstart holt zurück, was beschrieben ist, und nur das.

Daraus folgt eine Arbeitsregel, die schwerer durchzuhalten ist als der technische Teil. Wer seine Seite als Code hält, muss Änderungen auch dort machen. Jede Korrektur, die nur im Backend passiert, lässt den Live-Zustand von der Beschreibung wegdriften, und der nächste Kaltstart wirft sie still weg. Das Verfahren ist deshalb nur so gut wie die Disziplin, mit der es benutzt wird.

Genau an dieser Stelle bleiben Backups unverzichtbar. Sie sind die Antwort auf nicht reproduzierbare Daten, und die gibt es auf fast jeder Seite.

Der manuelle Rest: was der Provider nicht hergibt

Der ehrliche Teil dieser Geschichte ist der Provider. Klassisches Webhosting bietet keine Schnittstelle für das, was hier gebraucht wurde: die Zuordnung einer Domain lösen, ein Verzeichnis leeren, eine Datenbank verwerfen und neu anlegen, die PHP-Version setzen, ein Zertifikat neu ausstellen. Das sind Klicks in einer Weboberfläche, in eigener Reihenfolge, und sie sind der Grund, warum aus 30 Minuten keine drei werden.

Auf echter Cloud-Infrastruktur wäre genau dieser Teil ebenfalls beschrieben statt geklickt. Dann wäre nicht nur die Seite reproduzierbar, sondern auch die Umgebung, in der sie läuft, und der Kaltstart wäre ein Vorgang statt einer Handarbeit. Das ist die interessantere Fortsetzung dieser Geschichte, und sie führt an dieselbe Stelle, an der wir mit Vela Atlas ohnehin arbeiten: an Umgebungen, die aus einer Beschreibung entstehen und deshalb wiederholbar sind.

Bei diesem Vorfall war die Website reproduzierbar, ihre Umgebung nicht. Der Unterschied kostete etwa zehn Minuten Klickarbeit, und diese zehn Minuten sind der einzige Teil des Vorgangs, der sich nicht üben lässt, weil er jedes Mal gleich langweilig und gleich fehleranfällig ist.

Kaltstart oder Backup?

Die Frage ist falsch gestellt, weil beide an unterschiedlichen Reglern drehen. Zwei Kennzahlen aus dem Notfallmanagement machen das greifbar.

Die Wiederherstellungszeit, üblicherweise als RTO bezeichnet, beschreibt, wie lange es dauert, bis der Betrieb wieder läuft. Der maximal tolerierte Datenverlust, das RPO, beschreibt, wie viel Datenstand dabei verloren gehen darf. Ein Kaltstart drückt die Wiederherstellungszeit, weil er unabhängig davon funktioniert, ob eine Sicherung brauchbar ist. Am Datenverlust ändert er nichts. Backups drücken den Datenverlust und sagen nichts über die Dauer.

Wer beides will, braucht beides. Die praktische Ergänzung ist die bekannte Regel, mehrere Kopien auf verschiedenen Medien und eine davon außer Haus zu halten. Und der Satz, der dieselbe Prüfung für beide Seiten fordert: eine Sicherung, die nie zurückgespielt wurde, ist eine Annahme. Ein Kaltstart, der nie geübt wurde, ist ebenfalls eine.

Den Kaltstart üben, ohne die Live-Seite zu riskieren

Üben lässt sich das ohne Risiko, entweder auf einer Subdomain mit eigener Datenbank oder in einem lokalen Container. Der Ablauf ist derselbe wie im Ernstfall: alles löschen, Deploy ausführen, Checkliste abarbeiten, Zeit messen.

Der Wert liegt nicht in der Zeit, sondern in dem, was auffällt. Es ist immer eine Einstellung dabei, die nur im Kopf existierte und in keiner Beschreibung steht. Bei mir war es der Mailversand. Nach dem ersten Durchlauf stand er in der Beschreibung, und im echten Störungsfall war er dann kein Thema mehr.

Ein Durchlauf pro Quartal reicht. Er kostet eine halbe Stunde und ersetzt die Diskussion darüber, ob die Sicherungen wohl funktionieren.

FAQ

Wäre die Fehlersuche nicht der professionellere Weg? Sie ist der professionellere Weg, wenn die Ursache schnell gefunden wird. Ohne Zeitbudget ist sie ein offener Scheck, denn eine Diagnose garantiert kein Ergebnis zu einem festen Zeitpunkt, ein Neuaufbau mit bekannter Dauer schon. Die Ursache lässt sich danach in Ruhe an einer Kopie klären.

Reicht es nicht, wp-content zu behalten und nur den Kern neu zu installieren? Für eine schnelle Reparatur ja, für einen Kaltstart nein. In wp-content liegen mu-plugins, die ohne Aktivierung geladen werden, Drop-ins wie object-cache.php, generierte Cache-Verzeichnisse und bei einer Kompromittierung die eigentlich interessanten Dateien. Wer den Ordner behält, nimmt den alten Zustand mit.

Warum ist bei WordPress das Design schwieriger zurückzuholen als die Inhalte? Weil es in der Datenbank liegt und nicht in Dateien. Theme-Einstellungen stehen als serialisierter Wert in der Optionstabelle, Menüs als Taxonomie-Einträge mit Verweisen auf Seiten-IDs, und bei einem Seitenbaukasten liegt das Layout jeder Seite in ihren Metadaten. Nach einer Neuinstallation sind die IDs neu, deshalb bricht ein einfaches Zurückkopieren still. Verlässlich wird es erst, wenn das Aussehen als Code im Theme liegt.

Muss die Datenbank wirklich gelöscht werden, oder genügt das Leeren der Tabellen? Sie wird verworfen. Leeren lässt Tabellenstrukturen alter Plugin-Versionen, verwaiste Optionen mit gesetztem autoload, defekt serialisierte Werte und mögliche fremde Benutzerkonten zurück. Neuer Datenbankname, neuer Benutzer, neues Passwort.

Warum muss die Domain weg, bevor gelöscht wird? Weil ein WordPress ohne wp-config.php jeden Besucher in die Einrichtung schickt und dabei nur eine erreichbare Datenbank verlangt. Ein Angreifer trägt seine eigene ein und betreibt die Seite danach unter deiner Domain. Wordfence beschreibt das als WPSetup-Attack. Ein kurzes Wartungsfenster reicht dafür aus.

Was passiert mit E-Mail-Konten, DNS-Einträgen und dem Zertifikat? E-Mail-Konten und DNS-Einträge hängen beim Hoster nicht am Webspace und bleiben bestehen, solange man sie nicht anfasst. Genau deshalb bleibt der DNS-Eintrag unangetastet und die Umschaltung passiert über die Verzeichnis-Zuordnung. Das Zertifikat kann eine Neuausstellung brauchen, das ist einzuplanen.

Ersetzt ein Kaltstart die Backups? Nein. Er ersetzt die Abhängigkeit davon, dass ein Backup im entscheidenden Moment funktioniert. Für nicht reproduzierbare Daten wie Formular-Einsendungen oder Bestellungen bleiben Sicherungen die einzige Antwort.

Was bedeuten RTO und RPO hier konkret? Die Wiederherstellungszeit (RTO) ist die Dauer bis zum wieder laufenden Betrieb, der maximal tolerierte Datenverlust (RPO) ist der Datenstand, der dabei verloren gehen darf. Der Kaltstart verbessert die erste Zahl, Backups verbessern die zweite. Es sind zwei Regler, kein Entweder-oder.

Funktioniert das auch mit einem Website-Baukasten? Nur eingeschränkt. Ein Baukasten hält Inhalte und Konfiguration in seinem eigenen System, und was sich nicht exportieren und wieder einspielen lässt, kann auch nicht neu gebaut werden. Der Kaltstart setzt voraus, dass die Seite außerhalb ihrer Laufzeitumgebung vollständig beschrieben ist.

Muss das Impressum während der Wartung erreichbar sein? Der sichere Weg ist, die Domain während des Umbaus auf eine statische Wartungsseite zeigen zu lassen, die Impressum und Datenschutzerklärung enthält. Damit erübrigt sich die Frage, und der Aufwand ist eine einzelne HTML-Datei.

Fazit

Recovery ist nicht die Frage, ob eine Sicherung existiert, sondern ob ein Kaltstart möglich ist. Wer Inhalte, Konfiguration, Plugin-Liste und Rechtstexte als Beschreibung hält, tauscht eine Hoffnung gegen einen Vorgang: die laufende Installation wird ersetzbar, und ein Ausfall wird zu einer halben Stunde Arbeit mit bekanntem Ende statt zu einer Fehlersuche mit offenem Ausgang.

Der nächste Schritt ist klein. Nimm deine eigene Seite und schreibe auf, was existiert nur auf dem Server und in keinem Repository. Die Liste ist der Unterschied zwischen einem Kaltstart und einem Wiederaufbau aus dem Gedächtnis.

Quellen

  • WordPress-Dokumentation zu Neuinstallation, wp-config.php und Sicherheitsschlüsseln, wordpress.org
  • Wordfence, The WPSetup Attack, Beschreibung der Übernahme frischer Installationen über die Einrichtungsseite, wordfence.com
  • Paragraf 5 Digitale-Dienste-Gesetz (DDG), seit 14. Mai 2024 an der Stelle von Paragraf 5 TMG
  • Paragraf 25 Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG), seit 13. Mai 2024 die Bezeichnung des früheren TTDSG
  • Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung), Artikel 32 zur Sicherheit der Verarbeitung
  • BSI IT-Grundschutz-Kompendium, Baustein CON.3 Datensicherungskonzept, bsi.bund.de

Alle Beispiele stammen aus dem eigenen Vorfall und sind selbst geschrieben. Der Artikel ist ein Erfahrungsbericht aus der Praxis und keine Rechtsberatung. Für den konkreten Fall gehört ein Anwalt hinzugezogen.

← Zurück zum Blog

Vela Atlas richtet sich ausschließlich an Unternehmer im Sinne von § 14 BGB. Kein Verkauf an Verbraucher.
$ lang DE • EN • ES