10.2 Datensicherung und Sicherungsmethoden

Ursachen für Datenverlust

Die prozentuale Verteilung von Datenverlustursachen aus alten Schulungsunterlagen ist heute nicht mehr belastbar. Geräte, Cloudnutzung, Bedrohungen und Erhebungsmethoden haben sich grundlegend verändert. Für ein Sicherungskonzept ist ohnehin wichtiger, alle relevanten Schadensklassen zu berücksichtigen, statt eine einzelne historische Statistik zu übernehmen.

Backup, Archiv, Image, Snapshot und Replikation

Was heute gesichert werden muss

Eigene Dokumente, Bilder und Datenbanken bleiben wichtig. Für eine zuverlässige Wiederherstellung reichen Nutzdateien allein jedoch häufig nicht aus. Moderne Systeme bestehen aus Konfigurationen, Identitäten, Secrets, Zertifikaten, Anwendungen, Abhängigkeiten und externen Diensten.

Installationspakete lassen sich nicht immer erneut aus dem Internet beziehen. Versionen können verschwinden, Repositories ändern sich und Lizenzen oder Herstellerportale sind im Notfall möglicherweise nicht erreichbar. Deshalb muss bewusst entschieden werden, welche Installationsmedien, Pakete, Container-Images, Quelltexte und Lizenzinformationen für den Wiederaufbau benötigt werden.

• Benutzer- und Unternehmensdaten einschließlich Datenbanken und Dateifreigaben
• Betriebssystem- und Anwendungskonfiguration, Gruppenrichtlinien und Verzeichnisdienste
• Virtuelle Maschinen, Containerdefinitionen und Infrastructure-as-Code-Dateien
• Zertifikate, Schlüssel und Secrets mit getrenntem, geschütztem Wiederherstellungsweg
• Netzwerk-, Firewall-, Switch-, Router- und Storage-Konfigurationen
• Quellcode, Builddefinitionen, Abhängigkeiten und benötigte Installationspakete
• Dokumentation, Notfallpläne, Kontakt- und Lizenzinformationen

Vollsicherung

Eine Vollsicherung übernimmt bei jedem Lauf alle für den Sicherungssatz ausgewählten Daten. Sie bildet einen eigenständigen Ausgangspunkt für die Wiederherstellung. Das bedeutet nicht zwingend, dass das Ziel jedes Mal alle Blöcke erneut physisch speichert: Deduplizierung und andere Repositoryfunktionen können identische Daten intern gemeinsam ablegen.

Inkrementelle Sicherung

Eine inkrementelle Sicherung übernimmt Änderungen seit der jeweils letzten erfolgreichen Sicherung - unabhängig davon, ob diese vollständig oder inkrementell war. Klassisch benötigt ein Restore die letzte Vollsicherung und alle danach erforderlichen Inkremente in der richtigen Reihenfolge.

Moderne Backupprodukte können eine synthetische Vollsicherung im Repository erzeugen oder einen gewünschten Stand direkt präsentieren. Intern bleiben trotzdem Abhängigkeiten zwischen Datenblöcken, Metadaten und Wiederherstellungspunkten bestehen. Ein beschädigtes Glied kann mehrere spätere Punkte betreffen.

Differenzielle Sicherung

Eine differenzielle Sicherung übernimmt bei jedem Lauf alle Änderungen seit der letzten Vollsicherung. Der erste Lauf ist meist klein; danach wächst die Datenmenge bis zur nächsten Vollsicherung. Für den klassischen Restore werden die letzte Vollsicherung und nur die gewünschte beziehungsweise jüngste passende differenzielle Sicherung benötigt.

Sicherungsverfahren und Restore-Ketten

Beispielhafter Sicherungsplan

Ein Zeitplan muss aus RPO, Datenmenge, Änderungsrate, Sicherungsfenster und gewünschter Restore-Zeit entstehen. Die folgende Woche ist daher ein Beispiel und keine allgemeine Vorgabe.

• Sohn: häufige kurzfristige Sicherungen, beispielsweise täglich.
• Vater: länger aufbewahrte Wochensicherungen.
• Großvater: ausgewählte Monats- oder Jahressicherungen.
• Das Generationenprinzip beschreibt Aufbewahrungsstufen. Mediennamen, Zeitpunkte und Anzahl müssen zum Unternehmen passen.

Wie Backupsoftware Änderungen erkennt

Das Windows-Archivattribut existiert weiterhin. Eine Anwendung kann FILE_ATTRIBUTE_ARCHIVE verwenden, um Dateien für Sicherung oder andere Verarbeitung zu markieren. Es ist jedoch kein verlässliches allgemeines Modell für moderne plattformübergreifende Backups.

