Protecting backups from ransomware — append-only and sync strategies

A modern ransomware attack tries two things: first encrypt your data, then delete your backups so you have to pay. If the PBS token on your compromised PVE host has full permissions on the datastore, the attacker can prune snapshots and trigger GC — backups gone.

There are three layers of protection you can combine.

Layer 1 — least-privilege permissions

The most common mistake: the PVE host uses a user with admin rights on the entire datastore. If it gets compromised, the attacker can do everything.

Solution: a dedicated user per PVE host with minimal rights:

• Datastore.Backup — may write new backups and read its own
• Datastore.Read — may read existing backups (for restores)
• NOT Datastore.Modify — no touching other backup groups, no datastore-wide prune

Set permissions in PBS under Configuration → Access Control → Permissions.

Don’t let this lull you into a false sense of security, though: according to the Proxmox docs, Datastore.Backup explicitly allows the owner to read, restore — and delete — its own backup groups. A compromised PVE host is the owner of exactly the backups it wrote. With the stolen token, the attacker can wipe out precisely those backups. What he cannot do: touch other backup groups or run a datastore-wide prune/GC.

Least privilege limits the damage but doesn’t prevent it. Real protection against deletion only comes from layer 2 (sync to a second PBS the token can’t reach) — and for individual important snapshots from the protected flag, see Prune explained.

Layer 2 — sync to a second PBS with pull-only permissions

Stronger layer: backups are mirrored to a second PBS on which the attacker has no permissions at all.

Setup:

1. Source PBS (with us): this is where the regular backups run.
2. Target PBS (separate location, your own hardware or a second xaweho plan): pulls from the source PBS regularly via a sync job.
3. The sync job on the target runs with its own user: this user only has Remote.Audit and Remote.Read on the source.
4. Your PVE host has no access to the target PBS whatsoever.

Even if the attacker destroys your entire PVE and the source PBS datastore: the target PBS holds a complete, intact copy he never got near.

This is the more robust layer — it costs a second PBS plan, but it pays off for setups with real compliance requirements.

Layer 3 — tape or append-only storage (air gap)

The ultimate layer: backups land on a medium that physically cannot be modified.

PBS natively supports tape backups (LTO). We don’t run a tape setup, so that’s not an option with us. But you can:

• Run tape locally: your own LTO drive at home or in the office. PBS regularly writes tapes that you physically unplug.
• Append-only S3: cloud storage with an object-lock policy (e.g. AWS S3 Object Lock). The backup lands as an object that cannot be deleted for N days. But: more complex in PBS, often an extra software layer.

For most private customers and small companies, layer 1 + 2 is enough.

Additional hardening measures

Limit token lifetime

API tokens on the source PBS get an expiry date. A stolen token becomes worthless at the latest when it expires. Setup:

1. Configuration → Access Control → API Token → Add.
2. Expire field: an expiry date, e.g. 90 days in the future.
3. Before it expires, generate a new token and update it in the PVE storage.

Enforce encryption

With client-side encryption, an attacker can’t read backups he steals — he can only delete or restore them.

Combined with layer 2 (a copy the attacker can’t reach at all), that’s double coverage.

Verify jobs as an early-warning system

If an attacker tampers with backup chunks, the next verification fails. Configure verify jobs at a short interval (e.g. weekly) and mail notifications, so you know immediately when something has been tampered with.

Multi-factor on the PBS admin login

If the attacker gets into the PBS via the web GUI, everything is gone. Protect the admin login with MFA: Configuration → Two-Factor Authentication → Add TOTP.

We strongly recommend MFA for every admin account.

A concrete setup for private customers

For most private customers, a pragmatic variant is enough:

1. A dedicated PBS user per PVE host: only Datastore.Backup and Datastore.Read. Keep in mind: this user can still delete its own backup groups — the protected flag and layer 2 guard against that.
2. The datastore prune job runs on the admin side: your PVE host doesn’t need modify rights.
3. Mark important snapshots as protected: a snapshot with the protected flag survives prune and manual deletion — see Prune explained. If you need protection against targeted deletion attacks, we’ll also set up a separate append-only datastore for you on request — open a ticket.
4. MFA on your PBS admin account: strongly recommended.

That protects against 95% of all ransomware scenarios.

Frequently asked questions

What happens if the attacker has my PBS admin password? He can delete everything, even with a least-privilege setup. Hence: MFA on the PBS admin login. Plus: a second PBS as a sync target adds extra protection.

Is least privilege alone enough as ransomware protection? No. With Datastore.Backup, the owner can still delete its own backups — exactly the ones a compromised host wrote. Least privilege shrinks the attack surface; against targeted backup deletion, only the sync to a second PBS or the protected flag helps.

Can I switch to least privilege after the fact? Yes, anytime. Create a new token with reduced rights in PBS, store it in the PVE storage, revoke the old token.

What if I accidentally delete backups myself? That can happen even with least privilege — the backup user can delete its own backup groups. Protection for individual important snapshots: set the protected flag. Protection for everything: sync to a second PBS with its own, longer retention.

Is an air gap realistic at home? For private customers, not really. Anyone running an LTO drive at home already has a pro setup. For most people, the combo “PBS at xaweho + sync to a second PBS” + MFA + encryption is sufficient.

Can anyone get backups through a CLOUD Act request? No. We are a German UG, hardware in Germany, no US nexus. On top of that, encrypted backups are worthless without the key — even if someone physically got hold of our disks.

What’s next

• Sync jobs — mirroring backups to a second PBS
• Creating and safely storing encryption keys
• Setting up email notifications