Veeam Jobs: Locked Files and Stuck Checkpoints

Locked backup files and failed Hyper-V checkpoint cleanup can turn one Veeam problem into several stuck jobs. In a 2026 production complaint, an administrator said backup files became locked for no apparent reason, tape workflows then stalled, and checkpoint removal failures occurred daily.

The important word is cascade. Backup systems are pipelines. A primary backup produces restore points. Backup-copy jobs depend on those points. Tape jobs may depend on local backup files. Retention and cleanup depend on prior sessions finishing correctly. When one stage holds a file or leaves a checkpoint behind, the visible failure can appear somewhere else.

How can one locked Veeam file stall several jobs?

A backup file that remains in use can prevent another process from reading, moving, transforming, deleting, or copying it as expected. In the reported environment, the administrator said other jobs could get stuck until somebody noticed, with tape specifically mentioned as one downstream workflow.

That does not prove why the file was locked. The source discussion does not identify the owning process, an antivirus product, storage behavior, a Veeam component, or another cause. Treating any one of those as fact would go beyond the evidence.

The right first step is to identify the owner at the time of failure. Capture the job session, Veeam logs, Windows event data, repository logs, and operating-system file-handle information before restarting services. If the lock disappears after a restart, the evidence may disappear with it.

This is where monitoring matters. A stuck job that waits until the next business day is different from a job that alerts after a defined no-progress interval. The Mr.PlanB storage hub frames recovery systems around operational behavior, and "how long can a job make no progress before somebody knows?" is one of those behaviors.

Why do Hyper-V checkpoint removal failures matter?

Veeam Backup & Replication uses Microsoft Hyper-V production checkpoints for online backup on supported Hyper-V versions. Current Veeam 13 documentation describes a process where Veeam requests a production checkpoint, reads the VM data, and then the temporary checkpoint is merged back with the original VM after processing.

That makes daily checkpoint removal failure more than console noise. Leftover or repeatedly failing checkpoints can consume storage, complicate VM state, and indicate that the backup process is not completing cleanly.

The 2026 administrator said checkpoint removal failures happened every day. Support asked them to lower CheckpointRemovalParallelism to 32 from the stated default of 64. The likely purpose of that experiment was to change how much cleanup work happened in parallel, but the source does not prove the internal diagnosis.

Do not copy that value because it appeared in a public discussion. Use it as an example of what controlled troubleshooting looks like: change one variable, reproduce the same workload, and measure whether the symptom changes.

What should be captured before restarting Veeam services?

Capture enough evidence to answer three questions: what is stuck, who owns it, and what happened immediately before the stall.

For the Veeam side, export the job-session details and relevant logs. Record the backup server build, repository server build, proxy roles, transport mode, job name, restore point, and exact timestamps.

For Hyper-V, record the VM, host, cluster node, checkpoint state, available storage, VSS events, and Hyper-V VMMS events. If the VM migrated between cluster nodes around the failure, include that.

For a locked repository file, identify the process handle if possible. Also check whether antivirus, EDR, indexing, deduplication, replication, or storage-side software is touching the repository path. That is not an accusation against those tools. It is how a file lock is narrowed.

If the first troubleshooting action is always "restart Veeam," the environment may recover while the root cause remains invisible.

Can missing or inaccessible restore points create more copy problems?

Yes. Current Veeam documentation warns that when restore points in a backup chain are inaccessible, backup copy or restore operations that depend on those points can be affected. The product provides specific ways to forget or remove missing points from configuration, with cautions around chain integrity.

That documentation should not be confused with the reported file-lock case. A locked file is not automatically a missing file. The useful connection is architectural: downstream jobs depend on the health and accessibility of earlier restore points.

This is why backup monitoring should follow chains, not only individual job results. A green primary backup does not help if the copy is stuck. A successful copy does not help if tape never starts. A completed tape write does not help if nobody has tested the restore.

For a different virtualization stack, the Mr.PlanB Proxmox backup guide makes the same distinction between creating backups and proving recovery.

How should checkpoint failures be isolated on a cluster?

Start with one affected VM and determine whether the problem follows the VM or the host. If failures occur only on one Hyper-V node, inspect that node's VSS, storage, patch level, and Hyper-V state. If the same VM fails after moving to another node, the VM or workload becomes more interesting.

Also separate application-aware processing from the base checkpoint operation. If a simple crash-consistent or non-application-aware test behaves differently from the normal job, that can narrow the layer. Do not change production protection policy permanently just to make the error disappear.

Check free space where checkpoint data is created and merged. Check for old checkpoints and AVHDX files. Confirm that storage latency is not spiking during the merge window. Record whether the failure happens during job processing or after backup data has already been transferred.

Most importantly, test one change at a time. Registry tuning, host patches, storage firmware, antivirus exclusions, and job concurrency changes should not all land in one maintenance window unless there is a separate operational reason.

Why can tape expose a problem that started elsewhere?

Tape often sits downstream from disk backup, so it can become the place where an earlier failure becomes visible. In the reported environment, tape jobs read from local disk backups and did not pull data from S3. Yet the administrator still saw tape jobs become stuck when backup files were locked.

That detail is useful. It shows why blaming the object-storage path for every symptom would be too simple. Some failures affected local backup-file availability independently of S3 retrieval.

Draw the dependency graph. Primary VM backup creates files. Backup copy consumes them. Tape consumes local backups. Retention and cleanup modify chains later. When a job stalls, trace backward until you find the first unhealthy dependency.

This is more reliable than reading the final error message and assuming the final component caused the problem.

What would I fix first in this environment?

I would prioritize visibility before tuning. Every job that can remain stuck needs a no-progress alert. Every daily checkpoint failure needs a tracked count by VM and host. Every recurring file lock needs process ownership captured before services are restarted.

Then I would reproduce one checkpoint failure and one file-lock event under reduced concurrency. If support wants CheckpointRemovalParallelism changed, document the before-and-after result. If no measurable improvement follows, restore the original setting unless the vendor says otherwise.

Finally, I would perform a restore from a backup chain that experienced the issue. The real question is not whether the console can be made green again. It is whether the protected workload can still be recovered cleanly after these repeated interruptions.

Stuck jobs are operational debt. Daily stuck jobs are a reliability problem.