Proxmox Backup Strategies: Snapshots, vzdump and Proxmox Backup Server

Answer first: the three-tier strategy

For a Proxmox host you care about, the working strategy is:

1. Snapshots for the next hour: take one before risky changes (upgrades, config surgery), roll back if it goes wrong, delete it after. Snapshots live with the VM's storage — they protect against your mistakes, not against the host.
2. Scheduled vzdump backups for the next month: snapshot-mode backups on a calendar, with retention rules, to storage that is not the same disks the VMs run on.
3. Proxmox Backup Server when the numbers grow: deduplicated, incremental, encrypted, verified backups to a second machine, synced offsite. This is where daily full-history backups of every guest become cheap enough to actually do.

And the rule that turns all of it from theatre into protection: a backup you haven't restored is a hypothesis. Schedule restore tests like you schedule the backups.

Snapshots are not backups

Worth settling precisely, because the GUI puts "Snapshot" temptingly close to "Backup". A VM snapshot freezes a point in time on the same storage the VM lives on — storage dies, snapshot dies with it. Long-lived snapshots also degrade performance and complicate storage as deltas pile up.

What snapshots are excellent for is the thing backups are too slow for: an instant undo button around a risky change. Take one, do the dangerous thing, confirm, delete the snapshot. Minutes-to-hours of lifetime — our Debian upgrade guide's "decide your rollback plan first" advice, made concrete in one click. (RAID, for completeness, is neither snapshots nor backups — that's availability, a third thing.)

Tier 2: vzdump, done properly

vzdump is Proxmox's built-in backup engine — it produces a complete, self-contained archive of a guest, restorable on any Proxmox host. The difference between "we run vzdump" and an actual strategy is four settings.

Mode: snapshot, with the guest agent

Use snapshot mode for routine schedules — it backs up running guests with at most a brief hiccup. Its consistency depends on one thing people skip: the QEMU guest agent inside each VM (qemu-guest-agent package, plus the checkbox in VM options). With it, vzdump freezes the guest's filesystems (fs-freeze/fs-thaw) at the moment of capture, so the archive contains a crash-consistent-or-better image rather than a torn one. Reserve stop mode for the guests where cold-copy certainty is worth scheduled downtime — and for databases, belt-and-braces still applies: an application-level dump (pg_dump, etc.) on a schedule inside the guest costs little and restores in ways a disk image can't.

Schedule and retention

Configure under Datacenter → Backup: which guests, when (nightly, staggered if storage is shared), and — the part that prevents both data loss and full disks — retention. Proxmox prunes by rule: e.g. keep-daily=7, keep-weekly=4, keep-monthly=6 gives you a month of daily granularity and a two-season tail, automatically pruned. Any retention rule beats the two defaults people actually run: "keep everything until the disk fills" and "keep 1".

Target: not the same disks

A backup on the storage it protects is a snapshot with extra steps. Minimum viable target: any storage that fails independently — a second local array, NFS elsewhere, or (tier 3) a PBS datastore on another machine.

Fleecing: for slow targets

If backups to a slow target (NFS over a thin link, busy HDD array) make guests sluggish, that's the guest's writes waiting on the backup target. Fleecing (--fleecing enabled=1,storage=local-lvm) buffers old blocks on fast local storage instead, decoupling guest I/O from target speed — a quiet feature that fixes the most common "backups hurt production" complaint.

Tier 3: Proxmox Backup Server

vzdump's limitation is arithmetic: every backup is a full archive, so daily backups of a 200 GB VM cost 200 GB a day, and most of those bytes are identical day to day. Proxmox Backup Server — a free, open-source companion product you install on a second machine — changes the arithmetic:

