Proxmox Backup Server can use S3-compatible object storage through its native S3 datastore backend. Use that integration, allocate a persistent local cache and prove restoration before depending on a remote bucket. A mounted S3 bucket used as a filesystem datastore is a different design and is not the procedure described here.
As of 1 November 2026, Proxmox Backup Server 4.2 officially supports S3-compatible backends. The release also adds request and traffic statistics for S3-backed datastores. Official support for the backend does not certify every provider endpoint, account policy or network path.
Choose where S3 belongs in your backup design
A remote bucket can provide capacity outside the Proxmox VE host, but the whole recovery path still includes the backup server, network, credentials and any encryption keys. List the failure you want to survive: loss of a VM, a hypervisor, the PBS machine, your office or a storage account. One arrangement does not necessarily cover all five.
Two useful starting points are:
- A native S3-backed datastore: PBS writes to the object backend and uses local persistent cache. Consider it when remote storage will be part of routine backup and restore operations.
- A local datastore plus a second PBS: retain a local recovery copy and use PBS sync to another server whose datastore may be S3-backed. Consider it when fast local restores and an independently operated recovery site matter.
PBS remotes and sync jobs connect PBS installations. This is different from periodically copying a live datastore directory with a generic object uploader. Use a documented PBS workflow and verify the destination's snapshots, rather than assuming an interrupted filesystem copy produced a consistent backup repository.
For a small business, start with one critical workload and a written recovery objective: how much recent data can be lost, and how long can recovery take? Decide whether an internet-dependent restore meets that objective before moving every backup off site.
Qualify a European S3 endpoint before buying capacity
Ask the provider for the endpoint hostname, region value, addressing style, object and request limits, data location, charging terms and supported access controls. European billing identity and storage location are separate questions. Ask where the data and relevant replicas reside and review the terms your organisation needs.
PBS requires object read, write, list and delete permissions. It does not create the bucket or its access policy for you. Its S3 connection uses HTTPS, and the endpoint can be configured for virtual-host or path-style addressing. These requirements are described in the official S3 datastore documentation.
| Check | Evidence to collect |
|---|---|
| Connection | TLS validation, correct endpoint and region, working addressing style from the PBS machine. |
| Backup lifecycle | A completed backup, verification, file restore and controlled prune/garbage-collection trial. |
| Recovery | A restore after the canary PBS instance and its cache are unavailable. |
| Economics | Stored bytes, request counts and outbound bytes from representative jobs. |
| Operations | Alerts, credential recovery, support route and a documented ownership handover. |
DanubeData's endpoint is not claimed as tested or certified for PBS in this guide. If evaluating DanubeData object storage, run the same qualification procedure you would use for any other candidate. Compatibility is an outcome to demonstrate with the chosen versions and policy.
Set up an isolated S3-backed canary datastore
1. Create a dedicated bucket and identity
Use an empty test bucket containing no production backups. Give its dedicated PBS identity the required operations only within that bucket. Keep recovery copies of the credentials in an approved secret store, separate from the PBS machine. Enable alerts for authentication failures and unexpected usage if your monitoring supports them.
Do not add a general object-expiry rule to a live PBS bucket. PBS needs its own view of snapshot and chunk references. An external rule that deletes objects by age can remove data still required by retained backups. Evaluate bucket versioning and retention protection separately, including how they affect deletion, capacity and recovery.
2. Provision persistent local cache
The current PBS storage documentation recommends 64–128 GiB of persistent cache, preferably on a dedicated disk, partition or quota-controlled dataset. It is a recommendation to start from, not a universal sizing guarantee. RAM-only cache and converting an existing regular datastore in place are not supported by that documented setup.
Monitor both free space and latency on the cache. Reserve room for the operating system elsewhere and test alerts before the disk fills. Keep the canary path distinct from any existing datastore so an example command cannot target production storage accidentally.
3. Add the endpoint and create the datastore
In PBS, use Configuration > Remotes > S3 Endpoints to enter the provider's connection settings and credentials. Match TLS trust and addressing to its documentation. Do not disable certificate checks to get through a failed trial. Save the endpoint as eu-s3-test for this example.
After the endpoint is configured, this illustrative command creates a new datastore; replace the endpoint ID, bucket and local path with your reviewed test values:
proxmox-backup-manager datastore create eu-s3-canary \
/mnt/datastore/eu-s3-canary-cache \
--backend type=s3,client=eu-s3-test,bucket=pbs-canary-bucketThe manager command reference documents datastore creation and backend options. Keep credentials out of copied shell commands. Record the datastore name, endpoint ID, bucket, PBS version and cache path in your private recovery runbook.
Prove backup and restore with real acceptance checks
Use disposable files or a disposable VM. Include a known small file, a larger file representative of your workload and any filesystem properties you depend on. For a Linux-client trial, the following illustrates the flow after a PBS user with suitable datastore permissions exists. Replace the repository and snapshot identifier; let the client prompt for credentials:
export PBS_REPOSITORY='backup@pbs@pbs.example.net:eu-s3-canary'
proxmox-backup-client backup canary.pxar:/srv/pbs-canary
proxmox-backup-client snapshot list
proxmox-backup-client restore SNAPSHOT_FROM_LIST \
canary.pxar /srv/pbs-canary-restoredThe source directory must already contain your test files, and the restore target should be a new empty directory. The client reference describes archive specifications and restore arguments. Supply the correct key file if you enable client-side encryption.
Compare restored content against a saved checksum manifest and inspect file ownership, modes and application-specific expectations. For VMs, restore to an isolated test network and prove the guest boots. For a database, check the application's data and recovery procedure; a booting guest alone does not prove an application-consistent backup.
Record four times: backup start to completion, restore request to first usable file, full restore completion and application readiness. They answer different questions. Repeat with a representative workload before setting a service recovery target; this article supplies no measured throughput guarantee.
Next, make another backup after changing a test file. Restore both snapshots and confirm each contains the expected content. Run the canary datastore's verification task, then exercise pruning and garbage collection on disposable snapshots. PBS pruning removes snapshot metadata; garbage collection handles unreferenced chunks. A prune finishing successfully does not mean the storage bill immediately shrinks.
For general object-storage protection decisions, see S3 versioning and data protection. If the workload is PostgreSQL, our PostgreSQL backup guide covers database-specific recovery considerations.
Test recovery when the PBS server itself is lost
An object bucket full of backup chunks is useful only if a replacement system can interpret and decrypt it. Run this drill with the isolated canary first. Preserve the recovery record outside the server: endpoint details, exact datastore name, bucket, credentials, PBS configuration, encryption keys and the procedure for obtaining a new machine.
PBS configuration lives under /etc/proxmox-backup/, according to the configuration reference. Protect copies because configuration includes sensitive access material. Also document users, ACLs, backup schedules and client trust settings; recovering data and restoring normal service administration are separate tasks.
- Fence the original PBS instance. Make sure it cannot reconnect or run jobs. Do not operate the same S3 datastore from two PBS instances concurrently.
- Prepare a replacement. Install a supported PBS version, provision a fresh persistent cache and recreate the endpoint with recovered credentials.
- Reuse the existing datastore. Use its original name and bucket, following the documented recovery flags below. These flags are for a controlled takeover, not routine setup.
- Restore before restarting automation. Confirm snapshot visibility, recover a file and an isolated workload, and verify encrypted backup access with the independently stored key.
- Rebuild trust and schedules. Review PBS permissions and the certificate fingerprint expected by clients. Re-enable backup and cleanup jobs only after validation.
For the example canary, the documented takeover form is:
proxmox-backup-manager datastore create eu-s3-canary \
/mnt/datastore/recovered-eu-s3-cache \
--backend type=s3,client=eu-s3-test,bucket=pbs-canary-bucket \
--reuse-datastore true --overwrite-in-use truePBS documents reuse after the previous instance is unavailable; the original datastore name matters because it identifies the object prefix. Keep the old instance fenced throughout the drill and recovery.
Client-side encryption requires recoverable keys. A storage access key cannot decrypt client-encrypted backups. Test your independent key recovery rather than assuming the key exists somewhere on the lost machine.
Price a backup cycle and a disaster restore
Use a simple monthly model:
Monthly cost = stored data + API requests + outbound traffic
+ PBS compute/cache + independent recovery copiesDeduplication and compression mean protected VM disk capacity is not automatically equal to stored object bytes. Likewise, a single backup job can generate many object requests. Collect quantities from the canary, then a representative full cycle: initial backup, subsequent changes, verification, pruning, garbage collection and restore. Include failed jobs and retries in the operational budget.
Build a separate disaster estimate. If recovery must fetch 1 TiB and your sustained end-to-end path delivers 100 Mbit/s, the transfer-only lower bound is approximately 24.4 hours using binary TiB and decimal network units. This is illustrative arithmetic, not a benchmark: contention, request latency, decryption, destination writes and application startup add time.
Check the provider's actual egress allowance, request pricing, minimum charges and version-storage rules. Budget the cache and PBS machine even when object storage looks inexpensive. Compare options using current pricing, and retain the measured restore result beside the estimate.
Use our Linux-to-S3 backup guide for broader backup planning. Choose the final architecture according to the recovery you can demonstrate.
Frequently asked questions
Should I mount S3 and add it as a normal datastore?
For this design, use PBS's native S3 backend. A filesystem mount introduces different semantics and failure modes; a bucket appearing as a directory does not establish datastore suitability.
Is 64 GiB always enough cache?
No. The published recommendation is a starting point. Monitor your workload and measure repeated restores, cache pressure and request volume before deciding capacity.
Should I enable Object Lock for ransomware protection?
Evaluate it separately against the chosen backend, PBS cleanup behavior and your retention requirements. Do not assume provider support makes an arbitrary retention policy compatible. Test protection and deletion in a disposable bucket first.
When is the setup ready for production?
When backups, verification, routine restore, server-loss recovery, key recovery, monitoring and the cost model pass your acceptance criteria. A completed first upload establishes only one part of that result.
Sources
PBS 4.2 announcement; backup storage; manager reference; client reference; maintenance; client encryption and recovery.
