# Backup Typen: Full, Incremental, Differential – Strategien für Enterprise Data Protection

TL;DR / Management Summary Die Wahl des Backup-Typs ist ein kritischer Kompromiss zwischen Speicherplatzbedarf (Storage Footprint), Backup-Dauer (RPO-Effizienz) und Wiederherstellungsgeschwindigkeit (RTO-Effizienz). Ein Full Backup bietet das beste RTO, ist aber am speicherintensivsten. Incremental Backups sparen massiv Speicher, erfordern aber lange Wiederherstellungsketten und erhöhen das RTO signifikant, da alle Inkremnte seit dem letzten Full verarbeitet werden müssen. Differential Backups bieten einen ausgewogenen Mittelweg, da sie immer nur das letzte Full Backup als Basis benötigen. Moderne Enterprise-Systeme nutzen oft Synthetische Full Backups und Block-Level Change Tracking (CBT), um die Nachteile traditioneller Methoden zu umgehen und das beste aus allen Welten zu vereinen.

# 1. Einführung & Architektur

Als Senior DevOps Engineers wissen wir: Backups sind einfach. Restores sind der Albtraum. Unsere Architektur muss die Wiederherstellung, nicht die Sicherung, optimieren.

# Warum brauchen wir das?

Die Notwendigkeit, zwischen Full, Incremental und Differential zu wählen, ergibt sich aus der fundamentalen Herausforderung des Datenwachstums. Bei einem Terabyte-Dataset, das täglich um 5% wächst, ist ein tägliches Full Backup ökonomisch und zeitlich nicht tragbar.

• Problemstellung aus der Praxis: Große Datasets (mehrere TB) in Umgebungen mit engem Backup-Fenster (z.B. 4 Stunden über Nacht). Die Netzwerk- und Speicherkapazität reicht nicht aus, um täglich die gesamte Datenmenge zu verschieben.
• Vergleich mit Alternativen: Moderne Lösungen (z.B. Veeam, Rubrik, Cohesity) oder Filesystem-Features (ZFS Snapshots/Send/Receive, Btrfs) abstrahieren diese traditionellen Typen oft durch den Einsatz von Changed Block Tracking (CBT), was die Notwendigkeit manueller Typ-Wahl minimiert, indem es effektiv nur noch Block-Level-Inkremte speichert und die Kette intern verwaltet.

# Architektur-Diagramm (Konzept der Kette)

Die Kernarchitektur dieser Backup-Typen liegt in der Verwaltung der Restore Chain Integrity und der zugehörigen Metadaten.

Restore Chain Complexity (Abhängigkeiten):

# Kernel-Sicht: Changed Block Tracking (CBT)

In modernen, blockbasierten Systemen (Hypervisoren, Storage-Arrays) wird die Identifizierung geänderter Daten nicht durch Dateisystem-Scans (was langsam ist), sondern durch das Block Layer oder den Hypervisor selbst durchgeführt.

1. Block Map Initialisierung: Beim ersten Full Backup wird eine Bitmap aller belegten Datenblöcke erstellt und im Metadaten-Speicher gesichert.
2. Tracking: Jeder Schreibvorgang auf den Host-Speicher (oder VMDK/VHD) markiert den entsprechenden Block in der Bitmap als “Dirty”.
3. Delta-Extraktion: Während eines Incremental/Differential Backups liest der Backup-Agent nur die als “Dirty” markierten Blöcke aus.

graph TD
    A[Datenquelle: Filesystem/VM Disk] --> B(Kernel Block Layer/Storage Driver)
    B --> C{CBT Filter Driver}
    C --> D[Bitmap des Dirty State]
    D -- Backup Lauf --> E(Backup Agent/Proxy)
    E --> F[Metadaten: Pointer zur Kette]
    F --> G[Zieldatenspeicher: Blobs / Deduplizierung Store]

# 2. Installation & Grundkonfiguration (Praxis)

Da dies keine Installation eines einzelnen Tools ist, konzentrieren wir uns auf die Definition der Backup-Logik in einer typischen Enterprise-Umgebung, basierend auf dem GFS-Prinzip (Grandfather-Father-Son).

# Voraussetzungen

