Plan backup windows that finish before morning.

Why the first backup lies to you

The first backup of a guest reads and uploads everything — a 500GB VM over a 100 Mbps uplink is a 12-hour job even before dedup and compression help. Every backup after that is a different animal. For running QEMU guests, Proxmox VE keeps a dirty bitmap: a live record of which blocks changed since the last backup. The next run reads only those blocks, so a VM with 2% daily change backs up in minutes, not hours.

The catch that surprises people: the dirty bitmap lives in QEMU's memory. Shut the VM down, migrate it, or reboot the node, and the bitmap is gone — the next backup logs dirty-bitmap status: created new and must re-read the full disk. It still only uploads chunks the server doesn't already have, so it's much faster than the true first backup, but the read time returns. If your window calculations assume incremental speed, one host reboot can blow the window.

Practical rule: size your window for the re-read case on your largest guests, and treat bitmap-fast nights as the bonus, not the baseline.

Estimating duration

Three numbers per guest: disk size, daily change rate, and the slowest link in the path (source storage read speed, network, or PBS ingest). Then:

# steady-state (bitmap alive)
duration ≈ (disk_size × change_rate) / upload_throughput

# worst case (bitmap lost)
duration ≈ disk_size / source_read_speed  +  (changed_chunks / upload_throughput)

Real change rates: database servers commonly run 5–15% daily; file servers 1–5%; appliance-style VMs under 1%. Don't guess — after two weeks of backups, the task logs show actual transferred bytes per run, which is your real number. Our sizing guide covers the same math for storage.

Staggering jobs

One job containing every guest starts everything at once and saturates source storage, network, and PBS ingest simultaneously. Better: split by priority and spread the clock.

• Group by recovery priority, not alphabet. Critical guests in the earliest job, so if the window overruns, the things that matter finished.
• Start groups 60–90 minutes apart rather than back-to-back — overruns then overlap gracefully instead of cascading.
• Big change-rate guests get their own job. The database VM that ships 80GB nightly shouldn't hold twelve small guests hostage.

In Proxmox VE, that's simply multiple backup jobs with different schedules and guest selections — details in setting up backup jobs.

Bandwidth limits — when the pipe is shared

Backups to an offsite PBS share the uplink with production traffic. Two places to shape it: on the PVE side, vzdump accepts a bandwidth limit (job-level Advanced → Limit I/O bandwidth, or bwlimit in /etc/vzdump.conf); on the PBS side, Configuration → Traffic Control applies rate limits by client network and time window — e.g. 200 Mbps during business hours, unlimited overnight, which usually beats a flat cap.

Hosting with us: transfer on Dedicated plans matches your tier each month (a 50TB plan includes 50TB of monthly transfer), and your first month is unmetered specifically so the initial full backups can seed the server without watching a meter. That first-seed window is exactly when you'd otherwise be doing bandwidth math.

Keep the housekeeping out of the window

Verification re-reads chunks and GC walks the entire chunk store — both compete with ingest for the datastore's IOPS. Schedule them after the backup window closes: prune right after backups (it's cheap), GC mid-morning, verify on weekends. The full reasoning is in monitor, verify & prune.