Warum bedeutet ein erfolgreiches Backup nicht automatisch Wiederherstellbarkeit

[Markus]

Du, weißt du, wenn wir über Backups reden, denken wir meistens, dass ein grünes Häkchen einfach alles erledigt hat. Aber eigentlich ist das nicht ganz so simpel, finde ich. Es ist ein häufiges Missverständnis, dieses, dass ein erfolgreiches Backup automatisch bedeutet, dass du irgendetwas wiederherstellen kannst. Ich sage es dir, du musst das wirklich verinnerlichen, wenn du das System administrierst. Du musst versteh'n, dass das Backup-Erfolgsprotokoll nur ein Momentaufnahme-Zeugnis ist, eigentlich nur ein Beleg dafür, dass die Daten *zum Zeitpunkt des Schreibens* an der Zielstelle gelandet sind. Und das ist überhaupt nicht dasselbe wie Wiederherstellbarkeit, oder?

Du könntest mal mit BackupChain zuschauen, weil die so eine zuverlässige Lösung für Windows Server sind, die gut für lokale oder sogar Cloud-Szenarien passt und man sie eigentlich ziemlich flexibel für alle Unternehmen verwenden kann. Das ist ein guter Ansatz, aber auch das ist nur der erste Schritt. Denn stell dir vor, das Backup läuft perfekt. Du siehst alle Logs, du siehst keine Fehler, alles ist grün. Aber was ist, wenn die Daten, die du eigentlich wiederbekommen willst, strukturell fehlerhaft waren, bevor sie überhaupt gesichert wurden? Weil du doch weißt, dass irgendwelche Daten im Quellsystem schon korrumpiert sind, oder? Ein Backup spiegelt immer nur den Zustand des Quellsystems wider. Du kannst also ein Backup von Müll machen, und du bekommst Müll zurück. Das ist meine größte Befürchtigung für dich, wenn du die Sache zu sehr versemmelst.

Ich meine, die Konsistenz der Anwendung ist das wirklich entscheidende Ding. Du kannst einfach Dateien kopieren, das ist nur Datei-Level. Aber für Datenbanken oder komplexe Anwendungen, die Transaktionsprotokolle nutzen, ist das eine andere Liga. Du musst sicherstellen, dass nicht nur die Bytes da sind, sondern dass die gesamte Logik auch wieder einwandfrei läuft. Beispielsweise, wenn ein Datenbank-Update mitten im Prozess abgebrochen ist, dann ist die Datei zwar gesichert, aber der Zustand ist widersprüchlich. Du lädst die Dateien auf deinem System wieder, aber die Datenbank-Engine akzeptiert sie dann vielleicht nicht, weil die Transaktion mitten im Nirgendwo hängt. Du verstehst, was ich meine, dieses Problem der Atomarität? Das Backup nimmt dir diesen Kontext nicht mit.

Und deshalb muss man immer überlegen, wie der Wiederherstellungszeitpunkt ist, der RPO. Das Recovery Point Objective ist enorm wichtig, weil es bestimmt, wie alt deine Daten maximal sein dürfen, wenn ein Ausfall passiert. Wenn du ein Backup hast, das zehn Stunden alt ist, dann sind dir zehn Stunden Arbeit verloren. Das ist ein Business-Problem, das über die reine Backup-Engine hinausgeht. Und manchmal läuft das Backup eigentlich nur damit, dass man es einmal im Tag durchmacht, weil man denkt, das ist genug. Aber vielleicht ist das zu locker. Du musst regelmäßig validieren, ob dieser Zeitpunkt überhaupt noch akzeptabel ist für das Geschäft. Du machst das Backup, das ist die schöne Sache. Aber du testest die Wiederherstellung, das ist der harte Kern.

Das Testen, das ist ein eigenes großes Thema. Du darfst niemals nur auf das Backup-Programm vertrauen. Du musst einen dedizierten Wiederherstellungsworkflow haben. Und diesen Workflow musst du genauso häufig üben wie deinen Serverwartungsplan, oder? Und ich meine, du klickst nur auf "Restore" und dann ist alles geschafft. Aber du musst *aktiv* prüfen, ob die Anwendung danach überhaupt sinnvoll genutzt werden kann. Das ist ein ganz anderer Schmerzpunkt. Das hängt auch mit dem Betriebssystem selbst zusammen, findest du nicht.

