Proxmox PulseProxmox Backup Server 4.2 S3 Offsite Backup Setup Guide
Set up Proxmox Backup Server 4.2 S3 storage with scheduled VM and container backups, retention, and restore tests for a reliable offsite recovery plan.
On this page
Proxmox Backup Server 4.2 lets you point Proxmox backup jobs at S3-compatible object storage, so you can turn a small PBS node into a repeatable offsite backup target for VMs and containers. Follow the 12 steps below to add the S3 storage, schedule backups, set retention, and verify restores without rebuilding the plan every month.
Key Takeaways
- S3 target: PBS 4.2 stores backups in S3-compatible object storage, not just local disks.
- Offsite plan: Use a small PBS node or an existing PBS with an S3 storage target and scheduled Proxmox backup jobs.
- Verification: Run a restore test after the first backup; a backup that cannot be restored is only a hope.
- Tradeoff: Direct S3 backups are simpler but slower for restores than local PBS plus replication.
Step 1: Confirm PBS 4.2 and the S3 target
Start on the PBS node. This assumes Proxmox VE 9.1 and PBS 4.2, with the PBS API reachable from your Proxmox host. The S3 storage target lives in PBS, so the first checks belong on the PBS side.
pbs version
pbs-storage list
If the storage list is empty, that is normal for a fresh PBS node. You are about to add the first backup storage target.
Step 2: Decide direct S3 or local PBS plus replication
PBS 4.2 S3 support can be used in two ways. The simplest is to create an S3 storage target in PBS and point Proxmox backup jobs there. If you already run a local PBS with fast disk, you can keep local backups for quick restores and use an S3-backed PBS as the offsite copy. PBS still needs a local disk for the PBS node itself; S3 is the backup storage target, not a replacement for the PBS system disk.
| Approach | Restore speed | Offsite protection | Network load | Best for |
|---|---|---|---|---|
| Direct Proxmox to PBS S3 storage | Slower for large restores | Immediate offsite copy | One upload per backup | Simple offsite-only plans |
| Local PBS plus replication to S3-backed PBS | Faster local restores | Offsite after replication | Two stages, can be scheduled | Production workloads needing quick recovery |
| S3 as archive only | Slow | Long-term archive | Low if pruned | Compliance or cold storage |
For a homelab or small business plan, direct S3 is usually enough. If you have a 120 GB VM and need to restore it during business hours, local PBS plus replication is the better tradeoff. If you choose the local PBS path, put the local PBS storage on a ZFS dataset with enough space for the first full backup and let PBS manage snapshots.
Step 3: Prepare the S3 bucket and credentials
Create a bucket that only PBS can write to. Use a dedicated IAM user or object-store user, not the root account. The bucket should be in a region close to your PBS node; cross-region writes turn a 10-minute backup into a slow, expensive one.
aws s3api create-bucket --bucket my-proxmox-backups --region us-east-1
aws iam create-user --user-name pbs-backup
aws iam create-access-key --user-name pbs-backup
Save the access key and secret key. The secret key is shown once, so store it in your password manager before moving on.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/pbs-backup"
},
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts"
],
"Resource": [
"arn:aws:s3:::my-proxmox-backups",
"arn:aws:s3:::my-proxmox-backups/*"
]
}
]
}
aws iam put-user-policy --user-name pbs-backup --policy-name pbs-proxmox --policy-document file://pbs-policy.json
If your object store is not AWS, use the same idea: one bucket, one service user, and a policy limited to that bucket.
Step 4: How do you add S3 storage in PBS 4.2?
Add the S3 storage on the PBS node. The storage ID is what PBS uses internally, so choose a name you can recognize. If your object store uses path-style URLs, enable that option; MinIO often needs it.
pbs-storage add s3 s3-offsite --datacenter-id / --node pbs01 --bucket my-proxmox-backups --region us-east-1 --access-key AKIA... --secret-key REPLACE --endpoint https://s3.us-east-1.amazonaws.com
pbs-storage add s3 minio-offsite --datacenter-id / --node pbs01 --bucket my-proxmox-backups --region us-east-1 --access-key MINIO... --secret-key REPLACE --endpoint https://minio.example.com --path-style
A common gotcha is using the bucket URL as the endpoint when the provider expects a regional endpoint. The backup job can start and then fail with object-store errors. Test the endpoint in the PBS GUI before creating jobs.
Step 5: How do you connect Proxmox to the PBS storage?
Proxmox needs a PBS storage connection. Create an API token in PBS with Datacenter.Allocate, Storage.Allocate, and Storage.View. A common gotcha is giving the token only Storage.View; Proxmox can list the storage, but backup jobs fail when they try to allocate backup resources.
pvesm add pbs pbs --server pbs01 --port 8007 --username 'root@pam!proxmox' --password 'REPLACE' --datacenter-id / --node pbs01 --storage s3-offsite
The storage ID in Proxmox is the name you gave this PBS connection. In this example, it is pbs. The PBS S3 storage ID is s3-offsite. They are separate identifiers.
Step 6: Create the first VM backup job
Create a backup job for one representative VM first. Do not schedule the whole farm before you have confirmed the first backup completes. A 120 GB VM with 10 GB changed data over a 100 Mbit/s uplink often finishes in 10–15 minutes after the first full backup; the first full backup can take 20–30 minutes.
vzdump 100 --storage pbs --mode snapshot --schedule 02:00 --bandwidth 12 --retention-keep-daily 7 --retention-keep-weekly 4 --retention-keep-monthly 6
If the VM is not critical, set a later schedule and a bandwidth limit so the backup does not starve the uplink. The bandwidth value is in MiB/s, so 12 is close to a 100 Mbit/s link.
Step 7: Add container jobs for LXC and OCI LXC
Containers use the same backup job mechanism. For OCI LXC containers, the same pattern works, but confirm the container is supported by your Proxmox VE 9.1 build before adding it to the schedule. If you have already followed the OCI LXC backup to PBS 4.2 S3 guide, use the container IDs from that plan.
vzdump 200 --storage pbs --mode snapshot --schedule 02:30 --bandwidth 12 --retention-keep-daily 7 --retention-keep-weekly 4 --retention-keep-monthly 6
Stagger container jobs by 15–30 minutes if you have several large containers. This keeps the PBS node and the S3 upload from spiking at the same time.
Step 8: Set retention and prune jobs
Retention can be set in the Proxmox backup job, but PBS prune jobs give you a PBS-side mechanism for enforcing retention. Use one as your source of truth, or mirror the values in both places if you want predictable behavior. A common homelab baseline is 7 daily, 4 weekly, and 6 monthly.
pbs-prune add s3-offsite --schedule 01:00 --keep-daily 7 --keep-weekly 4 --keep-monthly 6
Do not assume old snapshots disappear just because the Proxmox job has retention values. The PBS prune job is the PBS-side cleanup path.
Step 9: How do you schedule backups without saturating the uplink?
Use the schedule to spread backups across the night. If your uplink is 100 Mbit/s, a 50 GB VM with 5 GB changed data usually takes a few minutes, but a first full backup of 120 GB can take 20–30 minutes. Add a 10–15 minute gap between jobs.
vzdump 100 --storage pbs --mode snapshot --schedule 02:00 --bandwidth 12 --retention-keep-daily 7 --retention-keep-weekly 4 --retention-keep-monthly 6
vzdump 200 --storage pbs --mode snapshot --schedule 02:30 --bandwidth 12 --retention-keep-daily 7 --retention-keep-weekly 4 --retention-keep-monthly 6
If you later add PBS replication, the PBS replication bandwidth scheduling guide covers how to throttle that second stage without stealing bandwidth from the first.
Step 10: Verify the backup and run a restore test
A backup is not complete until you can restore it. PBS can verify a snapshot before you rely on it. Run this after the first successful backup.
pbs-snapshot list s3-offsite 100
pbs-verify s3-offsite 100 <snapshot>
Then perform a real restore test. Restore the VM to a test storage or a spare node, boot it, and confirm the network, disk, and applications come up. The PBS 4.2 S3 restore test walks through that process in more detail.
Step 11: Add monitoring and a recovery runbook
Add a simple health check to your monitoring. PBS status is a good starting point, but you also need to know when a backup job fails or when a restore test is overdue.
pbs status
Put the recovery runbook in a place your team will read during an outage. It should name the storage ID, the restore test procedure, and the person who owns the offsite bucket. If your cluster started from a clean install, the Proxmox VE 9.1 homelab checklist is a good baseline for the host-level checks.
Step 12: Make the plan repeatable
Turn the setup into a repeatable plan by documenting the exact storage IDs, schedules, retention values, and restore test date. If you add a new VM or container, add it to the same backup job pattern instead of creating a one-off job.
offsite_backup_plan:
target: pbs
storage: s3-offsite
vm_job: 02:00
ct_job: 02:30
retention:
daily: 7
weekly: 4
monthly: 6
restore_test: monthly
Review the plan quarterly. S3 bucket permissions, PBS API tokens, and Proxmox storage connections all drift over time. A quarterly review catches the drift before you need the backup.
Conclusion
By the end of these 12 steps, you have a PBS 4.2 S3 storage target, scheduled VM and container backups, retention, verification, and a restore test plan. Your next step is to run the first backup, verify it, and schedule the monthly restore test.
