Veeam-Jobs: Gesperrte Dateien und hängende Checkpoints

Gesperrte Backup-Dateien und fehlgeschlagene Hyper-V-Checkpoint-Bereinigung können aus einem Veeam-Problem mehrere hängende Jobs machen. In einer Produktionsbeschwerde von 2026 berichtete ein Administrator, dass Backup-Dateien ohne erkennbaren Grund gesperrt wurden, Tape-Workflows daraufhin ins Stocken gerieten und Checkpoint-Entfernungsfehler täglich auftraten.

Solche Fehler pflanzen sich fort, weil Backup-Systeme Pipelines sind. Ein primäres Backup erzeugt Wiederherstellungspunkte, von denen Backup-Copy-Jobs abhängen, und Tape-Jobs können von lokalen Backup-Dateien abhängen. Aufbewahrung und Bereinigung setzen voraus, dass vorherige Sitzungen korrekt abgeschlossen wurden. Wenn eine Stufe eine Datei blockiert oder einen Checkpoint zurücklässt, kann der sichtbare Fehler an anderer Stelle auftauchen.

Wie kann eine gesperrte Veeam-Datei mehrere Jobs zum Stillstand bringen?

Eine Backup-Datei, die weiterhin in Benutzung ist, kann verhindern, dass ein anderer Prozess sie wie erwartet liest, verschiebt, transformiert, löscht oder kopiert. In der gemeldeten Umgebung sagte der Administrator, andere Jobs könnten hängen bleiben, bis es jemandem auffalle, wobei Tape ausdrücklich als ein nachgelagerter Workflow genannt wurde.

Warum die Datei gesperrt war, ist damit nicht geklärt. Die Ursprungsdiskussion identifiziert weder den besitzenden Prozess noch ein Antivirenprodukt, Storage-Verhalten, eine Veeam-Komponente oder eine andere Ursache. Eine dieser Möglichkeiten als Tatsache zu behandeln, würde über die Beweislage hinausgehen.

Der richtige erste Schritt ist, den Besitzer zum Zeitpunkt des Fehlers zu identifizieren. Erfassen Sie die Job-Session, Veeam-Protokolle, Windows-Ereignisdaten, Repository-Protokolle und Betriebssystem-Dateihandle-Informationen, bevor Sie Dienste neu starten. Wenn die Sperre nach einem Neustart verschwindet, kann der Beweis mit ihr verschwinden.

Deshalb braucht es Monitoring. Ein hängender Job, der bis zum nächsten Geschäftstag unbemerkt bleibt, ist etwas anderes als ein Job, der nach einem definierten Zeitraum ohne Fortschritt alarmiert. Der Mr.PlanB-Storage-Hub betrachtet Wiederherstellungssysteme aus operativer Perspektive, und „wie lange darf ein Job ohne Fortschritt bleiben, bevor jemand es merkt?" ist eines dieser Verhaltensmuster.

Warum sind fehlgeschlagene Hyper-V-Checkpoint-Entfernungen wichtig?

Veeam Backup & Replication nutzt Microsoft-Hyper-V-Produktions-Checkpoints für Online-Backup auf unterstützten Hyper-V-Versionen. Die aktuelle Veeam-13-Dokumentation beschreibt einen Prozess, bei dem Veeam einen Produktions-Checkpoint anfordert, die VM-Daten liest und der temporäre Checkpoint nach der Verarbeitung wieder mit der ursprünglichen VM zusammengeführt wird.

Tägliche Checkpoint-Entfernungsfehler sind deshalb mehr als Konsolenrauschen. Zurückgebliebene oder wiederholt fehlschlagende Checkpoints können Storage verbrauchen, den VM-Zustand verkomplizieren und darauf hindeuten, dass der Backup-Prozess nicht sauber abschließt.

