# Inkrementelle Backups: Maximale Effizienz durch Change Tracking

TL;DR / Management Summary Jeden Tag ein Full-Backup von Terabytes an Daten zu machen, ist physikalisch unmöglich. Inkrementelle Backups sichern nur die Blöcke oder Dateien, die sich seit der letzten Sicherung geändert haben. Ein Senior Admin nutzt Technologien wie CBT (Change Block Tracking) oder ZFS Dirty-Region-Logging, um den Scan-Vorgang zu verkürzen. Das Ziel: Ein tägliches Backup-Fenster von Minuten statt Stunden, bei minimaler Last für das Netzwerk.

# 1. Einführung & Typen

Der Weg der Differenz.

1. Full Backup: Alles wird gesichert. Die Basis jeder Kette.
2. Incremental (Inkrementell): Sichert Änderungen seit dem letzten Backup (egal ob Full oder Inkrementell).
   • Vorteil: Kleinste Backup-Größe.
   • Nachteil: Der Restore benötigt die gesamte Kette (Full + alle Inkremente).
3. Differential (Differenziell): Sichert Änderungen seit dem letzten Full Backup.
   • Vorteil: Schnellerer Restore (nur Full + letztes Diff).
   • Nachteil: Die Backup-Dateien werden jeden Tag größer.

# 2. Deep Dive: Change Block Tracking (CBT)

Nicht mehr suchen, nur noch wissen.

In der Steinzeit mussten Backup-Programme jede Datei scannen, um zu sehen, ob sich der Zeitstempel geändert hat (langsam!). Moderne Systeme (Hyper-V, Proxmox, VMware) nutzen CBT.

• Technik: Der Hypervisor-Kernel führt eine Bitmap-Liste der geänderten Festplatten-Sektoren.
• Vorteil: Beim Backup fragt die Software nur: “Welche Blöcke haben sich seit ID 1234 geändert?”. Die Antwort kommt in Millisekunden. Es muss nichts gescannt werden.

# 3. Inkrementelle Backups in Proxmox

Die ‘Dirty Bitmap’ Logik.

Wenn Sie Proxmox mit dem Proxmox Backup Server (PBS) nutzen:

• Fast Incremental: QEMU (der VM-Emulator) merkt sich im RAM, welche Blöcke beschrieben wurden.
• Effizienz: Selbst eine 10 TB VM kann in 30 Sekunden inkrementell gesichert werden, wenn sich nur 50 MB Daten geändert haben.

# 4. Day-2 Operations: Backup-Ketten-Integrität

Die Gefahr der langen Kette.

Eine inkrementelle Kette ist wie eine Perlenschnur. Reißt eine Perle (ein korruptes Inkrement), ist das gesamte Backup ab diesem Punkt wertlos.

• Lösung A: Regelmäßige Full-Backups: Einmal pro Woche ein neues Full starten.
• Lösung B: Synthetic Fulls: Der Backup-Server baut im Hintergrund ein neues Full-Backup aus den Inkrementen zusammen, ohne die Produktion zu belasten (Artikel 629).

# 5. Troubleshooting & “War Stories”

Wenn das Inkrement zum Full wird.

# Top 3 Fehlerbilder

1. Symptom: Inkrementelles Backup dauert so lange wie ein Full.

   • Ursache: CBT-Daten sind verloren gegangen (z.B. nach einem harten Reset des Hosts). Die Software muss die gesamte Disk scannen, um Änderungen zu finden.
   • Lösung: Geduld haben. Nach einem erfolgreichen Lauf ist CBT wieder aktiv.

2. Symptom: Inkrementelle Backups sind riesig (Change Rate > 50%).

   • Ursache: Eine Applikation schreibt ständig neue Logs oder der Defragmentierungs-Dienst (Artikel 446) verschiebt Blöcke auf der Disk.
   • Lösung: Defrag in VMs deaktivieren!

3. Symptom: Restore einer langen Kette schlägt fehl.

   • Ursache: Bit-Rot im mittleren Teil der Kette.

# “War Story”: Der “SQL-Index” Schock

Ein Admin wunderte sich, warum sein tägliches Datenbank-Backup plötzlich von 10 GB auf 500 GB anstieg, obwohl nur wenige neue Kunden kamen. Die Entdeckung: Er hatte einen wöchentlichen Job konfiguriert, der alle SQL-Indizes neu aufbaute (Rebuild). Da dabei fast jeder Datenblock auf der Disk neu geschrieben wurde, sah das inkrementelle Backup dies als “Änderung” der gesamten Datenbank. Lehre: Wartungsarbeiten an Datenbanken und Dateisystemen (Optimize, Defrag) sind die natürlichen Feinde der inkrementellen Backup-Effizienz.

# 6. Monitoring & Reporting

Die Change-Rate im Blick.

# KPIs

• Daily Change Rate %: Sollte bei Office-Servern < 5%, bei SQL-Servern < 15% liegen.
• CBT Status: Prüfen Sie in den Backup-Logs, ob “Change Block Tracking” wirklich genutzt wurde (Status: Success).

# 7. Fazit & Empfehlung

Inkrementelle Backups sind das Fundament moderner RPOs.

• Empfehlung: Nutzen Sie Incremental-Forever Strategien (wie bei PBS oder Borg), um Bandbreite zu sparen.
• Wichtig: Verlassen Sie sich nicht auf die Kette. Führen Sie regelmäßig Integritäts-Prüfungen (Verify) auf dem Backup-Speicher durch, um Bit-Rot zu erkennen.

# Anhang: Vergleich der Methoden

# Referenzen

• Proxmox: Backup and Restore - CBT explanation
• Veeam: Understanding Incremental Backups
• Microsoft: Change Block Tracking in Hyper-V