Backup-Strategie für kritische Legacy-Systeme: Die 3-2-1-Regel in der Praxis

Fragen Sie in Ihrem Unternehmen nach der Backup-Strategie für das alte Warenwirtschaftssystem. Die Antwort lautet meistens: "Da läuft nachts ein Skript." Wer das Skript geschrieben hat, weiß niemand mehr. Ob es noch durchläuft, prüft niemand. Und wann zuletzt jemand ein Backup zurückgespielt hat, kann keiner sagen.

Genau hier scheitert die Backup-Strategie für Legacy-Systeme in der Praxis. Die 3-2-1-Regel ist seit Jahren bekannt. Sie steht in jedem IT-Handbuch. Bei neuen Cloud-Anwendungen ist sie oft eingebaut. Bei einem System von 2009 hängt sie dagegen an Gewohnheiten und an einem Kollegen, der 2019 gegangen ist.

Dieser Artikel erklärt die 3-2-1-Regel für ältere Systeme. Er zeigt, wo sie bei proprietären Formaten hakt. Und er beschreibt, wie ein Restore aussieht, wenn niemand mehr weiß, wie er geht.

Was die 3-2-1-Regel eigentlich verlangt

Die Regel ist einfach. Sie besagt: Halten Sie drei Kopien Ihrer Daten vor. Speichern Sie diese auf zwei verschiedenen Medientypen. Lagern Sie eine Kopie an einem anderen Ort.

Drei Kopien bedeuten: das laufende System plus zwei Sicherungen. Zwei Medientypen bedeuten zum Beispiel: eine Festplatte im Server und ein Objektspeicher in der Cloud. Der andere Ort schützt vor Brand, Wasserschaden oder Diebstahl im Serverraum.

Viele Firmen ergänzen heute eine vierte Ziffer: 3-2-1-1. Die zusätzliche Eins steht für eine Kopie, die nicht verändert werden kann. Das schützt vor Ransomware. Ransomware ist Schadsoftware, die Daten verschlüsselt und Lösegeld fordert. Sie verschlüsselt gerne auch die Backups, wenn sie erreichbar sind.

So weit die Theorie. Bei einem Legacy-System stellen sich andere Fragen.

Warum Legacy-Systeme die Regel so oft brechen

Ein modernes System speichert seine Daten meist in einer bekannten Datenbank. PostgreSQL, MySQL, vielleicht MariaDB. Dafür gibt es Standardwerkzeuge. Ein Dump ist schnell erzeugt und schnell zurückgespielt.

Bei älterer Software ist das selten so sauber.

Proprietäre Formate

Viele Legacy-Anwendungen speichern in eigenen Formaten. Eine Access-Datenbank aus 2004. Ein Btrieve-Datenbestand. Binärdateien, die nur die Anwendung selbst lesen kann. Ein reines Kopieren der Dateien erzeugt zwar eine Sicherung. Ob diese Sicherung konsistent ist, wissen Sie damit noch nicht.

Konsistent heißt: Alle Dateien passen zum selben Zeitpunkt zusammen. Das Skript kopiert um 2 Uhr Datei A und um 2:05 Uhr Datei B. Dazwischen schreibt ein Nachtjob. Schon passt nichts mehr zusammen. Das Backup sieht vollständig aus. Beim Restore fehlt trotzdem jede zehnte Buchung.

Der Restore braucht das alte System

Ein Backup nützt nur mit einer Umgebung, die es lesen kann. Bei Legacy-Systemen ist das der Haken. Die Datenbankversion von damals gibt es vielleicht nicht mehr zum Download. Die Lizenz hängt an einer Hardware-ID. Das Betriebssystem ist seit Jahren End of Life.

Ein Backup der Daten ohne Backup der Laufzeitumgebung ist nur die halbe Sicherung. Das wird gerne übersehen, weil die Umgebung ja "immer da war".

Niemand hat je zurückgespielt

Das ist der häufigste Befund in unseren Analysen. Das Backup läuft seit Jahren. Es wurde noch nie wiederhergestellt. Nicht einmal testweise.

Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung und keine Strategie.

Was passiert, wenn Sie nichts tun

Der Ernstfall kündigt sich nicht an. Eine Festplatte fällt aus. Ein Update des Hosters bricht die alte Datenbank. Ein Mitarbeiter löscht den falschen Ordner. Oder Ransomware verschlüsselt alles, was per Netzlaufwerk erreichbar ist.

Dann greifen Sie zum Backup. In dem Moment zeigt sich, was es wert ist.

Bei einem Kunden brach das Backup-Skript seit 14 Monaten mit einem Fehler ab. Die Fehlermails las niemand. Bei einem anderen war das Band voll, aber im Haus stand kein Laufwerk mehr, das es lesen konnte. Und beim dritten funktionierte alles, nur dauerte der Restore drei Tage. Drei Tage ohne Auftragsbearbeitung.

Die Kosten sind dann schnell größer als jede Investition in eine saubere Backup-Strategie. Dazu kommt die DSGVO. Sie verlangt die Fähigkeit, Daten nach einem Vorfall rasch wiederherzustellen. Ein ungetestetes Backup erfüllt diese Anforderung nicht.