Der Administrator berichtete 2026, dass Checkpoint-Entfernungsfehler jeden Tag auftraten. Der Support bat darum, CheckpointRemovalParallelism vom genannten Standardwert 64 auf 32 zu senken. Der wahrscheinliche Zweck dieses Experiments war, zu ändern, wie viel Bereinigungsarbeit parallel ablief, aber die Quelle belegt die interne Diagnose nicht.

Übernehmen Sie diesen Wert nicht nur, weil er in einer öffentlichen Diskussion auftauchte. Nutzen Sie ihn als Beispiel dafür, wie kontrolliertes Troubleshooting aussieht: eine Variable ändern, dieselbe Workload reproduzieren und messen, ob sich das Symptom ändert.

Was sollte erfasst werden, bevor Veeam-Dienste neu gestartet werden?

Erfassen Sie genug Beweise, um drei Fragen zu beantworten: Was hängt, wem gehört es, und was geschah unmittelbar vor dem Stillstand?

Exportieren Sie auf der Veeam-Seite die Job-Session-Details und die relevanten Protokolle. Notieren Sie Backup-Server-Build, Repository-Server-Build, Proxy-Rollen, Transportmodus, Job-Name, Wiederherstellungspunkt und genaue Zeitstempel.

Notieren Sie für Hyper-V die VM, den Host, den Cluster-Knoten, den Checkpoint-Status, den verfügbaren Speicherplatz, VSS-Ereignisse und Hyper-V-VMMS-Ereignisse. Wenn die VM rund um den Fehler zwischen Cluster-Knoten migriert ist, nehmen Sie das mit auf.

Identifizieren Sie bei einer gesperrten Repository-Datei nach Möglichkeit das Prozess-Handle. Prüfen Sie außerdem, ob Antivirus, EDR, Indizierung, Deduplizierung, Replikation oder Storage-seitige Software den Repository-Pfad berührt. Diese Tools stehen damit nicht unter Verdacht, so grenzt man eine Dateisperre eben ein.

Wenn die erste Troubleshooting-Maßnahme immer „Veeam neu starten" ist, kann sich die Umgebung erholen, während die eigentliche Ursache unsichtbar bleibt.

Können fehlende oder unzugängliche Wiederherstellungspunkte weitere Kopierprobleme verursachen?

Ja. Die aktuelle Veeam-Dokumentation warnt, dass Backup-Copy- oder Wiederherstellungsvorgänge, die von unzugänglichen Wiederherstellungspunkten in einer Backup-Kette abhängen, betroffen sein können. Das Produkt bietet konkrete Möglichkeiten, fehlende Punkte aus der Konfiguration zu entfernen oder als vergessen zu markieren, mit Warnhinweisen zur Kettenintegrität.

Diese Dokumentation sollte nicht mit dem gemeldeten Dateisperren-Fall verwechselt werden, denn eine gesperrte Datei ist nicht automatisch eine fehlende Datei. Gemeinsam ist beiden Fällen die Architektur: Nachgelagerte Jobs hängen vom Zustand und der Zugänglichkeit früherer Wiederherstellungspunkte ab.

Backup-Monitoring sollte deshalb ganze Ketten verfolgen und nicht nur einzelne Job-Ergebnisse. Ein grünes primäres Backup hilft wenig, wenn die Kopie hängt, eine erfolgreiche Kopie wenig, wenn Tape nie startet, und auch ein abgeschlossener Tape-Schreibvorgang bringt nichts, wenn niemand die Wiederherstellung getestet hat.

Für einen anderen Virtualisierungs-Stack macht der Mr.PlanB-Proxmox-Backup-Leitfaden dieselbe Unterscheidung zwischen dem Erstellen von Backups und dem Nachweis der Wiederherstellbarkeit.

Wie sollten Checkpoint-Fehler auf einem Cluster eingegrenzt werden?

Beginnen Sie mit einer betroffenen VM und stellen Sie fest, ob das Problem der VM oder dem Host folgt. Wenn Fehler nur auf einem Hyper-V-Knoten auftreten, prüfen Sie dessen VSS, Storage, Patch-Stand und Hyper-V-Zustand. Wenn dieselbe VM nach dem Verschieben auf einen anderen Knoten weiterhin fehlschlägt, wird die VM oder Workload interessanter.

