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.

Das entscheidende Wort ist Kaskade. Backup-Systeme sind Pipelines. Ein primäres Backup erzeugt Wiederherstellungspunkte. Backup-Copy-Jobs hängen von diesen Punkten ab. Tape-Jobs können von lokalen Backup-Dateien abhängen. Aufbewahrung und Bereinigung hängen davon ab, 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.

Das beweist nicht, warum die Datei gesperrt war. 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.

Hier zählt Monitoring. Ein hängender Job, der bis zum nächsten Geschäftstag wartet, unterscheidet sich von einem 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.

Das macht tägliche Checkpoint-Entfernungsfehler zu mehr als nur 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. Das ist kein Vorwurf gegen diese Tools. So wird eine Dateisperre eingegrenzt.

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. Eine gesperrte Datei ist nicht automatisch eine fehlende Datei. Die nützliche Verbindung ist architektonisch: nachgelagerte Jobs hängen vom Zustand und der Zugänglichkeit früherer Wiederherstellungspunkte ab.

Deshalb sollte Backup-Monitoring Ketten verfolgen, nicht nur einzelne Job-Ergebnisse. Ein grünes primäres Backup hilft nicht, wenn die Kopie hängt. Eine erfolgreiche Kopie hilft nicht, wenn Tape nie startet. Ein abgeschlossener Tape-Schreibvorgang hilft nicht, 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. Prüfen Sie auf alte 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.

Am wichtigsten: Testen Sie jeweils eine Änderung. 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 ist nützlich. Es zeigt, warum es zu einfach wäre, den Object-Storage-Pfad für jedes Symptom verantwortlich zu machen. 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. Aufbewahrung und Bereinigung verändern Ketten später. Wenn ein Job hängen bleibt, verfolgen Sie 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. Jeder tägliche Checkpoint-Fehler braucht eine nachverfolgte Zählung nach VM und Host. 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. Die eigentliche Frage ist nicht, ob die Konsole wieder grün gemacht werden kann. Es ist, ob die geschützte Workload nach diesen wiederholten Unterbrechungen weiterhin sauber wiederhergestellt werden kann.

Hängende Jobs sind operative Schulden. Tägliche hängende Jobs sind ein Zuverlässigkeitsproblem.