---
title: "Incremental Forever Incremental Backup (IFI) – Architektur, Tuning und Enterprise-Strategien"
articleId: 401
tags: ["backup", "storage", "disaster-recovery", "deep-dive", "data-protection"]
summary: "Der 'Incremental Forever Incremental' (IFI) Ansatz ist die moderne Backbone-Strategie für Enterprise-Datensicherung. Wir analysieren die Architektur, die Notwendigkeit von Change Block Tracking (CBT) und detaillierte Tuning-Parameter, um aggressive RPO-Ziele bei minimalem Speicherverbrauch zu erreichen."
status: published
author: "SysAdmin Team"
---

# Incremental Forever Incremental – Optimierung der Backup-Kette

> **TL;DR / Management Summary**
> IFI (Incremental Forever Incremental) ist eine Backup-Strategie, bei der nach einem initialen Full Backup nur noch inkrementelle Änderungen (Block-Level) gesichert werden. Die Verwaltung der Wiederherstellungspunkte erfolgt durch die Backup-Software mittels Katalogisierung und synthetischer Full-Backups, ohne dass jemals wieder die vollständigen Daten vom Quellsystem übertragen werden müssen. Setzen Sie IFI für Umgebungen mit hohen Datenvolumen (> 50 TB), strengen RPOs (< 4 Stunden) und knappen Backup-Fenstern ein. Der Hauptvorteil ist die massive Reduzierung des Netzwerkverkehrs und der Speicherkapazität durch effektive Deduplizierung.

---

## 1. Einführung & Architektur

Die traditionelle GFS (Grandfather-Father-Son) Strategie mit periodischen, zeitaufwändigen Full Backups skaliert nicht mehr in modernen Virtualisierungs- und Big-Data-Umgebungen. IFI löst dieses Problem, indem es die Komplexität der Full-Backup-Generierung vom Quellsystem auf das Ziel-Repository verlagert.

### Warum brauchen wir das?

*   **Problemstellung aus der Praxis:** Voll-Backups sind E/A-intensiv für die Quellsysteme, belasten das Netzwerk stark und sind bei Petabyte-Größen nicht mehr im 24-Stunden-Fenster durchführbar. Ein Wochen-Full kann das RPO (Recovery Point Objective) unnötig verlängern.
*   **Vergleich mit Alternativen:**
    *   **Standard Incremental:** Schnelle Backups, aber die Wiederherstellung ist langsam, da jeder Punkt in der Kette verarbeitet werden muss.
    *   **Differential:** Reduziert die Wiederherstellungskomplexität, aber die Backup-Größe wächst kontinuierlich bis zum nächsten Full.
    *   **IFI:** Schnelle Backups und schnelle Wiederherstellung (da der Wiederherstellungspunkt synthetisch als Full vorliegt), optimiert für Speichereffizienz durch Deduplizierung.

### Architektur-Diagramm (Kernel- und Stack-Sicht)

Die Effizienz von IFI steht und fällt mit dem **Change Block Tracking (CBT)**, der kritischen Komponente, die auf dem Quellsystem läuft.

