Every guide on this page exists because of the same discovery, arrived at from four different directions: a backup can look completely successful and protect nothing.
Not a corrupted archive, not a failed job, not a red light anywhere. A green tick, a sensible retention policy, a datastore filling up at a believable rate — and a gap you only find on the day you need the data back. That is the failure mode this collection is about, because it is the one that actually costs people their data. A backup that visibly fails gets fixed on Tuesday.
These are written from a single Proxmox host running a working homelab, in the order the problems tend to arrive.
1. What is actually inside the backup
The first assumption worth destroying is that backing up a container backs up what the container serves. Bind-mount a NAS dataset into an unprivileged LXC and the data lives outside the container’s rootfs — so it is not in the container backup, and nothing tells you that.
Sharing TrueNAS Datasets with Unprivileged LXC Containers in Proxmox is the setup itself: how the UID mapping works and how to get the permissions right. Read it for the mechanics, and note what the resulting backup does and does not contain.
2. What retention actually guarantees
Once the contents are right, the next assumption is that a retention policy is a protection policy. It is not. Prune and garbage collection decide what is kept; they decide nothing about who can delete it. Anyone holding datastore credentials can still take the whole history.
Immutable backup on Proxmox is about the gap between those two things — what you can genuinely enforce on your own hardware, what needs object storage with a lock on it, and what you should stop calling immutable.
3. When the backup system is the thing that breaks
Backups protect the machines they run against. They do not protect themselves. A kernel update took the backup host down here, and the question stopped being “are the backups good” and became “can I prove anything about the state of the host that holds them”.
PBS Backup Host Outage: Evidence Checklist After a Kernel Update is the checklist that came out of it — what to collect, in what order, before you start changing things and destroy the evidence.
4. Copies are not recovery
The last assumption is the biggest one. Replication gives you the data somewhere else. Recovery is an ordered runbook, boot sequencing, re-addressing, and a test you can actually run without breaking production — which is what the commercial products were selling all along.
What Replaces SRM and vSphere Replication on Proxmox? covers ZFS send/receive and the scripting around it, and is honest about the part scripting does not replace.
The short version
If you read nothing else here: check what is inside your backups before you trust the schedule, and restore something on purpose, on a day you chose. Every problem on this page is cheap to find on a Tuesday afternoon and expensive to find any other way.
This collection grows as things break. It does not cover backing up Proxmox’s own configuration, or anything at genuine business scale, because neither has happened here yet — and there is enough advice online written by people it also has not happened to.
Everything in this cluster
- Immutable backup on Proxmox: what you can actually enforce on a homelab budget (Aug 2026)
- What Replaces SRM and vSphere Replication on Proxmox? ZFS replication and a little scripting (Jun 2026)
- PBS Backup Host Outage: Evidence Checklist After a Kernel Update (May 2026)
- Sharing TrueNAS Datasets with Unprivileged LXC Containers in Proxmox for Plex/Jellyfin (Aug 2025)