Dein Blog zum Thema digitales Business

Wenn bei dir eine Sicherung läuft, beweist das erst einmal nichts. Du siehst nur, dass ein Job gestartet und mit dem Status „erfolgreich“ beendet wurde. Was du damit nicht siehst: ob aus dieser Datei tatsächlich wieder ein funktionierendes System oder eine vollständige Datenbank entsteht. Zwischen „die Sicherung ist gelaufen“ und „die Wiederherstellung funktioniert“ liegt ein Schritt, den viele Backup-Konzepte nie einplanen, geschweige denn regelmäßig durchführen: der tatsächliche Restore. Solange dir dieser Schritt fehlt, hast du eine Annahme, keine Sicherheit.

Was beim Restore tatsächlich schiefgeht

Die Fehlerquellen liegen selten dort, wo du sie vermutest. Ein Sicherungsjob kann monatelang grün laufen und trotzdem eine leere oder beschädigte Datei erzeugen, wenn die zugrunde liegende Verbindung stillschweigend abbricht oder sich ein Speicherpfad ändert, ohne dass ein Alarm ausgelöst wird. Eine Sicherung kann vollständig und intakt sein und trotzdem am Restore scheitern, weil die Zielumgebung eine andere Softwareversion erwartet, weil dir Berechtigungen für den Wiederherstellungsprozess fehlen, weil eine Verschlüsselung einen Schlüssel voraussetzt, der separat aufbewahrt wird und im Ernstfall nicht greifbar ist, oder weil mehrere Systeme wie Datenbank, Objektspeicher und Suchindex beim isolierten Wiederherstellen eines einzelnen Bestandteils auseinanderfallen. Keine dieser Lücken zeigt sich in deinem Monitoring des Backup-Jobs. Sie zeigt sich ausschließlich dann, wenn du versuchst, aus der Sicherung tatsächlich etwas wiederherzustellen.

Restore ist ein eigenständiges Verfahren, kein Rollback

An dieser Stelle lohnt eine kurze Abgrenzung, weil beide Begriffe gern vermischt werden. Ein Rollback dreht eine fehlerhafte Softwareversion zurück, der Code ist die Fehlerquelle, und die Daten bleiben in der Regel erhalten. Was einen geübten Rückweg auf Anwendungsebene ausmacht, haben wir in einem eigenen Beitrag zum Rollback beschrieben. Ein Restore-Test behandelt ein anderes Problem: den Verlust von Daten selbst, durch einen fehlerhaften Löschbefehl, einen Hardwaredefekt oder einen Bedienfehler, bei dem der Rückweg nicht im Code liegt, sondern ausschließlich in deiner Sicherung. Wenn du dein Rollback-Verfahren übst, hast du damit noch nichts über die Restore-Fähigkeit deiner Backups ausgesagt, und umgekehrt.

Wie ein Restore-Test aussieht, der etwas wert ist

Ein Restore-Test, der bei dir Sicherheit erzeugt, hat drei Eigenschaften. Erstens läuft er auf einer Umgebung, die von deiner produktiven getrennt ist, aber realistisch genug bleibt, um dieselben Fehlerquellen zu zeigen: gleiche Softwareversion, gleiche Abhängigkeiten, die echte Sicherungsdatei statt eines Testdatensatzes. Zweitens hat er ein Ergebnis, das über „hat funktioniert“ hinausgeht: eine Prüfsumme, eine Stichprobe an Datensätzen, eine tatsächliche Anmeldung im wiederhergestellten System. Drittens läuft er in einem festen Rhythmus, unabhängig davon, ob du gerade Zeit dafür hast, denn Softwareversionen, Datenbankschemata und Backup-Konfiguration verändern sich laufend, und ein bestandener Test von vor einem Jahr sagt dir nichts über den heutigen Zustand.

Ein anerkannter Ausgangspunkt für die Backup-Seite dieser Überlegung ist die 3-2-1-Regel: mindestens drei Kopien der Daten, auf mindestens zwei unterschiedlichen Speichermedien, davon mindestens eine Kopie extern beziehungsweise offline aufbewahrt. Sie schützt dich vor dem Verlust der Sicherung selbst, sagt aber nichts darüber aus, ob eine dieser drei Kopien im Ernstfall tatsächlich einlesbar ist. Wie beides auseinanderfallen kann, zeigt ein oft zitiertes Beispiel: der GitLab-Vorfall vom Januar 2017. Nach einem versehentlichen Löschbefehl auf der produktiven Datenbank stellte sich heraus, dass mehrere parallel eingerichtete Sicherungs- und Replikationsmechanismen liefen, im Ernstfall aber keiner davon einen vollständig aktuellen, wiederherstellbaren Stand lieferte, weil keiner davon zuvor durch einen echten Restore geprüft worden war. Das Unternehmen hat den Vorfall öffentlich aufgearbeitet, gerade weil er zeigt, dass die Zahl der eingerichteten Sicherungsmechanismen allein nichts über ihre tatsächliche Wiederherstellbarkeit aussagt.

Ein Restore-Test kostet Zeit und passt planmäßig nie in den Moment, in dem du gerade Zeit dafür hast. Genau deshalb gehört er in deinen festen Kalender und nicht in eine Absichtserklärung.

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Alles Weitere richtet sich nach der Lage und läuft über drei Felder: Implementation, also Delivery und Nachweis modulweise in die Pipeline einziehen, AI Governance, also Nachvollziehbarkeit bei KI-gestützten Build- und Deployment-Schritten, und Maintenance, also die Frage, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de