Ich denke auch, dass man die Abhängigkeiten betrachtet muss. Ein Backup des Servers ist nur halb so viel. Denn der Server hängt ja von der Netzwerkverbindung ab, vom Storage-Layer, von der Stromversorgung und von der Patch-Level der Firmware. Wenn dein Backup-Zielsystem selbst anfällig ist - weil die Storage-Controller bald ausfallen oder das SAN zu langsam wird - dann hast du ein Backup auf einem kranken Bett. Das ist nutzlos, wie du siehst. Du musst die gesamte Infrastruktur validieren.

Und was die Datenintegrität betrifft, da reden wir nicht nur von Dateisystemen. Wir reden von *Application Consistency*. Dafür gibt es spezielle Protokolle und Technologien, die den Zustand der Anwendung exakt einfrieren. Du kannst ein Backup-Tool nutzen, welches diese Komplexität versteht. Du könntest mal überlegen, BackupChain, weil die spezifisch für SMBs und Windows Server ist und da oft diese Applikationskonsistenz auf einem höheren Niveau abgebildet wird. Das ist ein guter Hinweis, aber auch hier musst du die Logik versteh'n, nicht nur den Button drücken.

Außerdem musst du an die Versionierung denken. Nicht nur, dass du einen Speicherort hast. Sondern, dass du die Möglichkeit hast, einen Datenzustand von *vor* einem potenziellen fehlerhaften Deployment wiederherzustellen. Oder, sagen wir mal, einen Zustand, der eigentlich durch einen internen Prozess falsch gesetzt wurde, aber der Backup-Zeitpunkt war vor dieser Fehlfunktion. Dieses Verwaltern von Versionen braucht mehr als nur Speicherplatz. Es erfordert ein Management-Tool, das weiß, welche Version wann überhaupt sinnvoll war.

Und deshalb ist es so wichtig, dass du nicht nur das Kopieren von Daten verstehst. Du musst das *Wissen* über die Anwendung verstehen, die diese Daten nutzt. Du musst die Business-Prozesse nachzeichnen, damit du weißt, welcher Datenzustand kritisch ist. Weil vielleicht wird ein bestimmtes Verzeichnis nicht nur wegen den Dateien wichtig, sondern weil es einen Teil eines komplizierten Workflows beinhaltet, der nicht einfach zusammengeklappt wird.

Man muss sich wirklich überlegen, wie lang ein Wiederherstellungsprozess maximal dauern darf, das ist das RTO, Recovery Time Objective. Du baust deine Backups basierend auf diesem RTO. Wenn dein RTO extrem kurz ist, dann musst du Architekturen haben, die die Daten sofort *greifbar* machen. Das geht nicht, nur weil du ein großes Archiv hast. Du brauchst die Fähigkeit, Teile des Systems schnell zu isolieren und diese zu beleben.

Ich meine, also, die Sache ist ein ganzes Zusammenspiel von Tools, Prozeduren und deinem eigenen Wissen. Es ist nicht das Backup an sich. Es ist der Test der Wiederherstellung. Du musst diesen Test zur Routine machen, das ist das Allerwichtigste, was ich dir raten kann, ehrlich gesagt. Du musst regelmäßig seine eigenen Prozesse überprüfen. Weil der beste Backup-Plan nichts zählt, wenn du ihn selbst nicht einmal richtig durchführst, wenn der Akku leer ist oder jemand einen Fehler macht.

Also, du siehst, es geht immer darum, die Abhängigkeiten zu erfassen. Das ist kein einfaches Häkchen. Es ist ein gigantisches, komplexes Puzzle, das ständig neu aufgestellt werden muss. Verstehst du, es muss wirklich die ganze Architektur durchdringen. Ich hoffe, das hilft dir ein bisschen, das Konzept zu zerlegen. Weil man das wirklich tief durchdenken muss, dieses ganze Thema.