Backup-Strategien
Wer Daten sichert, braucht einen Plan: welche Daten, wie oft, wohin, wie lange aufbewahren und wie schnell sie im Ernstfall wieder verfügbar sein müssen. Dieser Plan heißt Backup-Strategie. Sie verbindet technische Sicherungsverfahren mit betrieblichen Anforderungen an Verfügbarkeit und Wiederherstellbarkeit.
Was eine Backup-Strategie leistet
Datenverlust entsteht durch Hardwaredefekte, Softwarefehler, menschliche Fehlbedienung, Cyberangriffe oder Naturereignisse. Eine Backup-Strategie legt fest, wie ein Unternehmen oder eine Einzelperson auf diese Risiken reagiert. Sie beantwortet vier Kernfragen: Welche Daten werden gesichert? In welchen Intervallen? Auf welche Speichermedien? Und wie lange werden die Sicherungen aufbewahrt?
Beispiel: Ein Onlineshop sichert seine Produktdatenbank stündlich, die Bestellhistorie täglich und den statischen Content wöchentlich. Die Intervalle richten sich nach der Änderungsfrequenz der jeweiligen Daten.
Ohne Strategie entstehen typische Probleme: Sicherungen fehlen für kritische Systeme, Restore-Tests finden nie statt, veraltete Bänder belegen Lagerplatz ohne Nutzen, und im Ernstfall dauert die Wiederherstellung Tage statt Stunden.
Beispiel: Ein Unternehmen sichert zwar den Datenbankserver, vergisst aber die Konfigurationsdateien der Applikationsserver. Nach einem Ausfall stehen die Rohdaten bereit, doch die Anwendung lässt sich nicht starten, weil die Konfiguration fehlt.
Vollsicherung, inkrementell, differenziell
Die drei Grundtypen der Datensicherung unterscheiden sich darin, welche Daten bei jedem Sicherungslauf kopiert werden.
Vollsicherung
Eine Vollsicherung kopiert sämtliche ausgewählten Daten unabhängig davon, ob sie sich seit dem letzten Backup verändert haben. Der Vorteil: Die Wiederherstellung erfordert nur ein einziges Backup-Set. Der Nachteil: Jeder Lauf benötigt den vollen Speicherplatz und die volle Übertragungszeit.
Beispiel: Ein Datenbankserver mit 500 GB Nutzdaten erzeugt bei täglicher Vollsicherung 3,5 TB Backup-Daten pro Woche. Bei einer Änderungsrate von nur 2 Prozent pro Tag werden dabei 98 Prozent redundante Daten kopiert.
Inkrementelle Sicherung
Eine inkrementelle Sicherung erfasst nur die Daten, die sich seit der letzten Sicherung beliebigen Typs geändert haben. Das reduziert Speicherbedarf und Sicherungsdauer erheblich. Die Wiederherstellung erfordert allerdings die letzte Vollsicherung plus alle nachfolgenden Inkremente in korrekter Reihenfolge.
Beispiel: Montags läuft eine Vollsicherung. Dienstags ändern sich 10 GB. Das Inkrement vom Dienstag umfasst diese 10 GB. Mittwochs ändern sich weitere 8 GB. Das Inkrement umfasst nur diese 8 GB. Für einen Restore auf Mittwoch werden die Vollsicherung vom Montag, das Inkrement vom Dienstag und das Inkrement vom Mittwoch benötigt.
Differenzielle Sicherung
Eine differenzielle Sicherung erfasst alle Daten, die sich seit der letzten Vollsicherung geändert haben. Das Volumen wächst im Lauf der Woche, aber für die Wiederherstellung genügt die letzte Vollsicherung plus das letzte Differenzial.
Beispiel: Bei derselben Ausgangslage umfasst das Differenzial am Mittwoch bereits 18 GB (alle Änderungen seit Montag). Am Freitag sind es möglicherweise 35 GB. Der Restore braucht aber nur zwei Dateien: Vollsicherung plus Freitags-Differenzial.
Fachliche Einordnung: Die Wahl zwischen inkrementell und differenziell ist ein klassischer Kompromiss zwischen Sicherungsaufwand und Wiederherstellungsaufwand. Inkrementelle Sicherungen optimieren den täglichen Betrieb (weniger Speicher, kürzere Fenster), differenzielle Sicherungen optimieren die Wiederherstellungszeit (weniger Abhängigkeiten in der Restore-Kette). In der Praxis kombinieren die meisten Umgebungen beide Ansätze.
Wiederherstellungsziele: RPO und RTO
Zwei Kennzahlen bestimmen, wie eine Backup-Strategie dimensioniert wird.
Die maximal tolerierbare Datenverlustspanne gibt an, wie viele Minuten oder Stunden an Datenänderungen im Ernstfall verloren gehen dürfen. In der Fachsprache heißt dieser Wert Recovery Point Objective (RPO). Ein RPO von vier Stunden bedeutet: Die letzte verfügbare Sicherung darf höchstens vier Stunden alt sein.
Die maximal tolerierbare Ausfallzeit gibt an, wie schnell ein System nach einem Ausfall wieder betriebsbereit sein muss. Dieser Wert heißt Recovery Time Objective (RTO). Ein RTO von einer Stunde bedeutet: Innerhalb von 60 Minuten muss das System wiederhergestellt und funktionsfähig sein.
Beispiel: Ein Zahlungsdienstleister benötigt ein RPO von 5 Minuten und ein RTO von 15 Minuten. Das erfordert kontinuierliche Datenbankreplikation, vorbereitete Standby-Systeme und automatisierte Failover-Mechanismen. Einfache nächtliche Bandsicherungen würden hier nicht ausreichen.
Beispiel: Ein internes Wiki mit statischen Dokumentationen verträgt ein RPO von 24 Stunden und ein RTO von 8 Stunden. Eine tägliche Vollsicherung auf einen Netzwerkspeicher genügt.
RPO und RTO müssen nicht für alle Systeme gleich sein. Eine sinnvolle Strategie klassifiziert Systeme nach Kritikalität und weist jedem System eigene Zielwerte zu.
Die 3-2-1-Regel und ihre Erweiterungen
Eine weit verbreitete Grundregel der Datensicherung fordert: drei Kopien der Daten, auf zwei verschiedenen Medientypen, davon eine Kopie an einem externen Standort. Diese Regel stammt aus dem Bereich der professionellen Fotografie und hat sich als Mindeststandard in der IT-Branche etabliert.
Beispiel: Ein Unternehmen hält seine Produktivdaten auf dem Datenbankserver (Kopie 1), sichert täglich auf ein lokales NAS-System (Kopie 2, anderer Medientyp) und repliziert wöchentlich in einen geografisch entfernten Cloud-Speicher (Kopie 3, externer Standort).
Die Erweiterung auf 3-2-1-1-0 ergänzt zwei Aspekte: eine der Kopien muss offline oder unverfälschbar (immutable) gespeichert sein, und die Sicherungen müssen null Fehler bei der Wiederherstellungsprüfung aufweisen. Diese Erweiterung reagiert auf die Bedrohung durch Verschlüsselungstrojaner, die auch erreichbare Backup-Systeme kompromittieren können.
Beispiel: Ein Krankenhaus speichert Patientendaten gemäß 3-2-1-1-0: Produktivsystem (1), tagesaktuelles Replikat auf getrenntem Storage (2), wöchentliche Sicherung in einem externen Rechenzentrum (3), monatliche Kopie auf WORM-Medien (Write Once Read Many) im Tresor (1 offline/immutable), und automatisierte Restore-Tests jede Nacht mit Protokollierung (0 Fehler).
Rotationsverfahren und Aufbewahrungsfristen
Backup-Medien oder -Datensätze müssen irgendwann überschrieben oder gelöscht werden, weil Speicherplatz endlich ist. Rotationsverfahren regeln, welche Sicherungen wie lange aufbewahrt werden.
Das Großvater-Vater-Sohn-Schema (GFS) ist das verbreitetste Verfahren. Tägliche Sicherungen (Sohn) werden eine Woche aufbewahrt, wöchentliche Sicherungen (Vater) einen Monat, monatliche Sicherungen (Großvater) ein Jahr oder länger.
Beispiel: Bei GFS mit Tages-, Wochen- und Monatssicherungen hält ein Unternehmen zu jedem Zeitpunkt 7 Tagessicherungen, 4 Wochensicherungen und 12 Monatssicherungen vor. Das ergibt 23 Sicherungssätze, die den Zustand der letzten 12 Monate in abnehmender Granularität abdecken.
Aufbewahrungsfristen ergeben sich aus betrieblichen Anforderungen und gesetzlichen Vorgaben. In Deutschland schreiben Handelsrecht und Steuerrecht Aufbewahrungsfristen von sechs bis zehn Jahren für bestimmte Geschäftsdaten vor. Branchenregulierungen wie MaRisk im Bankensektor oder die DSGVO stellen eigene Anforderungen.
Beispiel: Ein Handelsunternehmen muss Buchungsbelege zehn Jahre aufbewahren. Die Backup-Strategie muss sicherstellen, dass Jahreszwischensicherungen der Finanzdatenbank mindestens zehn Jahre lesbar und wiederherstellbar bleiben. Das erfordert Planung bezüglich Medienalterung und Formatkompatibilität.
Fachliche Einordnung: GFS-Schemata liefern eine gute Balance zwischen Speicherbedarf und Wiederherstellungsoptionen. Bei modernen Backup-Systemen mit Deduplizierung und Snapshot-Technologie verliert das klassische Medienwechsel-Konzept an Bedeutung, aber das Prinzip abgestufter Aufbewahrungszeiträume bleibt gültig.
Speicherziele und Medientypen
Die Wahl des Speicherziels beeinflusst Geschwindigkeit, Kosten und Verfügbarkeit der Sicherungen.
Lokaler Festplattenspeicher
Dedizierte Backup-Server oder NAS-Systeme im selben Rechenzentrum bieten hohe Geschwindigkeit bei Sicherung und Wiederherstellung. Sie schützen gegen Ausfall einzelner Server, nicht aber gegen Standortausfälle (Feuer, Überschwemmung, Einbruch).
Bandspeicher
LTO-Bänder (Linear Tape-Open) bieten hohe Kapazität zu niedrigen Kosten pro Gigabyte. Aktuelle LTO-9-Bänder fassen 18 TB nativ. Bänder eignen sich besonders für Langzeitarchivierung und Air-Gap-Sicherungen, weil sie offline gelagert werden können.
Beispiel: Ein Medienunternehmen archiviert Rohmaterial auf LTO-Bändern. 500 TB Videodaten passen auf rund 28 Bänder. Die Bänder lagern in einem klimatisierten Tresor außerhalb des Produktionsstandorts. Die Kosten pro Gigabyte liegen bei einem Bruchteil dessen, was Cloud-Speicher kostet.
Cloud-Speicher
Cloud-basierte Backup-Ziele bieten geografische Redundanz ohne eigene Infrastruktur. Die Kosten skalieren mit dem Volumen. Für große Datenmengen können die laufenden Kosten und die Wiederherstellungsgebühren erheblich sein.
Beispiel: Bei einem Cloud-Anbieter kostet kalter Archivspeicher etwa 1 Euro pro Terabyte und Monat. Für 100 TB Archivdaten fallen 1.200 Euro pro Jahr an. Allerdings berechnet der Anbieter zusätzlich Abrufgebühren: Ein vollständiger Restore von 100 TB kann mehrere Tausend Euro kosten und Tage dauern.
Restore-Tests und Verifizierung
Eine Sicherung, die sich nicht wiederherstellen lässt, hat keinen Wert. Regelmäßige Restore-Tests sind deshalb ein fester Bestandteil jeder Backup-Strategie.
Beispiel: Ein IT-Team stellt einmal pro Quartal den Stand einer zufällig ausgewählten Datenbank auf einem Testsystem wieder her. Dabei wird gemessen: Dauer des Restores, Integrität der Daten (Checksummenvergleich), Funktionsfähigkeit der Anwendung auf den wiederhergestellten Daten. Die Ergebnisse werden protokolliert.
Automatisierte Verifizierung prüft nach jedem Backup-Lauf die Integrität der erzeugten Sicherung. Methoden dafür sind Checksummenvergleiche, Mounten und Dateisystemprüfung, oder probeweiser Start einer virtuellen Maschine aus dem Backup-Image.
Beispiel: Ein Backup-System erstellt nach jeder Sicherung einer virtuellen Maschine automatisch einen Snapshot, startet die VM in einer isolierten Sandbox, prüft ob das Betriebssystem bootet und die Anwendung antwortet, und löscht die Test-VM wieder. Dieser Vorgang dauert wenige Minuten und liefert einen verlässlichen Nachweis der Wiederherstellbarkeit.
Schutz gegen Ransomware und gezielte Angriffe
Moderne Angriffsszenarien zielen gezielt auf Backup-Infrastruktur ab. Verschlüsselungstrojaner suchen aktiv nach erreichbaren Backup-Freigaben und verschlüsseln diese mit. Gezielte Angreifer kompromittieren zuerst die Backup-Verwaltungssoftware, bevor sie den eigentlichen Angriff starten.
Beispiel: Ein Ransomware-Angriff verschlüsselt nicht nur die Produktivserver, sondern auch die per SMB-Freigabe erreichbaren Backup-Dateien auf dem NAS. Das Unternehmen hat zwar Backups erstellt, kann aber keines davon verwenden. Nur die offline gelagerten Monatssicherungen auf LTO-Band sind unbetroffen.
Schutzmechanismen gegen solche Szenarien umfassen: Air-Gap-Sicherungen (physisch getrennte Medien), Immutable Storage (Speicher, der für einen definierten Zeitraum nicht verändert oder gelöscht werden kann), Multi-Faktor-Authentifizierung für Backup-Administrative und getrennte Netzwerksegmente für die Backup-Infrastruktur.
Fachliche Einordnung: Die National Institute of Standards and Technology (NIST) Cybersecurity Framework empfiehlt explizit offline Backups als Teil der Recovery-Strategie (PR.IP-4). In der Praxis zeigt sich, dass Organisationen mit getesteten Offline-Backups deutlich schneller von Ransomware-Vorfällen genesen als solche, die ausschließlich auf online erreichbare Sicherungen setzen.
Grenzen und typische Fehler
Backup-Strategien sind kein Allheilmittel. Einige Einschränkungen und häufige Fehler:
Backup ist kein Archiv. Sicherungen dienen der Wiederherstellung nach Datenverlust, nicht der Langzeitaufbewahrung für Compliance-Zwecke. Archivierungslösungen haben andere Anforderungen an Zugriff, Indexierung und Beweiskraft.
Backup schützt nicht gegen alle Datenkorruption. Wenn fehlerhafte Daten unbemerkt in die Produktivdatenbank gelangen, werden sie im nächsten Backup mit gesichert. Erst nach Erkennung des Fehlers wird klar, dass ein Restore auf einen Zeitpunkt vor der Korruption nötig ist. Ohne ausreichend lange Aufbewahrungskette fehlt dieser Wiederherstellungspunkt.
Beispiel: Ein fehlerhaftes Skript überschreibt über drei Wochen hinweg schrittweise Kundendaten mit falschen Werten. Da die Sicherungen nur 14 Tage zurückreichen, enthält keine Sicherung mehr den korrekten Datenstand. Der Fehler ist irreversibel.
Backup-Fenster und Bandbreite begrenzen die Sicherungsfrequenz. Große Datenmengen lassen sich nicht beliebig oft vollständig sichern, besonders wenn das Produktivsystem während der Sicherung weiterarbeiten muss.
Kosten steigen nicht linear. Halbierung des RPO verdoppelt nicht nur den Speicherbedarf, sondern erfordert häufig eine komplett andere Architektur (etwa kontinuierliche Replikation statt periodischer Sicherung).