How Proxmox Backup Server uses Ceph RGW as an S3 datastore
Yes, Proxmox Backup Server (PBS) can keep its backup data in an S3-compatible object store instead of a local disk, and Ceph RGW is a workable example of that store. A team moving backups off local disks should understand that PBS treats the object store as the datastore backend, but it still needs local disk space for a cache. Plan both before creating the datastore, because the cache is a separate design decision with its own sizing. The Proxmox Backup Server storage documentation describes the supported S3 configuration, and the example there uses a self-hosted Ceph RGW endpoint with a plain IP address, port 7480, a self-signed certificate and path-style addressing.
PBS does not create buckets for you. Create the bucket in RGW first, then give the PBS access key only the permissions the datastore needs: get, put, list and delete. Missing list or delete permissions tend to surface later as failed pruning or garbage collection, not at setup time, so test those operations on a scratch bucket before you rely on the datastore. PBS also refuses plain-text communication with the S3 API, so the RGW endpoint must be reached over HTTPS. Confirm the certificate chain and fingerprint PBS will pin, especially if you use a self-signed certificate as the example does, and record who renews it and when.
The local cache is still required. An S3 datastore needs a persistent cache, and the documentation recommends 64 GiB to 128 GiB on a dedicated disk, partition or ZFS dataset. Keep it off the disks that hold the PBS operating system and the RGW data pool, and confirm the cache is persistent across reboots and sized for your chunk churn. Losing the cache does not lose backups, but it changes restore and verification performance, so treat it as infrastructure to monitor, not as scratch space.
What you need before creating the datastore
A Proxmox Backup Server S3 datastore on Ceph RGW depends on six things lining up: the PBS release, a reachable RGW endpoint, a pre-created bucket, a scoped RGW user, a trusted certificate and a local cache disk. Confirm each one in your own environment before you touch the PBS storage configuration, because a gap in any of them usually shows up as a failed datastore creation.
Proxmox Backup Server 4.2 or later
Support for S3-compatible object store datastores moved from technology preview to full support in PBS 4.2, which was released on April 29, 2026. Check the installed version on every PBS node that will use the datastore, and confirm with your team whether your change policy allows that upgrade on the backup server before you plan the datastore layout. Running an older release means the S3 datastore is still in technology preview, which is a different support position to raise with your vendor contact.
Reachable RGW endpoint
PBS connects to the Ceph Object Gateway over the network, so the endpoint must be routable from every PBS node, not only from your admin workstation. Confirm the address, port and DNS name the datastore will use, and check that firewalls between the PBS hosts and the RGW hosts allow that port. Record the endpoint exactly as it will be configured, because the same value must match the certificate you install later.
Pre-created bucket
PBS does not create buckets, so the bucket must exist on RGW before the datastore is defined. Agree the bucket name, region and any versioning or Object Lock setting with the storage owner, and record who owns the bucket lifecycle. Creating the bucket in advance also lets you confirm that the RGW user can see it before PBS tries to use it.
Dedicated RGW user with scoped rights
Create a separate RGW user for PBS rather than reusing an administrator or another application's key. PBS needs get, put, list and delete permissions on the bucket, so grant those and no broader rights. Store the access key and secret in your secrets process, and plan how you will rotate them, since the PBS datastore must be updated when keys change.
HTTPS with a trusted or pinned certificate
PBS does not support plain-text communication with the S3 API, so the RGW endpoint must serve HTTPS. Proxmox's own example uses a self-signed certificate, which you should replace or pin with a certificate fingerprint for production. Confirm with your PKI or security team which certificate chain PBS will trust, and whether the fingerprint will be recorded in your change records.
Local cache disk sized 64 to 128 GiB
An S3 datastore still needs a local persistent cache on a dedicated disk, partition or ZFS dataset, and the documented recommendation is 64 GiB to 128 GiB. Do not share this cache with the operating system or other PBS data, and confirm the disk is on storage that survives a PBS host rebuild. Plan the cache size with your team against expected chunk activity, since the recommendation is a starting range rather than a sizing result.
Configuring the S3 datastore step by step
This sequence connects a Proxmox Backup Server datastore to a Ceph RGW bucket over HTTPS, then proves the path end to end. Each step closes with a check, so a fault surfaces at the layer where it occurs before any backup depends on it.
Create the bucket and scoped RGW user
Create the bucket first, because Proxmox Backup Server does not create buckets. Then create a dedicated RGW user for this datastore and generate its access key pair, granting only the permissions the datastore needs: get, put, list and delete. Keep this user separate from administrative and other application accounts so the key can be rotated or revoked without affecting them. Done when a client using only these keys can list the bucket and write, read and delete a test object.
Verify HTTPS and path-style addressing
Confirm that the RGW endpoint answers over HTTPS before adding it to PBS, because Proxmox Backup Server does not support plain-text communication with the S3 API. Use path-style addressing, where the bucket name sits in the URL path, as the PBS example for self-hosted Ceph RGW does. That example uses a plain IP endpoint on port 7480 with a self-signed certificate, so your host and port may differ. Done when a request to the bucket path over HTTPS returns a valid S3 response from the host the datastore will use.
Add the S3 endpoint and keys in PBS
In the Proxmox Backup Server web interface, add an S3 endpoint with the RGW host, port, bucket name and the access key pair from the first step. The menu location varies by PBS version, so confirm it in the current storage documentation before you start. Enter the scheme, host, port and path-style setting exactly as they worked in the previous check. Done when the endpoint is saved and PBS can reach the bucket. If the connection fails, resolve it before moving on rather than changing the datastore settings.
Pin the certificate fingerprint if needed
If the RGW certificate is self-signed or issued by an internal CA that PBS does not trust, record its fingerprint and pin it in the endpoint configuration. Read the fingerprint from the certificate on the RGW host through a trusted channel, then compare it with the value the TLS handshake presents. Pinning ties trust to one certificate, so schedule a fingerprint update at every certificate renewal. Done when the endpoint test succeeds with the fingerprint pinned and the fingerprint matches the certificate in use.
Create the datastore on the local cache
Create the datastore on the S3 endpoint and point its local cache at a dedicated disk, partition or ZFS dataset. The S3 datastore needs this persistent cache, and the PBS storage documentation recommends 64 GiB to 128 GiB. Size it with growth in mind, and keep it off the operating system disk so cache activity does not compete with the host. Done when the datastore shows as active in PBS and the cache location reports the capacity you planned.
Run a test backup to the datastore
Back up a small, non-production virtual machine or container to the new datastore, using a Proxmox VE backup job or the proxmox-backup-client tool. A small guest keeps the test short and limits network and cache load. Review the task log for errors, then confirm the snapshot appears in the datastore content view. Done when the backup task finishes without errors, the snapshot lists the expected guest, and objects appear in the Ceph bucket.
Restore the test backup and verify
Restore the test snapshot to a separate, isolated target, such as a new guest ID on a test node. Do not restore over a production guest for this test. Compare known files or run an application check against the source to confirm the data is usable. Done when the restored guest starts or the files match the source, and the restore log shows no errors.
Why the local cache still matters for an S3 datastore
An S3 datastore in Proxmox Backup Server does not read and write chunks directly against the object store alone. It keeps a local persistent cache on the backup server, and the documented recommendation of 64 GiB to 128 GiB sets the starting point for that disk, partition or ZFS dataset. Treat the cache as part of the datastore's performance design, not as optional scratch space. Without it, every chunk lookup that misses the cache becomes a round trip to Ceph RGW, so the object gateway and the network path between the backup server and RGW determine how fast backups, verification and restores run.
An undersized cache shows up first in verification and garbage collection, which touch many chunks and metadata entries, and then in restores, where repeated reads of the same chunks can degrade into object store requests. Placing the cache on shared storage adds a second risk: the cache competes with other workloads for I/O, and its latency becomes the latency of that shared pool. A dedicated disk gives the most predictable behavior. A partition on a local disk is simpler to provision. A ZFS dataset fits hosts already built on ZFS but brings its own memory and recordsize choices. Each option trades provisioning effort against how quickly you can rebuild or replace the cache after a failure.
Recovery time is the trade-off to plan around. The cache is persistent, so a failed cache disk means the datastore must be rebuilt or re-warmed before it performs as it did, and restores during that period will be slower. Confirm the cache size against your own snapshot count, retention policy and daily change rate, because the recommended range is a general guideline rather than a sizing result for your environment. Ask your Proxmox and Ceph administrators to measure the chunk working set during a representative restore test, and document who rebuilds the cache and how long that is expected to take on your hardware.
Mapping PBS storage fields to Ceph RGW settings
This table maps each Proxmox Backup Server S3 datastore field to the Ceph RGW value it takes, where that value comes from, and the permission or setting it depends on. Read it as a checklist before you create the datastore, and note where the documented example differs from a production setup.
| PBS field | Ceph RGW value | Source and dependency |
|---|---|---|
| Endpoint host | IP address or DNS name of the RGW endpoint | The PBS example uses a plain IP address with a self-signed certificate. In production, use a DNS name that matches the certificate's subject or alternative name. |
| Port | RGW listening port, 7480 in the PBS example | Confirm the port your RGW service or load balancer actually exposes. The port must serve HTTPS, since PBS does not allow plain-text S3. |
| Bucket | Existing bucket name | PBS does not create buckets, so create the bucket in RGW first with the RGW user or admin tooling you use. |
| Access key and secret key | Access and secret key pair of an RGW user | Generated for the RGW user that owns or is granted access to the bucket. Keys are shown by RGW when created, so store them in your secrets system. |
| Required permissions | Get, put, list and delete on the bucket | Grant these to the RGW user. Without them, datastore operations fail. Check the bucket policy or user capabilities you use. |
| Path-style addressing | Enabled, so requests go to the endpoint host with the bucket in the path | Required for the self-hosted example. Confirm path-style access is set in the PBS datastore options before testing. |
| Certificate fingerprint | SHA-256 fingerprint of the certificate RGW presents | Read it from the certificate served on the endpoint. It changes when the certificate is renewed or replaced, so plan an update step. |
| Local cache path | Dedicated disk, partition or ZFS dataset on the PBS host | Not an RGW setting. PBS needs a local persistent cache, with 64 GiB to 128 GiB recommended by the PBS storage documentation. |
Securing the datastore connection and the keys
A PBS S3 datastore moves backup data off the host and onto an endpoint you operate, so the connection, the RGW credentials and the encryption keys all need deliberate controls. The cards below cover the transport, the access scope, certificate pinning, key handling and network placement, and they note which controls sit in PBS and which sit in your Ceph environment.
Require HTTPS for the endpoint
Proxmox Backup Server does not support plain-text communication with the S3 API, so the RGW endpoint must be served over HTTPS. The Proxmox example uses a plain IP endpoint on port 7480 with a self-signed certificate, which is a starting point for a lab, not a production pattern. Confirm that the RGW certificate chain, its subject names and the endpoint address match what you enter in PBS, and confirm the TLS settings on the RGW side in your environment.
Scope RGW users to one bucket
PBS does not create buckets and needs get, put, list and delete permissions to work. Create a dedicated RGW user for the datastore, grant only those actions on the backup bucket, and keep it separate from administrative and application users. Confirm in your environment that no broader bucket policy or account-level permission gives this user access to other buckets, and that the user cannot manage other users or quotas.
Pin the certificate fingerprint
When the endpoint uses a certificate that PBS does not trust through the system store, the datastore configuration can carry a certificate fingerprint so that PBS checks the server identity on each connection. Record the fingerprint from the certificate you deployed, verify it out of band, and document the owner of the certificate. Confirm the exact field and behavior in the current PBS storage documentation before you rely on it.
Plan certificate rotation
A renewed or reissued RGW certificate changes the fingerprint, and a pinned value that no longer matches will stop datastore access. Before a rotation, schedule the new fingerprint update in PBS, test one datastore operation, and keep the previous certificate available until the change is verified. Ask your certificate owner for the renewal date and the notification process so that backups are not interrupted without warning.
Store and rotate S3 keys
The RGW access key and secret key live in the PBS datastore configuration and authenticate every backup and restore operation. Restrict who can read the PBS configuration on the host, keep the keys out of shared notes and tickets, and rotate them on a schedule you set. After each rotation, confirm that the old key is disabled in RGW and that backups still complete. Confirm how your organization stores these secrets and who approves rotation.
Encrypt backups before upload
PBS offers client-side encryption with AES-256-GCM, so backup chunks can be encrypted before they reach the object store. This matters because the RGW operator and anyone who reads the bucket would otherwise see backup content. Decide who holds the encryption key, back up that key separately from the datastore, and test a restore with the key alone. Losing the key makes encrypted backups unreadable, and the PBS documentation sets out how encryption keys are managed.
Keep the endpoint off untrusted networks
The RGW endpoint should be reachable only from the PBS host and the administrative networks that manage it. Place it on a management or storage segment, restrict inbound access with firewall rules, and avoid publishing the S3 port to the internet or to general user networks. Confirm the network path, any load balancer or proxy in front of RGW, and the access logs you keep for the bucket in your environment.
Common errors when PBS cannot reach the RGW datastore
This table lists the failures most often seen when Proxmox Backup Server cannot use a Ceph RGW bucket as an S3 datastore, with the likely cause and a check you can run for each. Work through the rows in order, since a TLS or endpoint problem can hide permission and addressing errors until the connection succeeds.
| Symptom | Likely cause | Check or fix |
|---|---|---|
| Certificate verification fails on connect | RGW uses a self-signed certificate that PBS does not trust, so the TLS handshake is rejected. | Record the certificate fingerprint and enter it in the datastore configuration, then confirm the fingerprint matches the one RGW presents on port 7480. |
| Endpoint rejected as plain text | PBS does not support plain-text communication with the S3 API, so an endpoint configured with http:// fails. | Change the endpoint to https:// and confirm RGW serves TLS on the port you configured, for example 7480 in the documented example. |
| Requests fail or go to the wrong host | Path-style addressing is not enabled, so PBS builds a virtual-host URL that RGW cannot resolve for a plain IP endpoint. | Enable path-style addressing in the datastore settings, then confirm the endpoint is an IP address or hostname that resolves to the RGW service. |
| Datastore cannot find or create its bucket | PBS does not create buckets, so the bucket was never created on RGW or the name differs from the configured one. | Create the bucket in advance with the RGW administration tools, then compare its exact name with the datastore configuration. |
| Backups or sync fail with access denied on write | The RGW user lacks put permission on the bucket. | Confirm the user holds put, get, list and delete permissions on the bucket, and test each one with an S3 client before rerunning the job. |
| Pruning, garbage collection or listing fails | The RGW user lacks list or delete permission, which PBS needs to clean up old chunks. | Grant list and delete alongside get and put, then run a prune job on a test datastore and review the task log. |
| Local cache fills and jobs stop | The cache disk is too small for the workload, or it is shared with other data and runs out of space. | Place the cache on a dedicated disk, partition or ZFS dataset, check free space with a standard disk usage command, and size it within the documented 64 GiB to 128 GiB recommendation or above it as your data grows. |
Questions buyers ask before setting up PBS on Ceph RGW
What does setting up a Proxmox Backup Server datastore on Ceph RGW involve?
It is a configuration and integration task that spans the Ceph side and the PBS side: a dedicated bucket and an RGW user with get, put, list and delete permissions, HTTPS on the gateway with a certificate PBS will trust, the endpoint and path-style addressing set in the PBS storage configuration, and a local cache disk for the datastore. Effort rises with the number of datastores, how the certificate is issued and distributed, whether the RGW endpoint sits behind a load balancer, and how many PBS servers share the same bucket. Proxmox Backup Server does not create buckets, so the bucket must exist before the datastore is added. The Proxmox Backup Server storage documentation lists the requirements that shape the work.
Can our own team set up PBS on Ceph RGW without outside help?
A team with working Ceph RGW administration and Proxmox Backup Server experience can do it, provided it can test restores end to end. The points that most often need experience are certificate handling, since PBS does not accept plain-text S3 and the documentation example uses a self-signed certificate, and cache sizing, because the local cache must be on a dedicated disk, partition or ZFS dataset. A partner is most useful when the environment is regulated, the RGW cluster is shared with other workloads, or the team has not yet run a restore from an S3-backed datastore. Whichever route you take, ask for the written scope, deliverables and test plan before work starts.
What do we need to provide before the work starts?
Plan to provide the following before any configuration begins:
- RGW access: an endpoint reachable from the PBS host, an access key and secret for a dedicated user, and permission to create or name the bucket.
- Certificates: an HTTPS certificate for the RGW endpoint and a method to make PBS trust it, whether a internal CA or a fingerprint pinned in the datastore configuration.
- Cache disk: a dedicated disk, partition or ZFS dataset for the local persistent cache, sized within the recommended range of 64 GiB to 128 GiB from the PBS storage documentation.
- A test window: time on the Ceph cluster and the PBS server for backup, sync and restore tests that can run without disturbing production.
Confirm the exact RGW version and TLS settings with your Ceph administrators before scheduling.
How long does setup take in our environment?
No duration is fixed by the supplied facts, so the honest answer depends on what already exists. A single PBS server pointing at an RGW bucket with a trusted certificate and a prepared cache disk is the simplest case. Time grows when the certificate authority must be created or distributed, when the RGW cluster needs TLS changes, when several datastores or PBS servers need separate users and buckets, or when restore testing reveals issues with network paths or cache sizing. Ask for a written timeline in the quote that separates preparation on the Ceph side, the PBS configuration and the restore tests, and say which of those your team will own.
What ongoing work recurs after the datastore is live?
The recurring tasks are certificate rotation before the RGW certificate expires and whenever it is reissued, rotation of the RGW access key used by PBS, monitoring of the local cache disk for space and health, and upgrades of Proxmox Backup Server itself. Each change can break the connection, so test a backup and a restore after every rotation or upgrade. Schedule a periodic restore test, because a datastore that writes successfully can still fail on read. Ask any partner whether these tasks are covered by a fixed-scope engagement or a retainer, and who receives alerts when the cache or the endpoint fails.
How do Proxmox Backup Server subscription tiers relate to this integration?
The S3 datastore integration does not require a subscription. Proxmox says all Proxmox Backup Server features are available at every subscription level, which differ only in support entitlement. Per server per year, the listed prices are 560 euros for Community, 1,120 euros for Basic, 2,240 euros for Standard and 4,480 euros for Premium, according to the Proxmox Backup Server pricing page. Basic includes 5 support tickets a year with a one business day response, Standard 15 tickets with a 4-hour critical response and Premium unlimited tickets with a 2-hour critical response. Choose the tier based on how much vendor support you need, not on access to the integration. A DeployOpen engagement is separate from any Proxmox subscription.
Does Proxmox Backup Server support S3 datastores in production?
Yes, with a version condition. Proxmox Backup Server 4.2, released on April 29, 2026, moved S3-compatible object store datastores from technology preview to full support, according to the Proxmox Backup Server roadmap. Earlier versions treated the feature as a preview, so confirm the PBS version before you design around it. Also confirm that your Ceph release is one the project still maintains. The Ceph releases page lists Tentacle and Squid as the actively maintained releases at the time of the supplied facts, and their end-of-life dates should inform your upgrade plan.
How DeployOpen works on this
DeployOpen plans and deploys Proxmox Backup Server with an S3 datastore on Ceph RGW inside infrastructure you control. The work starts with a written scope that fixes the bucket layout, endpoint, certificate handling and cache disk before any configuration is applied.
How we scope
- Confirm the Ceph release, RGW endpoint address, port and whether HTTPS uses a certificate your clients already trust.
- Define the bucket, dedicated access key permissions (get, put, list and delete) and the datastore name in the written scope.
- Size and place the local cache disk, partition or ZFS dataset for the datastore, and document what happens if it fills.
How we build
- Create the bucket and access key on RGW ahead of time, since Proxmox Backup Server does not create buckets itself.
- Configure the S3 endpoint with path-style addressing and the certificate fingerprint, and verify that plain-text connections are refused.
- Test backup, verify, prune and restore runs from a Proxmox VE node against the new datastore before it carries production jobs.
How we hand over
- Deliver a runbook covering endpoint settings, key rotation steps, certificate renewal and where the cache lives.
- Document the restore procedure and record the test results so your team can repeat them without DeployOpen.
- Walk your operators through monitoring cache usage and RGW capacity, with the handover recorded in the project file.
How we support
- Ongoing support, upgrades of Proxmox Backup Server and periodic restore tests are available as a retainer.
- Upgrades are planned against the Proxmox Backup Server release notes and your Ceph release, with changes tested first.
- Confirm with your team which certificate and key renewal responsibilities stay internal and which move to the retainer.
