A veeam hardened repository is not a backup target with better retention. It’s a threat model. PBS prune settings and garbage collection protect you from running out of disk. A hardened repository protects you from a person who already has root on your backup server and wants your backups gone. Those are different problems, and most homelab discussions blur them.
What PBS prune actually gives you
On my Proxmox Backup Server, prune is a schedule. It looks at the datastore, matches backup snapshots against retention rules, and marks old ones for removal. Garbage collection then reclaims the chunks. This is disk-space management. It runs as the backup user, inside the PBS daemon, and it deletes data by design.
The permissions model in PBS is role-based. A user with Datastore.Modify can delete backups. A user with Datastore.Admin can change retention settings. Root on the PBS host can do anything: stop the prune job, edit the datastore config, or just rm -rf the datastore directory. Nothing in PBS stops root. That’s not a flaw; it’s just not the problem prune is solving.
If someone compromises the PBS host, they can delete every backup, every verify job, every namespace. They can also encrypt the datastore and demand ransom. Prune settings won’t save you. They’ll be the first thing the attacker changes.
What a hardened repository claims to do
Veeam’s hardened repository is a Linux server with immutable storage. The key mechanism is that once a backup file is written and the immutability period starts, no one can delete or modify it until that period expires. Not the backup admin, not root, not the storage admin. The vendor documentation says this is enforced by the filesystem and the Veeam services running with restricted capabilities.
I haven’t run one. I’m comparing against Veeam’s published architecture and the general behaviour of Linux immutable attributes. The design uses a separate Linux machine as the repository, with SSH disabled, the Veeam transport service running as a non-root user, and the backup files protected by the immutable flag. The immutability period is set per backup job, and the flag can’t be removed until the time passes.
The threat model is explicit: an attacker who compromises the Veeam backup server, or the repository itself, cannot delete or encrypt the backups. They can try, but the filesystem refuses. That’s the difference. Prune is a policy you control; immutability is a property the system enforces even against you.
Why the distinction matters in a homelab
Most homelab ransomware scenarios are not sophisticated. Someone gets into your network, finds the backup server, and deletes everything before encrypting the primary systems. If your PBS host is on the same network with no isolation, and an attacker gets root, your backups are gone. Prune settings don’t matter. The attacker just deletes the datastore.
A hardened repository would survive that. The attacker could compromise the PBS host, but the backups on the hardened repo would still be there, immutable for the configured period. That’s a meaningful difference. It’s also a lot of extra infrastructure: a separate Linux box, careful network segmentation, and a backup product that isn’t PBS.
PBS has no native immutability. You can fake it with ZFS snapshots and read-only properties, but that’s not the same. A ZFS snapshot can be destroyed by root. A read-only dataset can be made writable by root. The only real protection is to keep the backup server off the domain, on a separate VLAN, with no shared credentials. That’s a poor man’s air gap, and it works until someone finds the management interface.
I wrote about what you can actually enforce on a homelab budget in Immutable backup on Proxmox. The short version: you can’t get true immutability with PBS alone. You can get close with ZFS and careful permissions, but root always wins.
What a hardened repository costs you
Veeam’s hardened repository is not a feature you tick in PBS. It’s a separate product with its own licensing. The pricing model is per-socket or per-instance, depending on the edition, and it’s aimed at businesses. For a homelab, the cost is not just money. It’s the time to stand up another Linux box, lock it down, and learn a new backup workflow.
You also lose the tight integration with Proxmox. PBS understands Proxmox VMs and containers natively. Veeam can back up Proxmox VMs, but it’s a different agent and a different management plane. You’d be running two backup systems: PBS for convenience, Veeam for the immutable copy. That’s a real operational cost.
I run PBS because it’s simple and it works. I don’t run a hardened repository because the threat model in my homelab doesn’t justify it. If someone gets root on my PBS host, they’ve probably already got root on everything else, and the backups are the least of my problems. But if I were backing up a business, or if I had data I couldn’t afford to lose to a bored teenager with a ransomware kit, I’d think hard about a separate immutable target.
What actually happens when PBS runs out of space
Prune and GC are not just about retention. They’re about not filling the disk. When a PBS datastore fills up, backups fail. The error is usually something about no space left on device, and it shows up in the backup task log. I’ve hit that, and it’s annoying but recoverable: you prune more aggressively, or you add storage.
A hardened repository doesn’t help with that. If the immutable backups fill the disk, you can’t delete them until the immutability period expires. That’s a real operational risk. You have to size the repository correctly, and you have to monitor it. Veeam’s documentation talks about this, but it’s easy to miss until you’re staring at a full disk and a backup job that won’t run.
PBS gives you more control. You can prune manually, you can change retention, you can delete a broken backup. With immutability, you wait. That’s the trade-off: resilience against attackers, but less flexibility for yourself.
Where the two overlap
Both PBS and a hardened repository are about backup integrity. PBS verifies backups with checksums and verify jobs. A hardened repository protects backups from deletion. They’re complementary, not competing. You could run PBS for daily backups and replicate the important ones to a Veeam hardened repository for the immutable copy. That’s a belt-and-suspenders approach that makes sense for some setups.
For most homelabs, the answer is simpler. Run PBS, keep it off the domain, use a separate VLAN, and don’t reuse passwords. That’s what I do, and it’s probably enough. The moment you start worrying about a targeted attack, you need to think about immutability, and that’s where the hardened repository conversation starts.
If you’re troubleshooting PBS issues, the PBS backup host outage evidence checklist is a good place to start when things go wrong. It won’t help with ransomware, but it’ll help you figure out why your backups stopped.
If you’d rather pay for this
Veeam Backup & Replication with a hardened repository is the obvious paid option. The pricing model is per-socket for the backup server, and the hardened repository is a component you deploy on your own Linux hardware. At the time of writing, Veeam’s entry-level pricing is around $450 per socket per year, but that’s for the standard edition and doesn’t include support. The hardened repository itself is free to deploy; you pay for the Veeam license.
For a homelab, that’s a lot of money for a threat model you probably don’t have. If you’re backing up a business, it’s cheap insurance. The real cost is the time to set it up and maintain it. If you’re not willing to do that, stick with PBS and a good network design. It’s not immutable, but it’s honest.
