Why Your Proxmox Backup Strategy Is Probably Wrong

Here's the thing about backup systems: they work right up until the moment you actually need them. And if you've set up Proxmox Backup Server the way most tutorials show—by giving your Proxmox VE cluster root access to the backup server—you've built something that technically functions but architecturally fails at the one job backups have: surviving disaster.

Tom from Lawrence Systems recently walked through what proper Proxmox backup security actually looks like, and it's worth paying attention to because this pattern applies well beyond Proxmox. The core problem is simple: if your production hypervisor has administrative access to your backup server, then a compromised hypervisor can delete your backups. The blast radius extends from "we got hacked" to "we got hacked and lost everything."

The Root Token Trap

Most people set up Proxmox Backup Server, connect it to Proxmox VE using a root token, verify the backups work, and move on. Tom admits he's done exactly this in his own lab. "Technically, it works. Architecturally, it's wrong," he says. The tutorial that gets you running isn't the tutorial that keeps you running when things go sideways.

The fix involves using scoped API tokens with least-privilege permissions. Instead of handing your PVE cluster the keys to everything, you create a dedicated backup user with limited permissions—can write backups, cannot delete them. The token associated with that user has even fewer permissions, constrained specifically to what's needed for backup operations.

Proxmox's permission model supports granular control down to individual datastores. You can create separate tokens for each system or cluster, meaning a compromise of one server doesn't automatically compromise the credentials for all your other systems. It's compartmentalization 101, but surprisingly rare in practice.

The Off-Site Problem

The more interesting architectural issue comes with off-site backups. If you're pushing backups from your local Proxmox backup server to a remote one, you've extended that blast radius again. A compromised local server with write access to the remote backup can push corrupted or deleted data offsite.

The solution is a pull model: the remote backup server reaches back to the local one using a read-only token and pulls the data. "This is the ideal way to set it up because that way your off-site backups have a token that only gives them readonly access to your local Proxmox backup server," Tom explains. If someone compromises your remote server, they get a copy of your backups but can't reach back and delete the originals. If someone compromises your local server and deletes backups, the sync job won't replicate those deletions to the remote.

This creates a housekeeping requirement: you need separate prune jobs on each backup server. The local PVE can't delete old backups (by design), and the remote server won't auto-delete based on what happens locally (also by design), so storage will fill up unless you explicitly configure retention policies on both sides. That's not a bug—it's acknowledging that backup lifecycle management and backup security are separate concerns that need separate controls.

What Actually Changes

The practical workflow looks like this: create a dedicated backup user on your Proxmox Backup Server, assign it datastore-level permissions (not system-wide admin), generate an API token scoped to that user, and use that token when configuring the storage connection in Proxmox VE. The backup user gets "DataStore.BackupPowerUser" permissions, the token gets "DataStore.Backup" and "DataStore.Reader" permissions.

For off-site replication, you create a separate remote pull user with only "DataStore.Reader" permissions, generate a token for that user, and configure your remote backup server to pull using those read-only credentials. The remote server gets its own admin user for managing prune jobs and verification tasks locally.

Tom walks through testing the setup by attempting to delete a backup from the PVE interface. It fails—as it should. "This is something to note when you're building backup jobs because you cannot prune them from the PVE environment here. They do not have any delete access." The system works by limiting what each component can do, not by trusting each component to behave.

The Permission Granularity Question

There's a judgment call around whether to use "DataStore.PowerUser" or "DataStore.Admin" permissions for your backup user. PowerUser can read and write backups but can't manage prune jobs or verification schedules. Admin can do everything within that datastore. If you're a solo admin, giving the backup user Admin rights to its assigned datastore isn't particularly risky—it's still scoped below root access. In a team environment with junior admins, you'd want separate roles.

The deeper principle is about blast radius and token lifecycle. API tokens don't have two-factor authentication. They're designed to stay in the system. Creating them per-server or per-cluster means you can revoke a single compromised token without regenerating credentials everywhere. It's slightly less convenient—more tokens to track, more accounts to manage—but compartmentalization is inherently less convenient than a single shared secret.

Tom's approach is pragmatic about these tradeoffs. For home labs and small deployments, giving one backup user admin rights to the datastore while keeping tokens separate per system hits a reasonable balance. For production infrastructure with multiple administrators, you'd want more granular role separation. The permission model supports both.

Pattern Recognition

This isn't really about Proxmox. The same architectural mistake appears everywhere: production systems with excessive permissions to backup infrastructure, backup jobs running with admin credentials, off-site replication using push models that extend trust boundaries. The tooling differs but the vulnerability is structural.

Proxmox actually gets credit for building a permission system granular enough to do this properly. Many backup solutions assume full trust between components or treat security as an enterprise add-on. The capability exists here—it's just not the default path.

The test of a good backup system isn't whether it can restore last Tuesday's database. It's whether it can restore last Tuesday's database after an attacker spent three weeks in your infrastructure specifically trying to prevent recovery. That scenario requires assuming compromise and building recovery paths that don't depend on the same credentials or trust relationships that failed initially.

Tom's guide—available in detail on the Lawrence Systems forums—maps out the specific permission grants and token configurations. The transcript cuts off before finishing the remote backup setup, but the pattern is established: separate credentials, minimal permissions, pull-based replication, independent lifecycle management. The specifics matter for implementation, but the architecture is what determines whether your backups survive the scenarios they're actually meant to address.

— Mike Sullivan, Technology Correspondent