Backups are undoubtedly important for your daily driver, and their utility goes up significantly when you step into the home lab domain. So much so that one of the first tips you’d come across on home server forums would be about creating regular backups of essential data. After all, when you’ve spent days building a robust army of containers and virtual guests, the last thing you’d want is for a misconfigured config file to render your entire server irrecoverable.

Fortunately, Proxmox packs many advanced backup features compared to other virtualization platforms, while still making them easier to access even for beginners. That said, you might want to avoid these pitfalls when creating a backup workflow for your Proxmox workstations.

Relying solely on vzdump backups even as your home lab scales up

A 3-2-1 PBS setup is what you’re looking for

The vzdump utility built into Proxmox is pretty handy for new home labbers, and assuming you have enough space in your local hard drives, you can use it to create automated backup schedules. That said, there are a couple of caveats about relying on it, especially when you’ve got a powerful home lab with spare nodes. For starters, hoarding backups on your host machine will make them vulnerable to botched experiments. You could technically utilize SMB/NFS shares to save your virtual guest backups and snapshots on a spare NAS, but vzdump can become rather inefficient when you’ve got dozens of LXCs and VMs.

That’s why I’ll always recommend going down the Proxmox Backup Server route when you can afford to add an extra node to your setup. Between its incremental snapshots, compression algorithms, and solid deduplication provisions, PBS works well even on budget-friendly 2-bay NAS units. Better yet, you can use its Rsync capabilities with another cheap x86 SBC or sub-$150 mini-PC to create an offsite PBS instance that pulls essential virtual guest backups from your local PBS server every once in a while for extra redundancy.

Not verifying your backups

Especially if you created the original snapshots ages ago

Storage devices, including the most expensive hard drives out there, aren’t immune to data corruption, and without the right provisions, you’d have no way of knowing whether your backups and snapshots are functional. For example, random power disruptions and excessive drive wear are the most infamous sources of drive corruption. Then there’s bit rot, which can slowly corrupt your files until the entire PBS datastore becomes irrecoverable. These problems are especially terrible for incremental snapshots that you’ve been hoarding for months – as you could end up with entire backup chains becoming useless.

As such, you should verify the integrity of your backups and snapshots every once in a while. The safest method involves randomly picking LXC and VM backups and using them to spin up new instances, but this can take a while when you’ve got virtual guests with hundreds of GBs worth of virtual drives. For Proxmox Backup Server users, this process is significantly easier because you can leverage selective restoration to test random files without recovering entire virtual guests. PBS also includes verification jobs, and I’ve scheduled them on my local and remote instances to ensure my backups remain safe and sound.

Misconfiguring the backup retention policy

Otherwise, you’ll end up running out of space

Although keeping old backups and snapshots can be helpful when you run into catastrophic problems on recent versions, hoarding too many of them can be detrimental. After all, your PBS datastore doesn’t have infinite space, and even with the right compression algorithms, keeping hundreds of snapshots for dozens of virtual guests isn’t feasible. If you’re not careful with the data retention settings, you could end up choking your server.

If you’re still relying on vzdump, you can use the Retention tab within each backup job to modify the max number of backups and snapshots your PVE node will retain for a specific period. Alternatively, PBS has dedicated prune and garbage collector jobs to ensure your storage server has enough space for future snapshots. The former is designed to get rid of old backup entries, while the latter is responsible for actually removing the data blocks. Just make sure you don’t set up the retention policies on both PVE and PBS, or you’ll end up with accidentally deleted snapshots.

Using the same backup schedule for all virtual guests

Not all VMs and LXCs have the same priority

When you’re configuring backup schedules on your Proxmox workstation, it’s a good idea to create separate automations for your self-hosted tools and virtual machines. Unless you’ve got a relatively small home lab running a few LXCs, creating frequent backups of all your virtual guests will end up choking the network’s bandwidth.

Ideally, you’d want to increase the backup frequency for mission-critical virtual guests that you tinker with fairly often, while scheduling the snapshots for rarely-used services and VMs at weekly (or even monthly) intervals.

Try not to back up everything, too

This is another problem I struggled with during my early home labbing days, but there’s no need to back up every container and VM. If you’re as deep into the automation rabbit hole as I am, deploying disposable virtual guests is as simple as running a few Terraform and Ansible scripts via Semaphore. So, your low-priority LXCs and virtual machines don’t have to hog precious space in your storage server, and you can just spin them up again if (or rather, when) things go wrong.