1. Robustes Metadaten-Management: Das Backup-System muss atomar garantieren können, dass die Metadaten über die Kette (Wann wurde was gesichert? Wo liegt das Parent-Backup?) konsistent sind.
2. Change Tracking Fähigkeit: Idealerweise Block-Level (CBT); mindestens aber schnelles Dateisystem-Journal-Lesen oder effiziente Hash-Prüfungen (rsync --checksum).
3. Genügend Backup-Window: Die Dauer des Full Backups diktiert die maximale Frequenz von Fulls.

# Schritt-für-Schritt Setup (Definition der GFS-Policy)

Wir definieren eine Strategie, die das RTO optimiert, indem sie lange inkrementelle Ketten vermeidet.

# Beispiel: Konzeptionelle Policy-Definition (Bacula/Veeam/Borg-Logik)

# 1. DEFINITION: Full Backup (Basis für die Kette)
# Ziel: Garantiertes RTO-Szenario
# Frequenz: Monatlich, am letzten Sonntag (für Langzeit-Retention)
POLICY_FULL_MONTHLY {
    RETENTION = 12 months ; # G (Grandfather)
    TYPE = FULL ;
    TRIGGER = "01:00 sun last month" ;
    CATALOG_REFRESH = Yes ; # Metadaten-Prüfung und Re-Baseline
}

# 2. DEFINITION: Differential Backup (RTO/RPO Kompromiss)
# Ziel: Minimierung der Kette auf maximal 2 Dateien
# Frequenz: Wöchentlich, nach dem letzten inkrementellen Backup
POLICY_DIFFERENTIAL_WEEKLY {
    RETENTION = 4 weeks ; # F (Father)
    TYPE = DIFFERENTIAL ;
    PARENT = POLICY_FULL_MONTHLY ; # Wichtig: Basis ist das letzte Full
    TRIGGER = "01:00 sun" ;
}

# 3. DEFINITION: Incremental Backup (Tägliches RPO)
# Ziel: Geringster Storage-Verbrauch, feinstes RPO
# Frequenz: Täglich
POLICY_INCREMENTAL_DAILY {
    RETENTION = 7 days ; # S (Son)
    TYPE = INCREMENTAL ;
    PARENT = LATEST_SUCCESSFUL_BACKUP ; # Wichtig: Basis ist das vorherige Inc/Diff
    TRIGGER = "22:00 mon-sat" ;
    # ACHTUNG: Die Integrität dieser Kette ist nur so gut wie das älteste Glied.
}

# 3. Deep Dive: Konfiguration für Profis

Hier beleuchten wir die kritischen Unterscheidungsmerkmale, die im Betrieb den Unterschied zwischen einem erfolgreichen Restore und einer Katastrophe ausmachen.

# Performance Tuning: Synthetische Fulls

Die größte Herausforderung bei inkrementellen Strategien ist die Notwendigkeit, periodisch ein neues Full Backup zu erstellen (Seeding), was viel Zeit und I/O kostet.

Synthetisches Full Backup (Synthetic Full): Anstatt die Daten erneut von der Quelle zu lesen, liest der Backup-Server das ursprüngliche Full Backup und wendet alle nachfolgenden Inkremte/Differentiale auf dem Backup-Speicher selbst an, um eine neue, unabhängige Full-Datei zu erzeugen.

• Vorteil: Eliminiert den I/O-Druck auf dem Quellsystem, reduziert das Backup-Fenster drastisch.
• Achtung: Dies verschiebt die Last auf den Backup-Speicher (Storage Performance und CPU des Backup-Proxys/Mediaservers sind kritisch).

# Differential vs. Incremental: Die Architektonische Entscheidung

Die Entscheidung zwischen Incremental und Differential ist primär eine Abwägung von RTO-Risiko vs. Storage-Kosten.

Senior Admin Empfehlung: Wenn Ihr Backup-Speicher es zulässt, nutzen Sie primär Differentiale anstelle von Inkremten. Die Komplexität und das erhöhte Risiko eines fehlgeschlagenen RTO durch eine gebrochene Kette bei reinen Inkremten rechtfertigt die zusätzlichen Speicherkosten fast immer.

# Hardening & Security: Immutability

Da die Integrität der gesamten Kette von der Unveränderlichkeit des ersten Full Backups abhängt, ist Immutability (Unveränderlichkeit) auf dem Zielspeicher (S3 Object Lock, WORM-Storage) unerlässlich, um Ransomware-Angriffe zu mitigieren, die darauf abzielen, die Restore Chain zu zerstören.

# 4. Day-2 Operations: Wartung & Alltag