Aktuelle Produkte verwenden je nach Quelle unter anderem Zeitstempel, Dateigröße, Dateisystemjournale, Änderungsblockverfolgung, Snapshots, Datenbankprotokolle, Objektversionen, APIs, Hashwerte oder eigene Kataloge. Nur das Änderungsdatum kann problematisch sein, etwa bei zurückgesetzter Uhrzeit, kopierten Metadaten oder nicht erkannten Anwendungsabhängigkeiten.

Konsistenz laufender Systeme

Eine gewöhnliche Dateikopie kann geöffnete oder sich gleichzeitig ändernde Daten in einem uneinheitlichen Zustand erfassen. Crash-konsistent bedeutet, dass der Datenstand ungefähr einem unerwarteten Systemausfall entspricht. Anwendungskonsistent bedeutet, dass die Anwendung Schreibpuffer und Transaktionen für den Sicherungszeitpunkt koordiniert.

Unter Windows koordiniert der Volume Shadow Copy Service, VSS, Backupanwendung, Writer und Snapshot-Provider. Unterstützte Anwendungen können Transaktionen abschließen, Protokolle wechseln und Schreibvorgänge kurz einfrieren. Andere Plattformen und Anwendungen besitzen eigene Snapshot-, Dump- oder Log-Backup-Verfahren. Ein Snapshot liefert dabei den konsistenten Zeitpunkt; die dauerhafte Kopie auf ein geschütztes Ziel bleibt eine getrennte Aufgabe.

• Dateiserver: geöffnete Dateien, Berechtigungen und Dateisystemmetadaten berücksichtigen.
• Datenbank: herstellerunterstütztes Backup, Transaktionslogs und Restore-Reihenfolge verwenden.
• Virtuelle Maschine: Hypervisor- und Gastintegration prüfen; ein VM-Snapshot allein ist kein Langzeitbackup.
• Verzeichnisdienst: Systemzustand, Replikation und autoritative beziehungsweise nicht autoritative Wiederherstellung beachten.

Validierung ist mehr als „Bit für Bit“

Nicht jedes Backupprogramm vergleicht nach der Sicherung automatisch jedes Bit mit der Quelle. Je nach Produkt werden Prüfsummen beim Lesen, Übertragen oder Speichern erzeugt, Datenblöcke stichprobenartig oder vollständig gelesen, Kataloge geprüft oder Hintergrund-Scrubs ausgeführt. Diese Funktionen müssen konfiguriert und überwacht werden.

Ein identischer Datenblock kann dennoch fachlich unbrauchbar sein, wenn bereits die Quelle inkonsistent war, Daten fehlten, der falsche Umfang gewählt wurde oder Schlüssel und Abhängigkeiten nicht verfügbar sind. Deshalb ergänzen sich technische Integritätsprüfung und praktischer Restore-Test.

Wiederherstellung vorbereiten und durchführen

Das Ablageformat beeinflusst die Wiederherstellung. Lose Dateien lassen sich einfach prüfen, proprietäre Container ermöglichen oft Deduplizierung, Verschlüsselung und Katalogfunktionen, benötigen aber kompatible Software. Offene Archivformate wie ZIP sind verbreitet, bilden jedoch nicht automatisch alle Dateisystemmetadaten oder anwendungskonsistenten Zustände ab.

Aktuelle Sicherungsmedien

Medienbetrieb und Aufbewahrung

• Sicherungen nicht dauerhaft mit denselben beschreibbaren Rechten wie das Produktivsystem erreichbar lassen.
• Transport und Lagerung gegen Verlust, Diebstahl, Feuchtigkeit, Temperatur, Magnetfelder und mechanische Schäden absichern.
• Medien beschriften oder inventarisieren, aber keine vertraulichen Inhalte offen auf dem Etikett nennen.
• Lebensdauer nicht nur nach Herstellerwert annehmen: Zustandskontrolle, Migration und rechtzeitigen Austausch planen.
• Verschlüsselungsschlüssel und Zugangsdaten getrennt, redundant und getestet wiederherstellbar halten.
• Aufbewahrungsfristen technisch erzwingen und nach Ablauf kontrolliert löschen beziehungsweise Medien sicher ausmustern.

Zusammenfassung

Vollsicherungen vereinfachen die Restore-Kette, inkrementelle Sicherungen reduzieren die tägliche Datenmenge und differenzielle Sicherungen bilden einen Mittelweg. Moderne Produkte können intern synthetische Vollsicherungen, Deduplizierung und Blocktracking verwenden; die logischen Abhängigkeiten der Wiederherstellung müssen trotzdem verstanden und getestet werden.

Ein Backup ist erst belastbar, wenn Umfang, Konsistenz, Integrität, Schutz und Wiederherstellung zusammen funktionieren. Historische Medien und das Archivbit bleiben für die Einordnung relevant, bestimmen aber kein modernes plattformübergreifendes Sicherungskonzept mehr.