Wenn es zum Schlimmsten kommt - musst Du wissen was zu tun ist
Was nützt ein regelmäßiges Backup, wenn man nicht mit Bestimmtheit sagen kann, ob und wie man es Wiederherstellen kann?
Bevor eine Webseite online geht und mindestens einmal pro Jahr sollte man den Ernstfall proben,
Was ist ein realistischer Ernstfall?
Ein schneller klick, an der falschen Stelle. Mehr ist nicht nötig um eine Webseite abzuschießen. Natürlich nicht für einen Besucher, das machen Administratoren. Oder Menschen mit Rechten von Administratoren, was übrigens ein guter Grund für die Einführung eines Rechte-Konzeptes ist. Fehler passieren auch im professionellen Umfeld. Vor jedem Update einer Softwarekomponente auf einem produktiv genutzten System, sollte man ein Backup erstellen. Weil auch ein Softwareupdate fehlerhaft sein kann, muss sichergestellt sein, das wir die Zeit zurückdrehen können. Das bedeutet, das Datenbank und Filesystem wieder so werden, wie sie zum Zeitpunkt des Backups - also vor dem fehlerhaften Update - waren.
Einen Plan oder mehrere?
Wir fangen mit dem Ersten an, dann sehen wir weiter.
Der Plan sollte als Minimalanforderung alle Schritte enthalten, die nötig sind um ein Backup an anderer selber oder anderer Stelle wieder herzustellen. Da ich den aktuellen Platz für die Neuinstallation benötige, wird der Restore an anderer Stelle erfolgen.
Fangen wir den Neuanfang also mit einem Plan für den Notfall an!
- einige Momente später -
Natürlich habe ich NICHT zuerst den Plan erstellt, sondern meinen ersten Plan in Form von Screenshots und ersten Texten in einem Dokument "on the fly" erstellt. Daraus kann bei Gelegenheit ein "besseres" Dokument werden.
Vorerst ist sichergestellt das die Methodik funktioniert und der Ablauf (Prozess) nachvollziehbar dokumentiert ist.
Dieser Prozess funktioniert natürlich in beide Richtungen.
Prod- & Test Umgebung
Besitzt man eine Domain wie Leinetal.de, kann man auch Sub-Domains haben wie test.leinetal.de
Aus lizenztechnischen Gründen hat eine solche Sub-Domain Vorteile für den Einsatz als Test-Umgebung, parallel zur Produktions-Umgebung auf der Haupt Domain leinetal.de
So könnte der Prozess aussehen um eine Änderung an einer Webseite in der Sub-Domain test.Leinetal.de zu validieren und auf die produktive Domain Leinetal.de zu übertragen:
Die farblichen Unterschiede helfen bei der Einordung von Aktivitäten in Gruppen. Mit diesem Bild vor Augen ist die Herausforderung der Dokumentation ungleich kleiner.
Natürlich ist klar, dass eine Webseite nicht wochenlang offline gehen kann, während man in aller Ruhe die Implementierung neuer Komponenten testet.
Für mich machen drei Stufen Sinn:
1. Produktionsumgebung (PROD)
2. Test- & Abnahme-Umgebung (PAT)
Möglichst produktionsnah, limitierter Zugang nur für ausgewählte und instruierte Tester
- zeitlich begrenzt
- mit klarer (Test-) Aufgabe
- strukuriertes Feedback
3. Entwicklungsumgebung (DEV)
- lokal = schnelles (re-)Deployment
Die spätere PAT Umgebung nutze ich bis zum Leinetal Release 1.0.00 als Referenzumgebung, die ich aus dem vorliegenden Backup file jederzeit wieder neu aufsetzen kann. Hier habe ich noch einiges an vorbereiteten "Content" der später integriert werden kann.
In das Thema Backup steige ich später wieder ein. Hier benötige ich eine klare Struktur für den Umgang mit den Backup Dateien. #lifecycle
Kurz, Disaster Recovery funktioniert und ist vorläufig dokumentiert.