Nach der Implementierung ist die Wartung der Restore Chain der kritischste Teil.

# Typische Tasks

# A. Chain Consolidation (Kettenzusammenführung)

Wenn eine inkrementelle Kette zu lang wird (z.B. 14 Tage), steigt das RTO-Risiko. Die Kette muss konsolidiert werden.

• Task: Alte, aufeinanderfolgende Inkremte in ein Differential oder ein neues Synthetisches Full umwandeln.
• Offline vs. Online: Moderne Backup-Systeme führen dies online und automatisch durch (z.B. Merge-on-Save). Bei manuellen Lösungen muss die Konsolidierung nach dem Backup-Fenster durchgeführt werden, um I/O-Konflikte zu vermeiden.

# B. Retention Policy Enforcement (Housekeeping)

Das Entfernen alter Backups muss sauber erfolgen, um die Kettenintegrität nicht zu gefährden. Ein Full Backup darf nur gelöscht werden, wenn keine Incremental oder Differential Backups mehr darauf verweisen.

• Gefahr: Löschen des Parent-Backups bricht alle Child-Backups.
• Profi-Methode: Nutzen Sie eine Garbage Collection (GC)-Funktion des Backup-Tools, die referenzierte Objekte automatisch erkennt und schützt.

# Automatisierung (Ansible/Terraform)

Infrastructure-as-Code (IaC) definiert nicht die Backup-Befehle, sondern die Policy und das Zielspeicher-Repository.

# Ansible Beispiel: Definition einer Sicherungs-Policy (Konzeptionell)
- name: Configure Enterprise Backup Job Definition
  hosts: backup_manager
  vars:
    client_name: web_prod_db01
    full_retention_days: 365
    diff_retention_weeks: 4
    inc_retention_days: 7
  tasks:
    - name: Ensure Backup Policy for PROD DB is defined
      backup_tool.policy:
        name: "{{ client_name }}_policy"
        source: "{{ client_name }}"
        full_schedule: "monthly, last sunday @ 01:00"
        differential_schedule: "weekly, sunday @ 03:00"
        incremental_schedule: "daily, mon-sat @ 22:00"
        full_retention: "{{ full_retention_days }} days"
        diff_retention: "{{ diff_retention_weeks }} weeks"
        inc_retention: "{{ inc_retention_days }} days"
        synthetic_full_enabled: true # Kritisch für RTO-Optimierung

# 5. Troubleshooting & “War Stories”

Die Katastrophen im Backup-Bereich sind fast immer Wiederherstellungskatastrophen.

# Top 3 Fehlerbilder

# 1. Symptom A: “Backup läuft schnell, Restore ist extrem langsam.”

• Fehlermeldung: Keine spezifische Fehlermeldung, aber RTO wird um Faktor 10 überschritten.
• Ursache: Übermäßig lange inkrementelle Kette (z.B. 40 Inkremte seit dem letzten Full). Beim Restore muss der Backup-Server alle 40 Dateien in der richtigen Reihenfolge lesen, entschlüsseln, deduplizieren und zusammenfügen.
• Lösung: Sofortige Erstellung eines neuen Full Backups (oder Synthetisches Full) und Anpassung der Policy, um die Kette auf maximal 7 Tage zu begrenzen.

# 2. Symptom B: “Metadaten-Konsistenzprüfung schlägt fehl.”

• Analyse: Logs zeigen Error: Parent object X not found. oder CRC Checksum mismatch.
• Ursache: Das Backup-System versucht, ein Inkremt zu validieren, aber die referenzierte Parent-Datei (das vorherige Backup) ist entweder korrupt, wurde manuell gelöscht oder die Metadaten-Datenbank zeigt fälschlicherweise darauf.
• Lösung: Isolierung der Kette. Alle nachfolgenden Backups, die auf dieses korrupte Glied aufbauen, sind nicht mehr wiederherstellbar. Man muss die Kette an dieser Stelle kappen und mit einem neuen Full Backup (Re-Seeding) beginnen.

# 3. Symptom C: Hohe Fehlerrate nach Retention-Clean-Up.

• Symptom: Unmittelbar nach der automatischen Löschung alter Backups (Garbage Collection) schlagen nachfolgende Inkremte fehl.
• Ursache: Fehlerhafte Logik im Backup-Tool, das fälschlicherweise ein benötigtes Parent-Backup gelöscht hat, weil die Metadaten-Referenz inkonsistent waren.
• Lösung: Manuelle Überprüfung der Metadaten und Deaktivierung der automatischen GC, bis die Referenzierung geprüft ist.