```mermaid
graph TD
    subgraph Quellsystem (Produktion)
        A[Applikation/Filesystem] --> B(VSS/Filesystem Filter Treiber);
        B --> C{Change Block Tracking (CBT)};
        C --> D[Backup Agent/Proxy];
    end

    subgraph Infrastruktur (Transport/Repository)
        D --> E[WAN Optimization/Compression];
        E --> F[Backup Repository];
        F --> G(Deduplizierungs-Index);
        F --> H(Katalog-Datenbank);
    end

    subgraph IFI Logik (Software-Defined)
        H --> I{Restore Request};
        G & I --> J[Synthetischer Full Restore-Punkt];
        J --> K(Restore Target);
    end

    style C fill:#f9f,stroke:#333,stroke-width:2px
    style J fill:#ccf,stroke:#333,stroke-width:2px

    note right of C: Kernel/Hypervisor API Hook (z.B. VMware VADP, Windows VSS, Linux Device Mapper Hooks)
    note right of F: Skalierbarer Object Storage (S3/Swift) oder Scale-out NAS

# Kernel-Sicht (CBT)

Auf Linux-Systemen wird CBT oft über den Device Mapper (DM) oder dedizierte Kernel-Module realisiert. Der Backup-Agent fragt nicht das gesamte Dateisystem ab, sondern liest nur die Liste der geänderten Blöcke, die DM bereitstellt. Dies reduziert die I/O-Last auf den Metadaten des Filesystems drastisch. Im Hypervisor-Kontext (z.B. KVM/QEMU) wird der Snapshot-Mechanismus des Hypervisors selbst genutzt, um die geänderten Blöcke der virtuellen Disk zu erfassen.

# 2. Installation & Grundkonfiguration (Praxis)

Wir betrachten die Konfiguration aus der Perspektive des Backup-Infrastruktur-Managers, nicht eines spezifischen Vendor-Tools.

# Voraussetzungen

1. Stabile CBT-Integration: Vergewissern Sie sich, dass der Backup-Agent die dedizierten APIs (z.B. libvirt Hooks, Windows VSS Writer, oder Kernel CBT Module) korrekt nutzt und nicht auf das langsamere File-Scanning (z.B. find oder rsync --checksum) zurückfällt.
2. Repository-Performance: Das Ziel-Repository muss hohe Random-Read-I/O-Leistung bieten, da Synthetic Fulls und Wiederherstellungen stark von der schnellen Abfrage des Deduplizierungs-Indexes abhängen. Eine SSD-basierte Metadaten-Schicht ist obligatorisch.
3. Netzwerklatenz: Niedrige Latenz zwischen Backup-Proxy und Repository ist kritisch für Inline-Deduplizierungsprozesse.

# Schritt-für-Schritt Setup (Der “Happy Path”)

Der Happy Path bei IFI ist die korrekte Definition des ersten Full Backups (Seeding) und der Konsistenzprüfungen.

# A. Initial Seeding und Policy-Definition

# 1. Quell-Validierung (Verifizierung der CBT-Fähigkeit)
# Beispiel: Prüfen, ob der Quell-Volume-Treiber die Block-Tracking-API freigibt.
# Bei Linux kann dies durch das Anlegen eines dm-snapshot-Overlay getestet werden.
CHECK_CBT_STATUS=$(backup_tool api query --source_id vm_prod_db --feature cbt)

if [ "$CHECK_CBT_STATUS" != "READY" ]; then
    echo "FEHLER: CBT ist nicht aktiviert oder nicht stabil. Korrigieren Sie die Kernel-Hooks/Hypervisor-Integration." 1>&2
    exit 1
fi

# 2. Definiere die IFI Policy
# Parameter, die oft unterschätzt werden:
# --block-size: Wichtiger Trade-off. 4K-8K für maximale Deduplizierung (Ideal für VMs). 64K-128K für maximale Durchsatz-Performance (Ideal für große Files).
# --cbt-reset-threshold: Wie viele inkrementelle Backups, bevor wir eine forcierte Validierung (Synthetisch oder Real) durchführen, um die Kette zu verkürzen. (Empfehlung: 30-90 Tage).

backup_tool policy create IFI_DB_POLICY \
    --type incremental_forever \
    --retention_points 90 \
    --block-size 8K \
    --dedupe_mode inline \
    --cbt-reset-threshold 60d

# B. Repository Hardening (Immutability)

Da IFI auf einer ununterbrochenen Kette von inkrementellen Blöcken basiert, ist die Integrität der Daten kritisch. Immutability (Unveränderlichkeit) ist der Schutz vor Ransomware.

# S3 Beispiel für Objekt-Lock (WORM - Write Once, Read Many)
# Das Backup-System muss diese Eigenschaft beim Schreiben nutzen.
# WICHTIG: Die Dauer der Aufbewahrung sollte die maximale gesetzliche Retentionsfrist + 7 Tage betragen.
aws s3api put-object-lock-configuration \
    --bucket backup-repository-ifi-prod \
    --object-lock-configuration '{"ObjectLockEnabled": "Enabled", "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Years": 7}}}'

# Compliance Mode verhindert, dass selbst der Root-Account die Daten vor Ablauf löschen kann.

# 3. Deep Dive: Konfiguration für Profis

# Performance Tuning

# Deduplizierung und Block-Größe

Die Wahl der Block-Größe (Chunk Size) ist der wichtigste Performance-Hebel.

• Kleine Blöcke (4K-16K): Höhere Deduplizierungsrate (mehr identische Blöcke), ideal für virtuelle Desktops und Datenbanken mit kleinen, fragmentierten Schreibvorgängen. Nachteil: Massiv größere Deduplizierungs-Indexgröße und höhere CPU-Last auf dem Proxy/Repository.
• Große Blöcke (64K-512K): Geringere Deduplizierung, aber höhere Durchsatzrate. Ideal für große unstrukturierte Daten (Video, PACS, Archive).

Empfehlung: Setzen Sie unterschiedliche IFI-Policies für verschiedene Workloads ein, z.B. 8K für VM-Infrastruktur und 128K für File-Server.

# Synthetische Fulls (Synthetic Full Generation)

Die periodische Generierung von Synthetic Fulls hält die Restore-Kette kurz. Dies ist ein I/O-intensiver Job auf dem Repository, da Tausende von inkrementellen Blöcken gelesen, neu zusammengesetzt und als neuer, vollständiger Block-Satz im Katalog indiziert werden müssen.

• Tuning: Planen Sie Synthetic Fulls für Zeiten niedriger Repository-Auslastung. Stellen Sie sicher, dass das Repository genügend freie SSD-Kapazität für die Metadaten-Operationen während dieses Prozesses hat.

# Hardening & Security

# Verschlüsselung

Bei IFI ist die Verschlüsselung End-to-End entscheidend, da inkrementelle Blöcke wertvolle Informationseinheiten darstellen.

• Source-Side Encryption: Daten sollten verschlüsselt werden, bevor sie das Quellsystem verlassen. Dies verhindert, dass ein kompromittierter Proxy oder ein unsicherer Cloud Storage Provider die Daten im Klartext sehen kann. Nachteil: Inline-Deduplizierung kann nur nach der Entschlüsselung (auf dem Repository) durchgeführt werden, was die Effizienz der globalen Deduplizierung reduziert.
• Target-Side Encryption: Daten werden verschlüsselt, nachdem sie das Repository erreicht haben. Dies erlaubt globale Deduplizierung über alle Clients hinweg. Erfordert Vertrauen in die Transport- und Proxy-Schicht.

Senior Empfehlung: Nutzen Sie Client-Side Deduplizierung vor der Verschlüsselung, wenn der Backup-Vendor dies unterstützt. Andernfalls verwenden Sie die globale Deduplizierung am Ziel und stellen Sie sicher, dass die Transport-Verschlüsselung (TLS/IPsec) aktiv ist.

# 4. Day-2 Operations: Wartung & Alltag

IFI-Systeme benötigen aktive Pflege, insbesondere im Bereich Katalog-Management und Space Reclamation.

# Typische Tasks

# Space Reclamation (Garbage Collection)

Wenn Wiederherstellungspunkte ablaufen, müssen die zugehörigen, nicht mehr referenzierten Blöcke im Repository gelöscht werden. Dieser Prozess ist oft asynchron und kann die Repository-Performance beeinträchtigen.

• Tuning-Parameter: Viele Systeme erlauben es, die Aggressivität der Garbage Collection (GC) einzustellen. Bei hohem Bedarf an sofortiger Kapazitätsfreigabe muss die GC aggressiver laufen, was die Lese-I/O-Latenz erhöht. Bei ausreichend Platz sollte GC auf Off-Peak-Zeiten verschoben oder gedrosselt werden.

# Konsistenzprüfung (Data Verification)

Da IFI-Restores auf der Integrität einer langen Kette basieren, ist eine regelmäßige Verifizierung der Blöcke unerlässlich.

• Task: Regelmäßiges, automatisiertes SureBackup oder DataLabs (Vendor-spezifische Begriffe) – das tatsächliche Booten von VMs oder Mounten von Datenbanken aus den synthetischen Restore-Punkten, um die Recovery Time Objective (RTO) einzuhalten.

# Automatisierung (Ansible/Terraform)

Infrastructure-as-Code sollte die Policy-Definition, nicht die Ausführung des Backups selbst, verwalten.

# Ansible Beispiel: Definition einer IFI Backup-Policy (Hypothetisch)
- name: Ensure IFI Policy is compliant with RPO/RTO
  backup_platform.policy_management.backup_policy:
    name: critical_data_ifi
    state: present
    source_tag: production_tier1
    repository_target: s3_immutability_vault
    schedule:
      type: incremental_forever
      start_time: "22:00"
      interval: "1h" # Aggressives RPO
    retention:
      mode: block_chain_managed
      duration: 365d
      synthetic_full_frequency: monthly # Reduziert die Kettenlänge
    data_optimization:
      dedupe_level: high
      encryption_enabled: true
      cbt_validation: daily # Tägliche Integritätsprüfung der CBT-Liste

# 5. Troubleshooting & “War Stories”

IFI-Probleme manifestieren sich meistens als Performance-Einbrüche oder als Korruption in der Kette.

# Top 3 Fehlerbilder

# 1. Symptom A: Backup-Fenster läuft über (Überlange inkrementelle Backups)

• Fehlermeldung: “CBT list reports unusually high number of changed blocks.”
• Ursache: Der CBT-Treiber auf dem Quellsystem hat die Tracking-Funktion aufgrund eines Host-Crashs, einer vMotion-Migration oder eines Snapshots-Fehlers verloren. Der Agent fällt auf ein vollständiges Dateiscan oder eine sehr große “Pseudo-Inkrementelle”-Übertragung zurück.
• Lösung: Erzwingen Sie einen CBT-Reset. Bei Hypervisoren (VMware/Hyper-V) bedeutet dies oft, die CBT-Metadaten für die VM manuell zurückzusetzen (Achtung: Dies erfordert den nächsten Zyklus als Full Backup oder Synthetic Full).

# 2. Symptom B: Restore-Performance bricht ein

• Symptom: Wiederherstellung eines 6 Monate alten Punktes dauert 10x länger als ein Restore von vor 1 Woche.
• Ursache: Die Backup-Kette ist zu tief (zu viele inkrementelle Schritte zwischen dem letzten Full und dem Wiederherstellungspunkt). Der Katalog muss zu viele Blöcke aus dem Deduplizierungs-Repository zusammensuchen. Die Datenblöcke sind physisch im Repository fragmentiert.
• Analyse: Prüfen Sie die Metriken zur Fragmentierung des Repositorys und die Kettenlänge.
• Lösung: Führen Sie eine Synthetic Full Operation durch, um die Kette an der aktuellen Stelle zu konsolidieren. Ggf. muss das Repository eine Rehydration (Neuorganisation der Datenblöcke für bessere Locality) durchführen.

# 3. Symptom C: Unfähigkeit, einen Restore-Punkt zu generieren (Metadata Corruption)

• Symptom: “Restore Point verification failed: Missing block reference [UUID xyz].”
• Ursache: Korruption im zentralen Katalog oder im Deduplizierungs-Index. Dies ist die gefährlichste IFI-Fehlfunktion. Kann durch Repository-Hardwarefehler oder einen Fehler während einer Garbage Collection auftreten.
• Lösung:
  1. Isolierung: Backup-Jobs auf dem Repository stoppen.
  2. Reparatur: Versuchen Sie, den Katalog oder Index mit Herstellertools zu reparieren (z.B. catalog_repair --index-rebuild).
  3. Ultima Ratio: Wenn die Reparatur fehlschlägt, ist das betroffene Restore-Set (die Kette nach dem letzten guten Full) verloren. Sie müssen einen neuen Full-Seeding-Prozess starten und die betroffene Repository-Partition eventuell neu formatieren.

# Recovery Szenarien (Mermaid Tree)

graph TD
    A[Restore Failed: Missing Blocks] --> B{Katalog / Index Korrupt?};
    B -- Ja --> C{Letzter funktionierender Restore Point gefunden?};
    B -- Nein (Quell-CBT Fehler) --> D[CBT am Quellsystem zurücksetzen];

    C -- Ja --> E[Aktuelle Kette verwerfen / Isolieren];
    C -- Nein (Repository Totalverlust) --> F[Notfall-DR Plan aktivieren (z.B. Off-Site Kopie)];

    E --> G[Neuen Full Backup erzwingen (Seeding)];
    G --> H[Überwachung auf Index-Integrität verstärken];
    D --> G;

    style B fill:#f99,stroke:#333
    style C fill:#f99,stroke:#333
    style F fill:#fcc,stroke:#f00,stroke-width:2px

# 6. Monitoring & Alerting

Die Überwachung muss sich von der reinen Verfügbarkeit auf die Integrität und Effizienz der Kette verlagern.

# Metriken (Key Performance Indicators)

# Alerting-Regeln

• PAGER T1 (Sofortige Eskalation):
  • Restore Validation Test ist fehlgeschlagen (zeigt, dass RTO nicht erfüllt werden kann).
  • Repository Free Space < 10%.
• E-Mail T2 (Tagesüberprüfung):
  • Deduplizierungs-Rate ist um mehr als 20% gefallen (Warnung vor ineffizientem Prozess oder Ransomware).
  • Synthetic Full Operation ist fehlgeschlagen oder überfällig.

# Tools

Nutzen Sie Prometheus Exporter oder Checkmk Plugins, die direkten Zugriff auf die Vendor-API der Backup-Lösung haben, um spezifische IFI-Metriken (Dedupe-Statistiken und Katalogintegrität) auszulesen. Standard-OS-Metriken reichen hier nicht aus.

# 7. Fazit & Empfehlung

IFI ist die technisch überlegene Strategie für moderne, hoch-performante Data Protection. Es verschiebt den Engpass von der Quelle zum Ziel und zwingt uns, in hoch-performante, skalierbare Repository-Speicher zu investieren.

Wann würde ich es nicht einsetzen?

• Kleine Umgebungen (< 5TB): Der Overhead des CBT-Managements und des komplexen Katalogs überwiegt den Speichervorteil. Hier sind einfache Full/Differential-Strategien effizienter.
• Gesetzliche/Regulatorische Anforderungen: Wenn Compliance physisch getrennte, nicht-deduplizierte Full-Backups erfordert (z.B. obligatorische Bandarchivierung in manchen Branchen), muss IFI ergänzt oder umgangen werden.

Ausblick: Der Trend geht zu Continuous Data Protection (CDP), einer extremen Form von IFI, bei der inkrementelle Änderungen fast in Echtzeit auf den Zielspeicher übertragen werden. Die IFI-Architektur (CBT und Block-Level-Indizierung) bildet das Fundament für diese zukünftigen RPO=0 Strategien.

# Anhang: Cheatsheet (IFI-Metriken und Checklisten)

# Referenzen

• Linux Kernel Doku: Device Mapper (dm-snapshot und dm-persistent-data) APIs für Block Tracking.
• Veeam/Rubrik/Commvault Doku: Spezifische Implementierungen von Synthetic Full und Garbage Collection Logik.
• Storage Benchmarks: Whitepapers zu Random-I/O Performance auf Deduplizierungs-Appliances (Wichtig für Restore-Geschwindigkeit).
• RFC 4684: Information zu Data Deduplication Algorithms und deren Katalog-Design.