Proxmox Backup Server vs restic for VMs: The Restore That Isn’t a File Tree

restic will back up a directory until you believe you have a hypervisor strategy. The job exits zero. The repo grows. You can extract a compose file. Then the disk that held VM 105 dies and you discover that “restore” in your head was a file tree, and the thing you needed was a bootable guest with a dirty bitmap you never had. Proxmox Backup Server exists because a VM is not a folder. Treating it like one is how homelabs lose a weekend to qemu-img archaeology.

PBS versus restic is not which logo is more open. It is whether your restore drill boots a guest or unpacks a path. I run both. I do not use them as synonyms. A green Borg or restic ping is still not a restore: the drill is the product, whether the payload is a file tree or a VM.

What a VM restore actually is

A guest is firmware, disks, a machine config, maybe a cloud-init snippet, maybe a PCI passthrough you will not get back. PBS stores that as a backup that Proxmox VE can map back into a VMID. Incremental, with change tracking when the stack cooperates. File-level restore exists too, as a bonus, not as the product. The product is “VM 105 is back on node B.”

restic stores files. If you restic the qcow2 while the guest is running, you have a crash-consistent-at-best disk file and a config you hope you copied. If you shut the guest down first, you have a consistent file and an outage you scheduled. If you restic inside the guest, you have a file tree and no hypervisor identity. All three are valid for some jobs. None of them is “click restore in the datacenter UI” unless you built that UI yourself.

The failure I keep seeing is restic of /var/lib/vz or the ZFS dataset while VMs run, plus a green Healthchecks ping, plus no test of qmrestore. The ping measured a tar. The fire needs a guest.

Where PBS earns the extra VM

You already run Proxmox VE. Adding PBS is another OS and a datastore, not a religion. Dedup and prune are built for guest backups. Verify jobs catch silent corruption. Encryption is a checkbox you should turn on if the datastore is not in your bedroom. The restore drill is: pick a backup, restore to a new VMID, boot, login. Time it. That number is your RTO for “the node is gone.”

Guest agent and snapshot mode decide whether the backup is a consistent filesystem or a crash image. Databases inside the guest still want their own dump if you care about SQL, not just a bootable disk. PBS does not make Postgres dump itself. It makes the disk restorable. People collapse those. I want PBS for the VM and a dump in the guest for the database I cannot rebuild from a crash.

PBS also fails in homelab-shaped ways. The datastore fills because prune never ran. The PBS box is a VM on the same node it backs up. The network path is a 1 GbE link you share with Plex. A backup window that never finishes looks like “PBS is slow.” It is a pipe. Put PBS on a different box and a disk that is not the live pool. If PBS lives on the same rust as the VMs, you have a second copy in name only.

Where restic is still the right tool

Offsite object storage without standing up a PBS at a friend’s house. A single important directory inside a guest: /srv/immich/library, a Forgejo dump, a paperless consume folder. Hosts that are not Proxmox. A travel laptop. A Pi that is not a VM.

restic shines when the unit of restore is a path. PBS shines when the unit is a machine. If you restic every qcow2 to B2, you can get the bytes back. You will spend the incident wiring them to a new VM. If that time is acceptable, restic is enough and PBS is overhead. If you need the guest up before the household notices, PBS is the drill you should have practiced.

I restic PBS’s own config and the guest dumps. I do not restic the live disks as my only VM backup. Two tools, two jobs.

The restore that is not a file tree

File-level restore from PBS is useful when you deleted a file inside the guest and you do not want to roll the whole VM. It is not a reason to skip booting a full restore quarterly. File-level can lie about permissions, about files that were mid-write, about whether the guest agent was frozen. A boot test lies less.

restic mount is seductive. You browse the repo, you copy a file, you feel safe. Then you need eth0 to come up on a new bridge and you do not have the VM config. The file tree did not include the datacenter. Export the VM config into the same restic paths if you insist on restic-only. Better: stop insisting.

Container (LXC) backups are a third shape. PBS handles them. restic of the container rootfs is closer to a file tree and closer to “this might boot if you remember the CT config.” Still restore one on a schedule. Unprivileged containers and bind mounts will surprise you on the destination node.

A split I will leave running

PBS on a small dedicated box, datastore on CMR rust, not the ZFS special vdev of the hypervisor. Nightly guest backups for anything I cannot rebuild from compose in an hour. Verify weekly. Restore one guest to a throwaway VMID monthly. Prune after a successful verify, not before.

Inside guests that hold irreplaceable file trees, a dump plus restic to a bucket or a second disk. That restic job is not a VM backup. It is application insurance when I do not want to roll the whole disk.

Healthchecks: one ping for PBS job success, one for verify, one for the monthly boot. Green on the first only is how I used to lie to myself with Borg.

If I did not run Proxmox, I would not install PBS to pretend I do. I would restic and accept file-shaped restores, or I would pick a hypervisor that has a real backup product. PBS is not a generic agent for random Ubuntu laptops. Stretching it there is how people get angry at the docs.

When people should not add PBS

One VM that is a toy. A node you will rebuild from git. A lab you wipe monthly. restic the compose project and move on. PBS is operations. If you will not verify, you bought a second disk format to ignore.

Also skip PBS if the only datastore you can afford is the same SSD the VMs live on. Copy-on-write feelings are not a second failure domain. Buy rust or rent a bucket and restic the dumps.

Encryption, keys, and the second site

PBS encryption is not optional if the disk will ever leave the house. The key is the backup. Store it the way I store restic passwords: not only on the hypervisor that just died. A PBS datastore at a friend’s house without a key you can load on a fresh install is a sculpture.

Sync jobs between PBS datastores are how you get a second site without inventing restic-of-qcow. They are also how you fill a friend’s disk with prune policies you forgot to match. Test a restore from the remote datastore, not only a sync-complete email. Sync-complete means bits moved. It does not mean you can boot.

restic to the same friend is simpler if you only have dumps. It is worse if you expected a VMID. Do not mix “I synced PBS” and “I restic the qcow on Fridays” as two sources of truth for the same guest. Pick the machine backup. Let restic handle the SQL dump. Label the folders so 3 a.m. you does not restore last month’s disk over this week’s dump.

Performance anxiety is usually the NIC. A 50 GB guest on 1 GbE is a coffee. A 2 TB media VM on 1 GbE is a day. Exclude the media virtual disk from PBS if the media already lives on rust you back up some other way. Back up the OS disk. People include everything because the UI default is everything. Defaults are how backup windows never end and prune never runs.

The close

restic restores files. PBS restores machines. A homelab that boots guests needs at least one backup whose drill ends in a login prompt, not in a mount point. Use restic for paths and offsite blobs. Use PBS for VMIDs if you already live in Proxmox. Do not congratulate a green repo that has never started a guest.

The restore that is not a file tree is the one you will want on the day the node is quiet. Practice that one. The file tree can wait until the VM is up. If you only have time for one drill this month, boot a guest from PBS. restic mount can be next month’s half hour.