# Backup Validation & Verification: Integritätsschutz für den Ernstfall

TL;DR / Management Summary Ein Backup-Job, der mit “Success” beendet wurde, garantiert nur, dass die Daten übertragen wurden. Er garantiert nicht, dass die Daten auf dem Zielspeicher noch lesbar sind oder dass sie logisch konsistent sind. Wir nutzen Verification Jobs, um Bit-Rot (schleichender Datenverlust durch Hardwarefehler) zu erkennen, und Validation Jobs, um die bootfähige Nutzbarkeit der Daten zu prüfen. Ein Senior Admin plant diese Jobs so ein, dass sie die tägliche Backup-Performance nicht beeinträchtigen, aber dennoch lückenlos alle Datenbestände abdecken.

# 1. Einführung & Definitionen

Integrität ist kein Zufall.

1. Checksum Verification (Integrität): Prüft, ob der geschriebene Block noch identisch zum gelesenen Block ist. Erkennt Hardware-Fehler.
2. Logical Validation (Konsistenz): Prüft, ob das Dateisystem oder die Datenbank innerhalb des Backups fehlerfrei ist.
3. Boot Validation (Verfügbarkeit): Startet die VM in einer Sandbox (Artikel 640).

# 2. Verification in Proxmox / PBS

Der blockbasierte Check.

Der Proxmox Backup Server (PBS) nutzt eine extrem effiziente Verification-Engine.

• Aktion: Erstellen Sie unter Maintenance -> Verify Jobs einen neuen Task.
• Einstellung: Verify All (für das gesamte Repository) oder Skip verified snapshots (um nur neue oder ungeprüfte Stände zu scannen).
• Frequenz: Wöchentlich empfohlen.

# Manueller Start via Shell
proxmox-backup-manager verify --repository my-repo --all

# 3. Deep Dive: Bit-Rot & Silent Data Corruption

Der Feind im Verborgenen.

Bit-Rot tritt auf, wenn magnetische oder elektrische Ladungen auf der Disk über Jahre schwächer werden.

• Gefahr: Das Backup-Programm meldet beim Restore plötzlich “Checksum Error”, und die Kette bricht ab.
• Lösung: Verification-Jobs lesen jeden einzelnen Datenblock vom Storage und vergleichen den SHA-256 Hash mit dem Index. Wird eine Abweichung gefunden, markiert PBS den Block als Bad.
• Recovery: Wenn der Block in einem anderen Snapshot noch gesund vorhanden ist, kann PBS ihn reparieren.

# 4. Day-2 Operations: Ressourcen-Planung

Die Last des Prüfens.

Ein Verification-Job muss jedes Byte vom Speicher lesen.

• I/O Last: Bei einem 100 TB Repository dauert ein Full-Scan auf HDDs mehrere Tage.
• Strategie: Nutzen Sie “Incremental Verification”. Prüfen Sie nur Daten, die jünger als 30 Tage sind, öfter als uralte Archivdaten.

# 5. Troubleshooting & “War Stories”

Wenn der Check Fehler findet.

# Top 3 Fehlerbilder

1. Symptom: Verification schlägt fehl mit “Manifest mismatch”.

   • Ursache: Das Index-File (Manifest) passt nicht mehr zu den Daten-Chunks.
   • Lösung: Prüfen Sie das Dateisystem des Backup-Servers (z.B. zpool status).

2. Symptom: Job dauert unendlich lange.

   • Ursache: Zu viele kleine Chunks auf langsamen mechanischen Platten.
   • Fix: Nutzen Sie SSDs für den PBS-Index oder vergrößern Sie den RAM des Backup-Servers.

3. Symptom: “Bad Chunks” nach Stromausfall.

   • Lösung: Löschen Sie die betroffenen Snapshots und starten Sie ein neues Full-Backup (Active Full) der betroffenen VMs.

# “War Story”: Der schweigende Sterbe-Prozess

Ein Admin sicherte 200 VMs auf ein großes RAID-6 System. Er verzichtete auf Verification-Jobs, um die Performance nicht zu drücken. Das Ergebnis: Ein Controller-Fehler schrieb über Monate hinweg falsche Paritätsdaten. Als ein Restore nötig war, stellte sich heraus, dass 30% aller Backup-Ketten korrupt waren. Lehre: Ohne regelmäßige Verification ist ein Backup-Storage nur ein Hoffnungsspeicher. Die Last der Prüfung ist der Preis für die Sicherheit.

# 6. Monitoring & Reporting

Statusberichte.

# Compliance Reporting

Integrieren Sie die Verification-Ergebnisse in Ihren wöchentlichen Bericht (Artikel 641).

• Metrik: % of Repository Verified. Zielwert: 100% innerhalb von 30 Tagen.

# 7. Fazit & Empfehlung

Verification ist der wichtigste Wartungs-Task nach dem eigentlichen Backup.

• Empfehlung: Nutzen Sie den PBS Verify Job mit der Option “Re-verify after 30 days”.
• Wichtig: Wenn ein Verification-Job einen Fehler findet, informieren Sie sofort das Team. Es ist kein “vielleicht” Fehler – es ist ein definitiver Datenverlust in dieser Backup-Instanz.

# Anhang: Cheatsheet

# Referenzen

• Proxmox Backup Server: Maintenance Tasks
• CERN: Data Integrity and Bit-Rot Study
• Veeam: Health Check for Backup Repositories