Why Does a VM Backup Freeze at the Same Percentage Every Night?

A VM backup that freezes at the same percentage every night is usually reaching the same source region or backup phase, making the percentage a repeatable diagnostic marker.

Record the exact VM disk, phase, log message, throughput, and destination state at the freeze point. Then compare another datastore, inspect source storage around that region, separate guest-quiesce hooks from bulk transfer, and check nightly contention. Do not treat a stable percentage as proof that the network is failing.

Use the Percentage as a Repeatable Location Marker

Record the exact percentage, elapsed time, current VM disk, backup phase, transfer rate, and last log line on several nights. The percentage is evidence about where the job is, not a diagnosis by itself.

PBS tuning work shows that PBS performance bottlenecks can move between source reads, hashing, compression, network transfer, and datastore work, so map the stall to a phase before changing random settings.

If the same VM and phase stop at nearly the same point every run, prioritize deterministic source data or a repeatable workflow step over general network congestion.

Compare the Backup Target With Another Destination

Run the same VM backup to a different datastore or a temporary local target if capacity and recovery policy allow. Keep snapshot mode and VM workload comparable.

A common Proxmox backup storage path includes NFS or NAS storage, and target latency or locking can make one destination stall while the VM itself remains healthy.

If the alternate target passes the former freeze point, investigate the original datastore, filesystem, network path, and free space. If both freeze identically, return to the source or backup phase.

Check the Source Disk Around the Repeatable Region

Inspect host storage logs, SMART data, ZFS or filesystem errors, and read latency while the backup approaches the failing point. A backup may be the first job to read every cold block.

Real reports of long PBS backup bottlenecks illustrate why a long backup can be dominated by one bottleneck rather than the headline size of the VM.

A repeatable read error, timeout, or latency spike at the same point should move the incident into data-preservation mode. Avoid repeated full reads if the source disk is degrading.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Separate Guest Quiesce From Data Transfer

Note whether the backup freezes during guest-agent freeze, snapshot creation, metadata preparation, or after bulk data has already started moving. Test a maintenance-window backup with minimal guest workload.

General Proxmox backup workflow separates backup orchestration from storage transfer, which is useful when an application-consistent freeze hook hangs even though disk and network throughput are normal.

If disabling a nonessential guest quiesce hook lets the job proceed, repair that hook or guest agent before restoring the consistency option. Do not leave important databases unquiesced without an alternative recovery plan.

Move the Job Away From Competing Nightly Work

Compare the freeze timestamp with scrubs, replication, media scans, snapshots, deduplication, or cloud sync jobs. Temporarily shift only one competing job to test contention.

A deeper PBS architecture and tuning view of PBS is useful when several resources share the same nightly window and the backup percentage is merely where that contention becomes visible.

The issue is fixed when the backup crosses the old stall point repeatedly and completes with a usable restore point. The related ZimaSpace guide on VM backup readiness adds the recovery boundary; keep one test restore in the validation plan rather than trusting a 100 percent progress indicator.