Disaster Recovery für Legacy-Systeme: Was ein Notfallplan enthalten muss
Der Server ist tot. Die Warenwirtschaft läuft nicht mehr. Der Kollege, der das System 2011 aufgesetzt hat, ist seit vier Jahren in Rente. Sein Nachfolger kennt das Passwort für die Datenbank, aber nicht den Weg, wie die Anwendung überhaupt startet. So sieht der Ernstfall bei vielen Unternehmen aus. Disaster Recovery für Legacy-Systeme bedeutet genau das: Ihr System nach einem Ausfall wieder in Betrieb bringen. Und zwar planbar, nicht durch Glück.
Ein Backup allein reicht dafür nicht. Ein Backup ist eine Kopie der Daten. Disaster Recovery ist der komplette Weg vom Ausfall zurück zum laufenden Betrieb. Dieser Artikel zeigt, was ein Notfallplan für ein altes System enthalten muss, damit dieser Weg auch ohne den ursprünglichen Entwickler funktioniert.
Warum Legacy-Systeme im Notfall besonders verwundbar sind
Moderne Anwendungen werden oft per Skript aus dem Nichts aufgebaut. Ein Befehl, zehn Minuten warten, fertig. Bei Legacy Software sieht das anders aus. Der Server ist über Jahre gewachsen. Jemand hat 2014 eine Bibliothek von Hand installiert. Jemand hat 2017 eine Konfigurationsdatei angepasst und nirgends notiert, warum. Das System läuft, aber niemand kann sagen, warum es läuft.
Dazu kommen Abhängigkeiten, die keiner mehr auf dem Schirm hat: eine alte PHP- oder Java-Version, die es in aktuellen Paketquellen nicht mehr gibt. Ein Lizenzschlüssel, der an die Hardware gebunden ist. Ein Cronjob, der nachts Daten mit einem Partner austauscht und den nur der alte Admin kannte.
Fällt so ein Server aus, stehen Sie vor drei Fragen. Haben wir die Daten? Haben wir eine Umgebung, in der das System läuft? Und wissen wir, wie beides zusammengesetzt wird? Meist lässt sich nur die erste Frage mit Ja beantworten.
Was passiert, wenn kein Notfallplan existiert
Ohne Plan beginnt im Ernstfall die Improvisation. Das kostet Zeit, und jede Stunde kostet Geld. Ein Beispiel aus unserer Praxis: Ein Handelsunternehmen mit rund 40 Mitarbeitern verlor nach einem Festplattendefekt sein Auftragssystem. Backups gab es. Die Wiederherstellung dauerte trotzdem sechs Arbeitstage. Nicht wegen der Daten, sondern weil niemand wusste, welche Systemversion die Anwendung brauchte. Das passende Installationspaket fand sich erst nach zwei Tagen Suche auf einem alten Netzlaufwerk.
Sechs Tage ohne Auftragssystem bedeuten: Bestellungen per Telefon und Zettel, keine Lieferscheine, keine Rechnungen. Der Umsatzausfall lag höher als die Kosten für fünf Jahre Wartung.
Der zweite Schaden ist schleichender. Nach so einem Vorfall vertrauen Mitarbeiter dem System nicht mehr. Kunden fragen, ob ihre Daten sicher sind. Und die Geschäftsführung diskutiert plötzlich eine Neuentwicklung, die eigentlich niemand wollte.
Die fünf Bestandteile eines Notfallplans für Legacy-Systeme
Ein brauchbarer Disaster-Recovery-Plan ist kein 80-Seiten-Dokument. Er beantwortet fünf Fragen, und zwar so, dass ein fremder Techniker damit arbeiten kann.
1. Systemdokumentation: Was läuft wo, und wovon hängt es ab?
Der erste Schritt ist eine Inventur. Welche Server gibt es? Welches Betriebssystem, welche Version der Laufzeitumgebung, welche Datenbank? Welche externen Dienste werden angesprochen? Wo liegen Konfigurationsdateien, Zertifikate und Lizenzschlüssel?
Diese Liste muss nicht schön sein. Sie muss vollständig sein. Wir halten sie in einer einfachen Textdatei im Repository, damit sie beim nächsten Update gleich mitgepflegt wird. Zugangsdaten gehören allerdings nicht in diese Datei, sondern in einen Passwortmanager, auf den mindestens zwei Personen Zugriff haben.
Ein häufig vergessener Punkt sind die Installationsquellen. Wenn Ihre Anwendung PHP 5.6 braucht, muss der Plan sagen, wo Sie dieses Paket im Notfall herbekommen. Sonst beginnt die Suche im schlimmsten Moment.
2. Backups, die tatsächlich getestet werden
Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Wir haben mehr als einmal erlebt, dass die nächtliche Sicherung seit Monaten leere Archive schrieb, weil ein Pfad nach einem Umzug nicht mehr stimmte. Aufgefallen ist es erst beim Ausfall.
Deshalb gehört in jeden Notfallplan ein Testrhythmus. Mindestens einmal im Quartal wird ein Backup auf einer separaten Maschine eingespielt und die Anwendung dort gestartet. Wie Sie die Sicherung selbst sinnvoll aufbauen, beschreibt unser Artikel zur 3-2-1-Regel für Backups bei Legacy-Systemen. Kurz gesagt: drei Kopien, zwei Medien, eine davon außer Haus.
Für alte Systeme kommt ein Punkt hinzu, der bei neuen Anwendungen entfällt. Sichern Sie nicht nur die Datenbank, sondern auch die installierte Umgebung. Ein Abbild des kompletten Servers ist bei Legacy-Systemen oft mehr wert als das sauberste Datenbank-Backup. Denn das Abbild enthält die von Hand installierten Bibliotheken, die niemand mehr rekonstruieren kann.
3. RTO und RPO: Wie lange darf es dauern, wie viel darf verloren gehen?
Zwei Kennzahlen bestimmen, wie aufwendig Ihr Plan sein muss. RTO steht für Recovery Time Objective: die Zeit, nach der das System wieder laufen muss. RPO steht für Recovery Point Objective: der Datenverlust, den Sie maximal hinnehmen können, gemessen in Zeit.
Ein Beispiel: Ihr Auftragssystem darf höchstens vier Stunden ausfallen (RTO) und höchstens eine Stunde Daten verlieren (RPO). Dann reicht ein nächtliches Backup nicht. Sie brauchen stündliche Sicherungen und eine vorbereitete Ersatzumgebung.
Diese Zahlen legt nicht die IT fest, sondern die Geschäftsführung. Denn dahinter steht eine Kostenfrage. Je kürzer RTO und RPO, desto teurer die Vorsorge. Ein internes Zeiterfassungstool verträgt einen Tag Ausfall. Ein Shop im Weihnachtsgeschäft nicht. Was solche Zusagen in der Praxis bedeuten, lesen Sie in unserem Beitrag Was bedeutet ein SLA mit 99,9 Prozent?.
4. Die Wiederherstellungsanleitung: Schritt für Schritt
Das ist das Herzstück und der Teil, der am häufigsten fehlt. Eine Anleitung, die ein Techniker ohne Vorwissen abarbeiten kann. Server bereitstellen. Betriebssystem in Version X installieren. Pakete A, B und C aus Quelle Y einspielen. Anwendung aus dem Backup entpacken. Konfiguration anpassen. Datenbank einspielen. Dienste starten. Prüfen, ob die Startseite antwortet.
Schreiben Sie diese Anleitung nicht aus dem Kopf. Schreiben Sie sie beim Backup-Test mit. Jeder Stolperstein, der dabei auftaucht, wird notiert. Nach dem zweiten Durchlauf ist die Anleitung meist brauchbar.
5. Zuständigkeiten: Wer tut was, und wen ruft man an?
Im Ernstfall darf nicht die Frage entstehen, wer eigentlich zuständig ist. Der Plan nennt eine Person, die die Wiederherstellung leitet, und eine Vertretung. Er nennt, wer die Geschäftsführung informiert und wer die Kunden. Und er enthält die Telefonnummern von Hoster, Dienstleister und, falls vorhanden, dem ehemaligen Entwickler.
Hängen Sie diesen Teil auch ausgedruckt auf. Wenn der Server steht, kommen Sie vielleicht auch nicht mehr ins Wiki, in dem der Plan liegt.
So gehen Sie es an, ohne alles auf einmal zu machen
Sie müssen nicht in einer Woche den perfekten Plan schreiben. Sinnvoll ist eine Reihenfolge, die das größte Risiko zuerst senkt.
Beginnen Sie mit einem Wiederherstellungstest. Spielen Sie das aktuelle Backup auf einer Testmaschine ein und versuchen Sie, die Anwendung zu starten. Alles, was dabei schiefgeht, ist Ihre To-do-Liste. Dieser eine Nachmittag bringt mehr Erkenntnis als jedes Konzeptpapier.
Danach legen Sie RTO und RPO fest. Erst mit diesen Zahlen wissen Sie, ob nächtliche Backups genügen oder ob Sie eine bereitstehende Ersatzumgebung brauchen.
Dann schreiben Sie die Anleitung und die Kontaktliste. Und zum Schluss tragen Sie den nächsten Testtermin in den Kalender ein. Ein Plan, der nicht regelmäßig geprüft wird, veraltet still. Genauso still, wie sich Störungen in alten Systemen ankündigen. Wie Sie solche Vorboten erkennen, zeigt unsere Störungsanalyse für Legacy-Software.
Fazit: Der Plan ist billiger als der Ausfall
Disaster Recovery für Legacy-Systeme ist eine Frage der Vorbereitung. Backups haben die meisten. Eine getestete Anleitung, klare Zuständigkeiten und realistische Ziele für Ausfallzeit und Datenverlust haben die wenigsten. Diese Lücke entscheidet im Ernstfall über sechs Stunden oder sechs Tage Stillstand.
Wenn Sie nicht wissen, ob Ihr altes System nach einem Ausfall wieder hochkommt, schauen wir uns das an. Unsere System-Analyse für den Notfall dokumentiert Abhängigkeiten, testet die Wiederherstellung und liefert Ihnen einen Plan, mit dem auch ein fremder Techniker arbeiten kann. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
