The lab box had no backup job at all. Not a failed job, not a stale one: /etc/pve/jobs.cfg does not exist on this host, so there is no scheduled vzdump for any guest. CT 161, gamelab, is the unprivileged LXC on Proxmox pve-manager/9.2.5 where I run a DayZ dedicated server under LinuxGSM — the same box I built and first measured. It has 4 cores, 8192 MB RAM, 2048 MB swap, and a 60 GB rootfs on local-lvm, an LVM-thin pool. The DayZ server was running throughout the backup with zero players.
The snapshot run
I ran the backup manually because the schedule did not exist, and I wanted to see what a live snapshot backup actually costs on this hardware. The command was:
vzdump 161 --storage DataHDD500G1-backup --mode snapshot --compress zstdA snapshot backup freezes the guest filesystem, creates an LVM snapshot, thaws the filesystem, then copies from that snapshot. The freeze/thaw pair is momentary. The DayZ server did not stop and was not restarted; status = running throughout. Vzdump reported:
INFO: filesystem type on dumpdir is 'cifs' -using /var/tmp/vzdumptmp3654528_161 for temporary files
INFO: Starting Backup of VM 161 (lxc)
INFO: Backup started at 2026-08-13 21:11:34
INFO: status = running
INFO: CT Name: gamelab
INFO: backup mode: snapshot
INFO: create storage snapshot 'vzdump'
freeze guest filesystem
Logical volume "snap_vm-161-disk-0_vzdump" created.
thaw guest filesystem
INFO: creating vzdump archive '/DataHDD500G1/backup/dump/vzdump-lxc-161-2026_08_13-21_11_34.tar.zst'
INFO: Total bytes written: 10341632000 (9.7GiB, 104MiB/s)
INFO: archive file size: 6.03GB
INFO: cleanup temporary 'vzdump' snapshot
Logical volume "snap_vm-161-disk-0_vzdump" successfully removed.
INFO: Finished Backup of VM 161 (00:01:37)
What was measured
The run finished in 00:01:37, from 21:11:34 to 21:13:11. Vzdump read 10,341,632,000 bytes — 9.7 GiB — at 104 MiB/s, and wrote an archive of 6,479,585,133 bytes, which vzdump rounds to 6.03 GB. With zstd compression, the ratio was 1.596:1, so the archive is 62.7% of the bytes read.
That is the number the pricing pages tend to leave out: a live backup of this guest costs 97 seconds, reads under 10 GiB, and lands at about 6 GB.
Why 60 GB became 9.7 GiB
local-lvm is LVM-thin, so the guest’s 60 GB is provisioned, not allocated. lvs reports vm-161-disk-0 at 60.00g with data_percent 18.31. Only the written blocks exist, and only those get backed up. That is the single biggest reason the backup is faster and smaller than the disk size suggests.
At the time of the run, local-lvm showed 354,275,328 KiB total, 159,565,607 used, and 194,709,720 available, at 45.04% used. The backup target, DataHDD500G1-backup, a directory store, showed 467,401,728 KiB total, 100,495,488 used, and 366,906,240 available, at 21.50% used.
The two LVM warnings
During the run, LVM printed two warnings that belong in the same picture as the good numbers:
WARNING: You have not turned on protection against thin pools running out of space.
WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic
extension of thin pools before they get full.
WARNING: Sum of all thin volume sizes (457.00 GiB) exceeds the size of thin pool pve/data
and the amount of free space in volume group (16.00 GiB).Across all guests, the host has provisioned 457 GiB of thin volumes against a pool smaller than that, and the volume group has only 16.00 GiB of unallocated space left to grow the pool into. vgs pve reports VSize <464.76g and VFree 16.00g. This is not a problem today: the pool is 45% used with 194 GB free, because thin volumes only consume what they have written. It becomes a problem if the guests collectively write enough to fill the pool, and thin_pool_autoextend_threshold is not set, so nothing would extend it automatically. Nothing broke during this run; the warning is about the future.
What the numbers mean
For a 60 GB guest with 18.31% data written, a live snapshot backup costs 97 seconds, reads 9.7 GiB, and lands at 6.03 GB. It does not require a maintenance window; the game server stays up. The archive is small enough to keep several copies on the current backup target, which has 366,906,240 KiB free.
One operational detail: because the backup target is a CIFS-backed directory store, vzdump staged the archive through /var/tmp/vzdumptmp3654528_161 rather than writing directly to the share. The local filesystem needs room for that staging, so the local disk numbers matter even though the destination is network storage.
The next step for this box is not a different backup product. It is setting thin_pool_autoextend_threshold below 100 before adding more guests or letting the existing ones grow, and then adding a scheduled vzdump job. The measurements say the backup itself is cheap enough to run daily. The thing that wants attention is not the backup target; it is the thin pool behind the guest.
