vzdump backup retention off-site transfer is a two-part problem: you need to keep local copies short and prune the remote ones too. Otherwise you sync everything and the off-site box fills up with old dumps you don’t need.
What vzdump’s retention actually does
vzdump’s own retention settings only apply to the local backup storage. If you use --prune-backups keep-last=3 or set it in the storage config, it cleans up dumps on that storage after each backup job. It has no idea about your off-site copies.
So if you rsync or rclone the dump directory to a NAS or cloud, the off-site side just accumulates everything. You have to handle retention there separately.
The manual way: a prune script on the off-site box
I’d run a simple script on the off-site host. Find dumps older than N days and delete them, but keep at least a few. Something like this:
#!/bin/bash
# Prune vzdump backups older than 14 days, keep at least 3
find /mnt/offsite-backups -name 'vzdump-*.{vma,zst,tar,lzo}' -mtime +14 -print0 | \
sort -z | head -z -n -3 | xargs -0 rm -fThat keeps the three newest and removes anything older than two weeks. Adjust the numbers to match your local retention.
Run it as a cron job daily or weekly. If the off-site box is a Proxmox host, you could even use a hookscript to trigger it after a backup, similar to what I covered in this post on hookscripts.
Proxmox Backup Server handles this properly
If you’re serious about off-site backups, just use Proxmox Backup Server (PBS). It has real retention policies that work across remotes. You set up a remote in PBS, create a sync job, and the retention rules apply to both local and remote datastores.
PBS deduplicates too, so your off-site storage needs are way smaller. And you get verification jobs. It’s more setup, but you stop babysitting scripts.
My take
For a homelab, the manual script is fine. It’s dumb and it works. But if you already have a PBS instance or can spin one up, use that. The retention logic is built in and you won’t forget to update a cron job when you change backup schedules.
One thing to watch: if you use --remove 0 in vzdump to keep all local backups and rely on off-site retention, make sure the off-site prune script actually runs. Missing one cron run means you keep everything forever. Test it with find -mtime first before letting it delete anything.
If you’d rather pay for this
Backblaze B2 with lifecycle rules can handle retention on the cloud side. It’s about $6/TB/month for storage. Worth it if you don’t want another server to manage. But for most homelabs, a cheap NAS and a cron job does the same thing for less.