Trennen Sie außerdem anwendungsbewusste Verarbeitung von der grundlegenden Checkpoint-Operation. Wenn sich ein einfacher, absturzkonsistenter oder nicht anwendungsbewusster Test anders verhält als der normale Job, kann das die Ebene eingrenzen. Ändern Sie die produktive Schutzrichtlinie nicht dauerhaft, nur um den Fehler verschwinden zu lassen.

Prüfen Sie den freien Speicherplatz dort, wo Checkpoint-Daten erstellt und zusammengeführt werden, und suchen Sie nach alten Checkpoints und AVHDX-Dateien. Bestätigen Sie, dass die Storage-Latenz während des Merge-Fensters nicht ausschlägt. Notieren Sie, ob der Fehler während der Job-Verarbeitung oder nachdem die Backup-Daten bereits übertragen wurden, auftritt.

Vor allem sollten Sie jeweils nur eine Änderung testen. Registry-Tuning, Host-Patches, Storage-Firmware, Antivirus-Ausnahmen und Änderungen an der Job-Gleichzeitigkeit sollten nicht alle in einem Wartungsfenster landen, sofern kein separater betrieblicher Grund dafür besteht.

Warum kann Tape ein Problem sichtbar machen, das anderswo entstanden ist?

Tape sitzt oft nachgelagert vom Disk-Backup und kann daher der Ort werden, an dem ein früherer Fehler sichtbar wird. In der gemeldeten Umgebung lasen Tape-Jobs von lokalen Disk-Backups und riefen keine Daten von S3 ab. Trotzdem sah der Administrator, dass Tape-Jobs hängen blieben, wenn Backup-Dateien gesperrt waren.

Dieses Detail zeigt, warum es zu einfach wäre, den Object-Storage-Pfad für jedes Symptom verantwortlich zu machen, denn manche Fehler betrafen die Verfügbarkeit lokaler Backup-Dateien unabhängig vom S3-Abruf.

Zeichnen Sie den Abhängigkeitsgraphen: Das primäre VM-Backup erzeugt Dateien, Backup-Copy verbraucht sie, Tape verbraucht lokale Backups, und Aufbewahrung und Bereinigung verändern Ketten später. Wenn ein Job hängen bleibt, verfolgen Sie ihn rückwärts, bis Sie die erste ungesunde Abhängigkeit finden. Das ist zuverlässiger, als die letzte Fehlermeldung zu lesen und anzunehmen, dass die letzte Komponente das Problem verursacht hat.

Was würde ich in dieser Umgebung zuerst reparieren?

Ich würde Sichtbarkeit vor Tuning priorisieren. Jeder Job, der hängen bleiben kann, braucht einen Alarm bei ausbleibendem Fortschritt, und tägliche Checkpoint-Fehler sollten nach VM und Host gezählt werden. Jede wiederkehrende Dateisperre braucht eine erfasste Prozess-Zuordnung, bevor Dienste neu gestartet werden.

Dann würde ich einen Checkpoint-Fehler und ein Dateisperren-Ereignis unter reduzierter Gleichzeitigkeit reproduzieren. Wenn der Support eine Änderung von CheckpointRemovalParallelism wünscht, dokumentieren Sie das Ergebnis vorher und nachher. Wenn keine messbare Verbesserung folgt, stellen Sie die ursprüngliche Einstellung wieder her, sofern der Hersteller nichts anderes sagt.

Schließlich würde ich eine Wiederherstellung aus einer betroffenen Backup-Kette durchführen. Eine grüne Konsole sagt wenig darüber, ob sich die geschützte Workload nach diesen wiederholten Unterbrechungen weiterhin sauber wiederherstellen lässt. Ein gelegentlich hängender Job ist operative Schuld, täglich hängende Jobs sind ein Zuverlässigkeitsproblem.