backup job stuck at 99 percent for hours

TL;DR

Do not judge by the percentage; open the job session details and find the child task that is still moving or truly hung, because 99 percent usually means data transfer finished and merge, cataloging, indexing, snapshot cleanup or application log processing remains. Give a moving task time and resources, clear a genuinely hung one through the product controls, and fix its cause. Killing the whole job blindly can leave the chain and snapshots in a worse state.

backup job stuck at 99 percent for hours

Use this when

• A backup job sits at 99 percent for hours with little or no throughput shown.
• The main transfer appears complete but the job will not close and blocks the next schedule.
• This repeats for the same job while other jobs finish normally.

Not for this skill when

• The job is at low progress and waiting on a locked VM or repository. Early stage waits have different causes.
• A restore or replication job is at 99 percent. Their closing tasks differ from backup post processing.
• The repository is offline. A closing task cannot complete against a missing target.

Steps

1. Open the job session or real time statistics view and list the per VM or per item statuses inside the job. Identify whether one item is still processing, and read its latest action line, which usually names merge, transform, health check, guest indexing, catalog upload or snapshot removal rather than backup. Verify: you can name the exact closing task and the item it belongs to instead of describing the job only by its percentage
2. Decide whether that task is moving: watch its counters, processed size, repository file timestamps and sizes, and host CPU and disk activity for ten to fifteen minutes. A merge or transform on a large full file legitimately runs for hours with modest visible progress, while a task with zero change in every counter is likely hung. Verify: counters or repository files are either demonstrably changing, supporting patience, or completely static across the observation window
3. If it is moving, remove pressure rather than restarting: pause competing jobs, confirm repository disk latency is not saturated, and let the task finish. Note its duration and set expectations, because the same closing work will recur and may need its own window or faster repository storage. Verify: the closing task completes without intervention and its duration is recorded for window planning
4. If it is static, check the dependencies of that specific task: repository free space for a merge, the catalog or database service for cataloging, guest credentials and application services for log truncation, and the hypervisor task queue for snapshot removal that may be progressing slowly in vCenter or Proxmox tasks. Fix the dependency you find rather than restarting every service. Verify: the dependency check produces a concrete fault, such as a full repository, a stalled hypervisor consolidation task or a stopped catalog service
5. Stop the job only through the product stop control, choosing the graceful option where offered, and then inspect the aftermath before rerunning: look for leftover snapshots on the VM, a chain needing a health check, and locks on the repository. Run the product health check for that restore point before the next backup. Verify: the job stops cleanly, leftover snapshots or locks are cleared through product or hypervisor tools, and the last restore point health check result is known
6. Rerun the job in a quiet period and watch the same closing task complete. If the same task hangs again at the same point, collect the job logs and open a support case with the task name and timestamps rather than repeating stop and retry cycles that risk the chain. Verify: the rerun passes the closing task, or a support case is opened with the session logs and the exact hung task identified

Why it happens

Backup progress percentages are weighted toward data transfer, so the long tail of closing work compresses into the last percent. That tail includes merging increments into the full file, removing the source snapshot and consolidating its delta, truncating application logs after a successful application aware backup, building the catalog and indexing guest files. Each has different dependencies and different safe interventions. A merge can be slow but healthy on an overloaded repository, while a snapshot removal can be waiting on the hypervisor and a catalog step can be blocked by a service fault. The percentage hides all of that, which is why the session detail is the only reliable starting point.

Variants and edge cases

A job stuck at 99 percent that also holds a source snapshot open is time sensitive: the delta file grows with production writes, so prioritise the snapshot removal branch if the hypervisor shows consolidation pending. Record the growth rate and escalate sooner on busy VMs. Conversely, indexing and catalog tasks can often be disabled or deferred for a job whose restore model does not use them, which is a legitimate permanent fix for repeated catalog stalls.

veeam job stuck at 99 percent merging backup files

The merge variant. Expect repository bound work; measure file change over time and repository latency before calling it hung.

backup stuck at 99 snapshot removal consolidation

Use when the hypervisor shows the snapshot still present. Work the consolidation task in the hypervisor and watch delta growth while you do.

backup job hangs at 99 percent truncating logs

The application processing variant. The backup is done; the log truncation step is waiting on the application or its credentials inside the guest.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-0TwhT2Ptmy5e5O82mTcFQ