← All break/fix scenarios in Proxmox VE
PBS runs vzdump with `bwlimit` not set, so it issues reads at the raw disk speed. The VM's disk reads and the backup's disk reads compete for the same underlying storage IOPS budget. The VM experiences this as CPU steal time because qemu waits on I/O that isn't completing. The fact that the issue only appears at backup time is the tell — it's not a resource leak or a configuration change, it's a predictable resource contention with a scheduled job.
1. Throttle the backup job: `vzdump 100 --bwlimit 102400` (100 MB/s) or set a per-storage default in `/etc/vzdump.conf`. 2. Stagger backup jobs so they don't all run at 02:00. Use the `starttime` parameter to spread them across the night. 3. Move the VM to a different storage backend if its I/O is latency-sensitive and the backup can't be throttled enough. 4. Consider PBS-side read concurrency limits: in the PBS storage config, set `max-workers` lower than 4 if the storage backend can't keep up.
- Application latency inside the VM returns to baseline during the next backup window - CPU steal time inside the VM stays under 2% - Backup job still completes within the maintenance window - `iostat` on the storage backend shows reasonable IOPS during backup
- Always set `bwlimit` on vzdump jobs - Stagger backup start times across the cluster - Monitor storage IOPS headroom, not just capacity - Test backup impact with realistic load before going to production
The pattern here is: scheduled event, predictable time, monotonic correlation. When something reliably happens at the same hour and disappears after, suspect scheduled jobs first.
CPU steal time is the diagnostic clue: it means the hypervisor is ready to give the vCPU CPU time, but the underlying I/O isn’t completing. This is almost always a shared-storage contention.