Which Method to Choose
| PBS + S3 | Remote PBS | vzdump + rsync | |
|---|---|---|---|
| Off-site target | S3-compatible object storage | Your second PBS server | A storage box over SSH |
| What you need | PBS 4 or later, on-site | PBS at another site | Nothing extra |
| Incremental, deduplicated | Yes | Yes | No: a full file per backup |
| Encryption | Client-side, from Proxmox VE | Client-side, from Proxmox VE | SSH in transit; the files themselves are not encrypted |
| Restore | From the Proxmox VE web interface | From the Proxmox VE web interface | Copy the file back, then restore it |
Already running PBS? Use method 1 for the off-site copy. On a single host without PBS, method 3 takes ten minutes and needs no new software.
Method 1: PBS with an S3 Datastore
Create a bucket for PBS in the Virteche dashboard (one bucket per datastore) and copy its access key. In the PBS web interface, go to Configuration → S3 Endpoints and add the endpoint: Endpoint s3.us-west.virteche.com, Region us-west, Path Style on, plus the Access Key and Secret Key. Then add a datastore with Datastore Type S3, choosing the endpoint, the bucket and a Local Cache folder. The same from the PBS shell:
proxmox-backup-manager s3 endpoint create virteche \ --endpoint s3.us-west.virteche.com --region us-west --path-style true \ --access-key 'YOUR_ACCESS_KEY' --secret-key 'YOUR_SECRET_KEY' proxmox-backup-manager datastore create offsite /mnt/datastore/offsite-cache \ --backend type=s3,client=virteche,bucket=pbs-backups
Proxmox recommends a dedicated disk or partition of 64 to 128 GiB for the cache. If the PBS server is ever rebuilt, create the datastore again with the same bucket and --reuse-datastore true, and the backups reappear:
proxmox-backup-manager datastore create offsite /mnt/datastore/offsite-cache \ --backend type=s3,client=virteche,bucket=pbs-backups --reuse-datastore true --overwrite-in-use true
Then connect Proxmox VE to the datastore as in method 2.
Method 2: Add PBS to Proxmox VE with Encryption
On the PBS server, create a user and an API token for Proxmox VE. Give the user and the token the DatastoreBackup role: a token never gets more rights than its user, and with the role on the token alone Proxmox VE reports that it cannot find the datastore.
proxmox-backup-manager user create pve@pbs proxmox-backup-manager user generate-token pve@pbs backup # note the secret "value" proxmox-backup-manager acl update /datastore/offsite DatastoreBackup --auth-id pve@pbs proxmox-backup-manager acl update /datastore/offsite DatastoreBackup --auth-id 'pve@pbs!backup' proxmox-backup-manager cert info | grep Fingerprint
In Proxmox VE, go to Datacenter → Storage → Add → Proxmox Backup Server. Enter the server's address, pve@pbs!backup as the username, the token secret as the password, the datastore and the fingerprint. On the Encryption tab choose Auto-generate a client encryption key, then download the key when Proxmox VE shows Important: Save your Encryption Key. Or from the shell:
pvesm add pbs pbs-offsite --server pbs.example.com --datastore offsite \ --username 'pve@pbs!backup' --password 'TOKEN_SECRET' \ --fingerprint 'AA:BB:...' --encryption-key autogen # the key is stored in /etc/pve/priv/storage/pbs-offsite.enc: copy it somewhere safe
Then add a nightly job under Datacenter → Backup with this storage as the target, and set its retention. Only the first backup sends everything: in our test, later backups reused all unchanged data and finished in seconds.
Method 3: vzdump and rsync to a Storage Box
Keep your normal backup job writing to local storage, and copy its files off-site after every run. First give the host an SSH key for the storage box (add the public key under SSH keys on the box's page in the dashboard) and a short name for it:
ssh-keygen -t ed25519 -f /root/.ssh/storagebox_ed25519 -N '' cat /root/.ssh/storagebox_ed25519.pub # paste into the dashboard cat >> /root/.ssh/config <<'EOF' Host storagebox HostName bend.storage.virteche.com Port 23 User sb123456 IdentityFile /root/.ssh/storagebox_ed25519 EOF ssh storagebox mkdir -p proxmox
Then a hook script. vzdump calls it at each stage of a backup job, and at job-end it mirrors the dump folder to the box:
cat > /usr/local/bin/vzdump-offsite <<'EOF' #!/bin/sh # After every backup job, mirror the local dump folder to the storage box. [ "$1" = "job-end" ] || exit 0 exec rsync -a --delete --partial /var/lib/vz/dump/ storagebox:proxmox/ EOF chmod +x /usr/local/bin/vzdump-offsite echo 'script: /usr/local/bin/vzdump-offsite' >> /etc/vzdump.conf
Because of --delete, the box keeps the same backups as the local storage, so set retention there (for example Keep Last 7 on the storage or the job). Then turn on the box's scheduled snapshots: they keep older states that nothing on the Proxmox host can delete, even if the host is compromised.
To restore, copy a file back and restore it, or restore it from local storage in the web interface:
rsync -a storagebox:proxmox/vzdump-qemu-100-2026_10_01-02_00_01.vma.zst /var/lib/vz/dump/ qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_10_01-02_00_01.vma.zst 120 --storage local-lvm
Test a Restore
Whichever method you choose, restore one VM to a new ID, boot it, and check its data before you rely on the backups. We restored each method's backup to a new VM and compared its disk with the original. For the wider picture of how many copies to keep and where, see the 3-2-1 backup rule, and for choosing between the two storage types, storage box vs object storage.