# Recovery Szenarien: Der Entscheidungsprozess

Der RTO hängt direkt von der Backup-Strategie ab.

graph TD
    A[Datenverlust erkannt] --> B{Letztes Full Backup vorhanden?};

    B -- Ja --> C[Wiederherstellung: Nur Full nötig];
    C --> RTO1[RTO: Niedrig];

    B -- Nein (Seit Full Inc/Diff erstellt) --> D{Welcher Typ ist der Neueste?};

    D -- Differential --> E[Wiederherstellung: Full + Letztes Diff];
    E --> RTO2[RTO: Mittel];

    D -- Incremental --> F[Wiederherstellung: Full + Inc1 + ... + IncN];
    F --> RTO3[RTO: Hoch - Kritisch];

    F -- Kette gebrochen? --> G[Neues Full Backup notwendig];
    G --> H[RTO: Nicht erfüllbar!];

Anekdote (War Story): Wir hatten einmal in einer Umgebung mit über 100 VMs eine rein inkrementelle Strategie mit einem Full alle 90 Tage. Als die zentrale Backup-Storage-Appliance (die für die Deduplizierung zuständig war) ausfiel und ersetzt werden musste, stellten wir fest, dass das ursprüngliche Full Backup auf dem Archiv-Speicher fehlerhaft war. Resultat: 90 Tage an Inkremten waren wertlos. Die Lektion: Testen Sie periodisch die Wiederherstellbarkeit des Full-Backups, da es die Basis Ihrer gesamten DR-Strategie ist.

# 6. Monitoring & Alerting

Backups müssen als geschäftskritischer Service mit klaren KPIs überwacht werden.

# Metriken: Key Performance Indicators (KPIs)

# Alerting-Regeln

1. Critical Alert: Failed Job: Pager-Alarm, wenn ein Job fehlschlägt, besonders ein Full Backup.
2. Warning Alert: High Change Rate: Alarm, wenn die Change Rate signifikant höher ist als der gleitende Durchschnitt (Potenzieller Ransomware-Angriff oder fehlerhafte Konfiguration, die zu einem unbeabsichtigten Full führt).
3. Warning Alert: Extended Chain Depth: Pager-Alarm, wenn die Tiefe der Wiederherstellungskette den konfigurierten Schwellenwert (z.B. 7) überschreitet. Dies signalisiert ein erhöhtes RTO-Risiko.

Tools: Prometheus Exporter (z.B. für Backup-Lösung spezifische Metriken), Checkmk/Nagios Plugins, die den Status direkt aus der Backup-Software-API ziehen.

# 7. Fazit & Empfehlung

Die traditionellen Backup-Typen sind die Grundlage, aber moderne Infrastruktur muss sie durch intelligente Automatisierung ersetzen.

Wann würde ich es nicht einsetzen? Manuelle Implementierungen von Full/Incremental/Differential sind heute bei großen Datasets (TBs) obsolet. Wenn Sie eine moderne Infrastruktur (Virtualisierung, Cloud) betreiben, setzen Sie auf Lösungen, die Synthetische Fulls und Changed Block Tracking (CBT) nativ unterstützen. Dies eliminiert die RTO-Nachteile langer Inkremeten-Ketten.

Ausblick: Die Zukunft gehört der Continuous Data Protection (CDP) und den Immutable Backups. CDP ermöglicht ein RPO nahe Null, da jeder Schreibvorgang sofort gesichert wird. Kombiniert mit Deduplizierung und Speicherung auf unveränderlichem Storage (Immutable), bietet dies die höchste Resilienz gegen operative Fehler und Cyber-Angriffe.

# Anhang: Cheatsheet

# Referenzen

• Veeam Best Practices Guide – Ausgezeichnete Dokumentation zur Implementierung synthetischer Full Backups und CBT.
• ZFS Documentation – Deep Dive in zfs send/receive (Implementierung von Block-Level Incremental Backups auf Dateisystem-Ebene).
• DR Standards (ISO 27031) – Rahmenwerk für RPO und RTO Definitionen.
• Open Source Backup Tools Manpages – (z.B. borg backup für Deduplizierung und Metadaten-Handling).