Die 3-2-1-Regel für Legacy-Systeme umsetzen

Die gute Nachricht: Sie müssen das System dafür nicht modernisieren. Eine tragfähige Backup-Strategie für Legacy-Systeme lässt sich in wenigen Wochen aufbauen. Der Ablauf hat fünf Schritte.

Schritt 1: Bestandsaufnahme

Klären Sie zuerst, was gesichert werden muss. Dazu gehört mehr als die Datenbank: Konfigurationsdateien, Lizenzdateien, Skripte, Cronjobs, Schnittstellen zu anderen Systemen. Und die Laufzeitumgebung selbst: Betriebssystem, Datenbankversion, Bibliotheken.

Diese Liste ist oft länger als erwartet. Sie ist die Grundlage für alles Weitere. Wie so eine Bestandsaufnahme abläuft, beschreibt unser Artikel zur Backup-Strategie für Legacy-Software im Detail.

Schritt 2: Konsistente Sicherung der Daten

Nutzen Sie, wenn möglich, das Exportwerkzeug der Anwendung oder der Datenbank. Das erzeugt einen konsistenten Stand. Wenn es kein solches Werkzeug gibt, stoppen Sie die Anwendung kurz für die Sicherung. Ein Snapshot auf Dateisystemebene ist eine Alternative. Er friert alle Dateien zum selben Zeitpunkt ein.

Zusätzlich empfehlen wir ein Abbild des gesamten Servers. Eine virtuelle Maschine lässt sich als Ganzes sichern. Damit haben Sie auch die Laufzeitumgebung im Backup.

Schritt 3: Drei Kopien, zwei Medien, ein anderer Ort

Jetzt kommt die eigentliche Regel. Die erste Sicherung liegt lokal, zum Beispiel auf einem NAS. Sie ist schnell erreichbar für den Alltag. Die zweite Sicherung geht in einen Objektspeicher außer Haus. Das kann ein deutscher Cloud-Anbieter sein. Wichtig ist: Das Legacy-System darf diesen Speicher nicht mit Schreibrechten erreichen. Sonst verschlüsselt Ransomware ihn gleich mit.

Aktivieren Sie im Objektspeicher die Unveränderbarkeit. Viele Anbieter nennen das Object Lock. Dann kann für einen festgelegten Zeitraum niemand die Sicherung löschen. Auch kein Angreifer mit Admin-Rechten.

Schritt 4: Restore testen. Regelmäßig.

Das ist der Schritt, der fast überall fehlt. Spielen Sie das Backup auf einen separaten Rechner zurück. Starten Sie die Anwendung. Öffnen Sie einen Datensatz von letzter Woche. Stimmt er? Dann funktioniert Ihr Backup.

Dokumentieren Sie jeden Schritt. Wie lange hat es gedauert? Welche Befehle waren nötig? Welche Passwörter? Diese Dokumentation ist Ihr Notfallplan. Sie muss auch dann lesbar sein, wenn der einzige Kenner des Systems im Urlaub ist.

Wir empfehlen einen Restore-Test pro Quartal. Bei kritischen Systemen monatlich.

Schritt 5: Überwachen statt hoffen

Ein Backup-Skript, das still abbricht, ist gefährlicher als gar keins. Weil alle glauben, es wäre da. Richten Sie eine Überwachung ein. Sie gibt Alarm, wenn das Backup ausbleibt oder zu klein ausfällt. Wie das bei älteren Anwendungen geht, zeigt der Artikel zum Monitoring für Legacy-Software.

Prüfen Sie außerdem jedes Backup auf Lesbarkeit. Eine Prüfsumme reicht als Minimum. Besser ist ein automatischer Test-Restore in eine Testumgebung.

Sonderfall: Der Server selbst ist am Ende

Manchmal ist nicht nur die Software alt, sondern auch die Hardware darunter. Dann ist das Backup nur der Anfang. Der Weg zu einem stabilen Betrieb führt über eine Virtualisierung oder einen Umzug. Was dabei zu beachten ist, beschreiben wir unter Server End of Life: Weiterbetrieb oder Migration.

Und wenn es bereits gekracht hat? Dann geht es zuerst um Ursache und Wiederherstellung. Unser Beitrag zur Störungsanalyse bei Legacy-Software beschreibt das Vorgehen.

Fazit

Die 3-2-1-Regel ist nicht kompliziert. Kompliziert wird sie erst, wenn das System Eigenheiten hat, die niemand mehr kennt. Proprietäre Formate, alte Laufzeitumgebungen und fehlende Dokumentation haben sich über Jahre angesammelt. Das lässt sich aufräumen. Ein tragfähiges Backup ist dabei der erste Schritt. Danach kommen Monitoring und Dokumentation.

Wenn Sie nicht sicher sind, ob Ihr Backup im Ernstfall hält, prüfen wir das. Wir schauen uns das System an, testen den Restore und liefern einen Plan. Das ist Teil unserer Software-Wartung und geht auch als einmaliger Auftrag.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos.