Proxmox VE makes it easy to back up virtual machines and containers, but the default setup keeps those backups close to the cluster. This guide explains the backup options Proxmox offers, how Proxmox Backup Server changes the picture, and how to add an offsite copy in the cloud that you can actually restore.
Why Proxmox backups need an offsite copy
A typical first installation stores backups on a local directory, an NFS share on a NAS, or a Proxmox Backup Server (PBS) in the same rack. That protects you against the most common problem, a deleted or broken VM. It does not protect you against events that affect the whole location: a fire, a power surge, theft, a flooded room, or ransomware that reaches the backup server with stolen credentials.
The classic 3-2-1 rule asks for at least one copy in a different location. For Proxmox, that usually means a second PBS in another site, a PBS datastore backed by object storage, or archives copied to S3-compatible cloud storage.
Proxmox VE backup options
Proxmox VE includes vzdump, the tool behind every backup job you configure in Datacenter → Backup. It backs up QEMU/KVM virtual machines and LXC containers, including their configuration, into a single archive or into a PBS datastore.
Backup modes
| Mode | What happens | When to use |
|---|---|---|
snapshot | The guest keeps running. For VMs, QEMU tracks writes during the backup; with the QEMU guest agent installed, file systems are frozen briefly for consistency. | Most production VMs. Install the guest agent. |
suspend | The guest is suspended during part of the process to reduce inconsistency. | Rarely needed; mainly for containers on storage without snapshot support. |
stop | The guest is shut down, backed up and started again. | Maximum consistency when a short downtime is acceptable. |
Even in snapshot mode, a database running inside a VM is only crash-consistent unless the guest agent freezes the file system or the application flushes its data. For critical databases, combine VM backups with application-level dumps, as explained in our MySQL backup guide.
Running vzdump manually
The web interface covers most needs, but the command line is useful for one-off backups and scripts:
# Back up VM 100 to the storage "backup-nfs" with zstd compression
vzdump 100 --mode snapshot --compress zstd --storage backup-nfs
# Back up all guests on this node and apply a retention policy
vzdump --all --mode snapshot --storage backup-nfs \
--prune-backups keep-daily=7,keep-weekly=4,keep-monthly=6When the target is a regular storage (directory, NFS, CIFS), every run produces a complete archive such as vzdump-qemu-100-2026_10_19-02_00_01.vma.zst. That is simple and portable, but each archive has the full size of the guest after compression.
Proxmox Backup Server
Proxmox Backup Server is a separate product that you install on its own machine or VM. Proxmox VE sends backups to it as if it were another storage, but the way data is stored is very different:
- Deduplication: data is split into chunks identified by their hash. Identical chunks are stored once, across all backups of all guests in the datastore.
- Incremental VM backups: for running VMs, QEMU keeps a dirty bitmap of changed blocks, so the next backup only reads and sends what changed.
- Client-side encryption: backups can be encrypted on the Proxmox VE host before they reach PBS.
- Verification, pruning and garbage collection: verify jobs re-read chunks and check their checksums; prune jobs apply retention; garbage collection removes chunks no longer referenced.
- Sync jobs: a PBS can pull from, or push to, another PBS, which is the standard way to create an offsite copy.
Adding a PBS datastore to Proxmox VE can be done in Datacenter → Storage → Add → Proxmox Backup Server, or with pvesm:
pvesm add pbs pbs-main --server 10.0.0.20 --datastore store1 \
--username backup@pbs --fingerprint 'AA:BB:...:FF' --passwordFull and incremental backups in practice
It helps to separate two ideas: how much data is transferred and how much data is needed to restore.
- A vzdump archive on file storage is a full backup: large to transfer, but self-contained.
- A PBS snapshot is transferred incrementally, yet every snapshot is logically complete. You can restore any snapshot directly, without replaying a chain of increments, because the datastore references all chunks it needs.
The dirty bitmap only lives while the VM process runs. After a VM is stopped and started, or the host reboots, the next backup has to read the whole disk again. It still uploads only the chunks PBS does not have, but it takes longer and generates more disk I/O. Plan maintenance windows with that in mind.
Options for an offsite copy
1. A second Proxmox Backup Server in another location
This is the most common design: a local PBS for fast restores and a remote PBS that pulls the backups with a sync job. The remote server can be in another office, a colocation rack or a provider that offers PBS hosting. Because sync jobs transfer only missing chunks, daily synchronization is efficient after the initial copy.
# On the offsite PBS: define the primary server as a remote
proxmox-backup-manager remote create primary --host 203.0.113.10 \
--auth-id sync@pbs --password 'xxxx' --fingerprint 'AA:BB:...:FF'
# Pull the datastore every night
proxmox-backup-manager sync-job create pull-primary --store offsite \
--remote primary --remote-store store1 --schedule dailyPull mode has an important security property: the primary server does not hold credentials that can delete data on the offsite server.
2. A PBS datastore on S3-compatible object storage
Proxmox Backup Server 4.0 (August 2025) introduced S3-compatible object storage as a datastore backend, initially as a technology preview. The official roadmap lists the backend as fully supported from version 4.2. With it, a PBS can keep its chunk store in a bucket while using a local cache, which makes cloud object storage a natural offsite target. Read the documentation for your exact version before relying on it.
3. Copying vzdump archives to S3
If you do not use PBS, you can upload the archives produced by vzdump to S3-compatible storage with tools such as rclone or the AWS CLI. It works, but every upload is a full archive, so bandwidth and storage grow quickly. Encrypt the archives before or during upload if they leave your network.
# Upload last night's archives and keep the bucket in sync
rclone copy /mnt/pve/backup-nfs/dump remote-s3:proxmox-backups/node1 \
--include "vzdump-*.zst" --transfers 4 --checksumS3 considerations
- Initial seeding: the first upload of several terabytes can take days on a regular connection. Estimate it: 2 TB at a sustained 200 Mbit/s takes roughly 22 hours.
- Request and egress pricing: deduplicated stores create many small objects. Check request charges and, above all, the cost of downloading data during a restore.
- Lifecycle rules: never apply automatic expiration rules to a PBS chunk store. Retention must be handled by PBS prune and garbage collection, otherwise chunks still referenced by snapshots may disappear.
- Immutability: S3 Object Lock and versioning protect against deletion, but they interact with garbage collection. Test the combination before production.
- Encryption keys: if you enable PBS client-side encryption, keep the key (and its paper backup) outside the cluster. Without it, the offsite copy is unreadable.
- Region: choose a region that satisfies your data residency requirements and is far enough from your primary site to avoid shared risks. See Backnix cloud storage for how regions are handled.
Backup verification
A backup job that reports "OK" means the data was written, not that it can be read back later. On PBS, schedule verify jobs so chunks are periodically re-read and checked; verification of new snapshots can also be done right after the backup. For vzdump archives on file storage, you can at least test the compression layer:
zstd -t /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2026_10_19-02_00_01.vma.zstThis detects corruption of the file but does not prove the VM boots. Only a restore test does that.
Restore testing
Restore to a new VMID so you never overwrite the production guest, ideally on a different node or an isolated network:
# Restore a vzdump archive as VM 9100, generating new MAC addresses
qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-100-2026_10_19-02_00_01.vma.zst 9100 \
--storage local-lvm --unique
# Restore a container archive as CT 9200
pct restore 9200 /mnt/pve/backup-nfs/dump/vzdump-lxc-200-2026_10_19-03_00_02.tar.zst \
--storage local-lvmFrom a PBS storage, the same commands accept the backup volume ID shown in the storage content view, for example pbs-main:backup/vm/100/2026-10-19T02:00:01Z. After the restore, boot the guest with networking disconnected, check that services start and that the application data is recent. Record how long the restore took: this is your real recovery time, which we discuss in RPO vs RTO.
Common mistakes
- Keeping the only PBS in the same rack, on the same power circuit, as the hypervisors.
- Letting the production cluster hold credentials that can delete offsite backups.
- Forgetting the QEMU guest agent, which leaves database VMs only crash-consistent.
- Applying S3 lifecycle expiration to a deduplicated chunk store.
- Enabling encryption and storing the only copy of the key on the Proxmox host.
- Never restoring a backup until the day it is needed.
- Not backing up host configuration (
/etc/pve, network settings), which matters when rebuilding a node, as covered in our Proxmox disaster recovery guide.
Next steps
- List your guests and decide which need snapshot mode, stop mode or additional application dumps.
- Deploy a Proxmox Backup Server if you still back up to plain file storage.
- Choose your offsite target: a remote PBS with a pull sync job, an S3-backed datastore, or archive uploads.
- Schedule verify jobs and a quarterly restore test on separate hardware.
- Store encryption keys and recovery documentation outside the cluster.
Backnix is designed to provide the offsite layer for Proxmox environments. You can follow the status of the Proxmox backup integration on its page.