Feedback: lack of host backup has me reconsidering use of Proxmox

[bmac]

Proxmox VE is an impressive platform, and what the team is doing is genuinely valuable. I've been running it on one node and was about to deploy it more widely - a second and maybe third node, with plans to cluster. But the lack of built-in host backup is making me reconsider.

Part of what makes this gap stand out is that Proxmox VE presents itself as an appliance - installer, web UI, integrated VM/CT management, scheduled backups for guests, datacenter-level configuration. Users reasonably expect appliance-like behavior, including straightforward backup and restore of the appliance itself. When "backup" turns out to mean "guests only, figure out the host yourself," it's a jarring mismatch with the rest of the experience.

Cluster replication is sometimes offered as the answer, but clustering is not a backup any more than RAID is. The community workarounds (custom scripts, Clonezilla with its various gotchas, manual config.db dances) aren't trustworthy enough to depend on for disaster recovery. Documentation that implies "full backups" while only covering VMs compounds the problem. This has been raised consistently with no movement for years.

After spending considerable time trying to set up reliable host backup/restore on my existing node, I'm walking that back. I'm now evaluating plain Linux + KVM for my new machines instead, and won't be expanding Proxmox usage based on what I've found so far.

I want the Proxmox team to know this is what's driving at least one user away - from a multi-node deployment.

 

[MikeO3]

I use a PBS client but mostly for file reference restores. My recovery is reinstall an rejoin cluster but I do agree with your sentiments.

I'm now evaluating plain Linux + KVM for my new machines instead, and won't be expanding Proxmox usage based on what I've found so far.

Curious as to what backup solution you would be considering for this configuration.

 

[k12nate]

What features are you setting up on your hosts that are such great effort to deploy? Can you give specifics?

My $.02, ymmv.

As someone who recently migrated and expanded from a 3 node Vsphere cluster to 5 node Proxmox cluster and moved from Veeam to PBS. Changing my perspective on hosts made my life easier to be honest. I've converted to treating hosts as disposable in a cluster. They're compute resources. They shouldn't be doing all sorts of unique work in the host OS, VMs and LXCs should pick up any extraneous stuff.

I have my hosts built with a zfs boot mirror for boot storage redundancy, this is just to take out the "of course an SSD is going to fail here and there risk". Then, being in a cluster, joining to it adds storage, backup jobs, notifications and misc other things. There are a handful of networking configurations to build manually build, maybe some users, mapping extra hardware correctly, and ensure that the layouts match expected and they're basically done. There is a bit more setup when you start piecing in HW passthru and other features, but even then, it should be reasonably expect-able to have it scripted or documented enough to be able to rebuild quickly.

If you are spending ages building out your hosts, I think you're approach is likely incorrect if you're looking for Enterprise-like robustness. The cluster should be built robust enough that the other members should be able to pick up a host loss while rebuild is happening anyway (this is why we oversize). If you are expecting to have an environment that you could restore hosts from a file in a total hardware loss (no remaining cluster members) you have bigger problems and should change how your infrastructure is built anyway to maintain proper backup and redundancy standards.

If you lost all cluster members, the DC would be likely be obliterated, which would take out your networking, storage, misc other appliances, equip etc. If you need to be ready for this situation and turn around quickly to up and running with no expectation of long downtime, you should be planning to have a second site. Or, just have it documented well enough that in a complete disaster recovery situation that you can rebuild the cluster and have time to do so.

I get it, I really do. Host backup would be great for a "small shop" or personal homelab like setup. Ope, my host 2 died, which is based on a consumer desktop. I can just buy another desktop and stab in it's restored SSD and away I go, little time to spend, and little true cluster familiarity needed. But, unfortunately, the target of the project is for larger scale imo.

And if worse comes to worse, to handle this backup issue, crontab'ing an rsync job or rclone job to remote storage to backup the /etc/ directory to have what misc configs you have in a host, isn't a tall ask for a proficient admin.

Maybe, I'm wrong though. But, I think it's all about original approach and design, not about lacking features.

 

[alexskysilk]

like behavior, including straightforward backup and restore of the appliance itself.

I think you have a misconception of what an appliance is (or rather, what seperates an appliance from a managed software stack.)

an appliance doesnt NEED backing up. its an appliance. restoration of a failed appliance is just redeploying it.

In context of PVE, its a lot less of an appliance and more a managed stack- but the design philosophy lets you operate it as one, especially in a cluster configuration where the cluster data resides in a shared database so a member node is just another cow in the herd and neither need or wants a backup.

If you DO want to treat your pve node as a general purpose linux server rather then an appliance, you CAN use pbs to back it up. or clonezilla. or any other means you use to back up linux servers.

In over 10 years of operating pve environments I have not one had need to back up a node.

 

[gfngfn256]

I'm now evaluating plain Linux + KVM for my new machines instead

Not sure of your logic since AFAIK any backup that is available for "plain Linux" should be available on PVE, which is "plain Debian"!

While I generally agree that a complete (built-in) host node backup would be most welcome, I can't see your logic of using "plain Linux + KVM" when PVE in fact does that under the hood, plus all the managerial work around & above that.

 

[leesteken]

I came for PVE but I stayed for PBS. Using the proxmox-backup-client (which can be installed on Debian and Ubuntu), I backup (including but not limited to: /etc, /var/lib/vz/snippets and /etc/pve) to PBS and I use that to lookup configuration settings (directly from the PBS interface) when I need to (re)install and configure a PVE.

 

[SteveITS]

FWIW there are multiple threads about backing up PVE hosts to PBS, for example:
Post in thread 'Backing up PVE host ZFS boot disks to PBS'
https://forum.proxmox.com/threads/backing-up-pve-host-zfs-boot-disks-to-pbs.165169/post-767215

There is also a roadmap entry to add this as I recall.

 

[gfngfn256]

There is also a roadmap entry to add this as I recall.

Here. I'd prefer if it no longer appeared there!

 

[Johannes S]

You can backup the host the same way like any Linux Server with the backup tool of your choice. I use restic + resticprofile but any backup tool for Linux will do since in the end Proxmox products are customized Debian.
Now if you prefer to use a plain Linux Server + kvm that's fine but yiu will still need to backup it with a regular Linux backup tool. So I don't see the difference if you the lack of a host backup is a dealbreaker, a plain Linux Server lacks it too. Or did I miss something?