• Deduplication + incremental transfer. Data is stored as content-addressed chunks; unchanged chunks are stored once, and running VMs are backed up incrementally using QEMU dirty bitmaps — only blocks written since the last backup are even read, let alone sent. Practical effect: after the first backup, nightly backups of large VMs take minutes and cost gigabytes, not hundreds of them. (Containers get their own accelerator: the metadata change-detection mode skips unchanged files by comparing against the previous snapshot's metadata.)
• How much does dedup save? Proxmox publishes no official ratio, honestly — it depends on retention depth and how similar your guests are. Community reports commonly land in the 5–12× range with daily backups and sensible retention; a ratio near 1× usually just means retention is set to a single snapshot.
• Verification against bit rot. Scheduled verify jobs re-checksum stored chunks, so silent storage corruption is discovered before the restore that needed the data. This is PBS's quietly killer feature — cold archives rot invisibly; verified ones don't.
• Client-side encryption (AES-256-GCM): backups are encrypted before leaving the PVE host, so the PBS box — or the S3 bucket behind it — never holds plaintext. Guard the key; PBS supports a paper-printable master key for recovery.
• Offsite sync. Sync jobs replicate datastores between PBS instances (push or pull, delta-only) — a second PBS in another location turns the setup into a real 3-2-1. Since PBS 4.2, S3-compatible object storage is an officially supported datastore backend, making "offsite copy in a bucket" a first-class option too.
• Restore ergonomics: single-file restore (pluck one file out of a VM image backup from the GUI) and live-restore (boot a VM directly from its backup while it streams back — RTO in minutes for the impatient).

The deployment shape on dedicated servers is straightforward: PBS wants its own box — backups on the hypervisor protect nothing — with capacity-oriented storage (RAID-wise: raidz2/RAID 6 territory) and a fat enough pipe that restore windows are tolerable (the sizing guide's restore-window math applies: 4 TB over 1 Gbit/s is ~9 hours; 10 Gbit/s makes it under one). PVE hosts then get a nightly Datacenter → Backup job targeting the PBS datastore, PBS runs prune + garbage collection + weekly verify, and — if the data warrants it — a sync job pushes to a second location.

What about replication and Ceph?

Two adjacent features get mistaken for backups. ZFS replication (pvesr) copies guest volumes to another node on a schedule (as often as every minute) — excellent for fast failover with local storage, but it faithfully replicates every deletion and corruption within minutes; it's availability, not history. Ceph likewise: self-healing replicated storage that will preserve your ransomware-encrypted blocks with flawless redundancy. Both pair with backups (they cover the "node died" case; backups cover the "we need last Tuesday" case) — neither replaces them. More on both in the cluster and HA guide.

The restore drill

Quarterly, minimum: restore one VM to a scratch VMID (qmrestore or GUI, restore-as-new — it doesn't overwrite the original), boot it, confirm the application actually works, delete it. Twenty minutes that converts "we have backups" into "we have restores". While you're there: time it. If the timing surprises you, better now than during an incident — that's when you discover whether live-restore, more bandwidth, or better retention granularity is worth configuring.

Frequently asked questions

Are snapshot-mode backups of a running database safe?

Safe-but-improvable. With the guest agent freezing filesystems at capture, the image is consistent at the filesystem level, and modern databases (PostgreSQL, MySQL/InnoDB) recover cleanly from that — it's equivalent to recovering from a power cut, which they're designed for. What a disk image can't give you is point-in-time flexibility or easy partial restores, so for databases that matter, add application-level dumps or WAL archiving inside the guest. The combination — image backups for whole-system recovery, dumps for surgical recovery — is the grown-up answer.

How often should I back up?

Work backwards from the question "how much work can we afford to lose?" — that's your backup interval. Nightly is the standard floor for general guests; with PBS's incremental cost model, several-times-daily for hot databases is entirely affordable (and pvesr replication can shrink the availability gap to a minute alongside). The number that matters as much: retention depth. Corruption and ransomware are often discovered days late — a strategy holding only three nightly backups can rotate the damage into every copy before anyone notices.

Can PBS back up things that aren't Proxmox guests?

Yes — the proxmox-backup-client runs on any Linux host and pushes file-level backups into the same deduplicated, encrypted, verified datastores. If you're running PBS anyway, it's a natural home for the config and data of your unvirtualised machines too — one backup infrastructure, one retention policy, one place to test restores.

Does this protect against ransomware?

It's most of the answer, with two conditions. First, separation: a PBS reachable only via its API with its own credentials is not encryptable by a compromised guest — but backups written to an NFS share the hypervisor mounts read-write are. Second, history and sync: retention deep enough to reach behind the infection, verify jobs so you know the chunks are intact, and an offsite sync (second PBS or S3) that a single compromised site can't reach. PBS's client-side encryption protects your backups from the storage; access separation protects them from the attacker.

Deploying on Serverside

The natural PBS deployment here is a second dedicated server — capacity-heavy storage config, on the private network with your Proxmox hosts so nightly backup traffic never touches your public bandwidth, in a different failure domain from the host it protects. Sub-minute provisioning on ASN 55285, and the same Proxmox-ready images throughout.

The rest of the series: initial setup, networking, LXC vs VMs, and — where replication and failover take over from backups — clustering and high availability.