📰 Your Site Name

Proxmox Backup Server: 9 hardening steps for a safer homelab

2026-02-06
#homelab#proxmox#backup#cybersecurity#self-hosting#sysadmin

Backups are the thing you only notice when they fail—or when ransomware finds them first. In a homelab, Proxmox Backup Server (PBS) is fantastic because it’s fast, deduplicates well, and integrates cleanly with Proxmox VE. But “it works” isn’t the same as “it’s safe”.

This guide is a pragmatic hardening checklist you can apply in under an hour, then improve over time.

Threat model (keep it simple)

Assume:

  • One machine in your network can get compromised.
  • Your main Proxmox VE (PVE) host could be reached by an attacker.
  • Your backups must still be recoverable even if PVE is owned.

Goal:

  • Make it hard to delete backups.
  • Make PBS management hard to abuse.
  • Make it easy to detect issues early.

1) Put PBS on its own network segment

At minimum:

  • PBS should not sit on the same flat LAN as your everyday devices.
  • Create a dedicated VLAN (e.g. VLAN 30 - infra) and only allow:
    • PVE → PBS (backup traffic)
    • Admin workstation → PBS (management)
    • PBS → DNS/NTP/updates (outbound)

If you can do only one thing: segment PBS. It reduces blast radius massively.

2) Restrict the PBS web UI with firewall rules

PBS is managed via web UI + API. That means:

  • Only your admin workstation (or a jump host) should reach TCP 8007
  • Block it from the general LAN

Example firewall approach:

  • Allow admin-subnet → pbs-ip:8007
  • Allow pve-subnet → pbs-ip:8007 only if needed
  • Deny everything else to pbs-ip:8007

If your firewall supports it, geo-blocking is irrelevant here—this is internal traffic. Focus on least exposure.

3) Use separate accounts and roles (no “root everywhere”)

Best practice:

  • One admin account for UI tasks (with strong auth)
  • One or more backup-only accounts/tokens for PVE jobs
  • No shared credentials

In PBS, use:

  • Users / Realms (PBS local or PAM/LDAP if you have it)
  • ACLs to scope access to:
    • specific datastore
    • backup namespace
    • specific operations (read vs write vs prune)

A common setup:

  • pbs-admin → full admin
  • pve-backup → write backups + read own backups, but no datastore delete

4) Enable MFA / TOTP for admin accounts

If you’re logging into a management UI, MFA is worth it, even in a homelab.

  • Enable TOTP for your admin user(s)
  • Store the recovery codes in a password manager

This prevents “stolen browser password” scenarios from becoming total disaster.

5) Protect your datastore from accidental/hostile deletion

PBS allows pruning and garbage collection. Misconfiguration can wipe history.

Do this:

  • Set prune policies conservatively at first
  • Make sure you understand:
    • Prune removes old backups based on retention rules
    • GC frees space by removing unreferenced chunks after prune

Practical retention suggestion:

  • 7 daily
  • 4 weekly
  • 6 monthly

Start conservative, watch usage, then tune.

6) Use immutable-ish workflows (write-only + delayed delete)

True immutability depends on storage + filesystem features, but you can still reduce risk:

  • Use a write-only identity for backups where possible.
  • Keep delete capabilities limited to admin users only.
  • Consider a second copy (next step) that is not directly writable from the same admin plane.

If your attacker compromises PVE, they shouldn’t immediately get “delete all backups”.

7) Make a second copy (2nd target or offline-ish)

The best protection against “someone deleted everything” is a second copy that’s harder to reach.

Options:

  • Periodic sync to another PBS instance (separate VLAN, separate creds)
  • Sync to storage that isn’t continuously mounted on your main infra
  • Rotate USB disks if you’re old-school (it works!)

Even monthly “cold” copies are valuable.

8) Patch cadence + reboot discipline

PBS is a server. Treat it like one:

  • Patch monthly (or faster if a serious CVE hits)
  • Reboot after kernel/security updates
  • Don’t leave it unpatched for “later”

A boring, consistent cadence beats heroic catch-up.

9) Add monitoring (space + job failures)

You want alerts for:

  • datastore usage (space running out)
  • verification failures
  • backup job failures from PVE
  • SMART errors / disk issues

Minimum viable monitoring:

  • a nightly check that “last backup time” is within expected window
  • disk health + free space thresholds

You can do this with whatever you already run:

  • Uptime Kuma
  • Prometheus/Grafana
  • Zabbix
  • simple cron + email/webhook

What to do next

  1. Segment PBS (VLAN) and firewall the UI.
  2. Split admin vs backup identities.
  3. Add a second copy (sync or cold storage).
  4. Add monitoring for “no backup in 24h” + disk usage.

If you do those four, you’re already ahead of most setups.