Introduction

If you're already running Proxmox Backup Server, you've probably run into the same wall everyone eventually hits: a local datastore is only as safe as the box it's sitting in. A single disk, a single RAID array, or even a single building is one flood, one fire, or one failed controller away from taking your only copy of every backup with it. The usual fix is to ship a second copy offsite, and for a long time that meant rsync jobs, sync-to-a-second-PBS setups, or manually rotating external drives.

As of Proxmox Backup Server 4.0, there's a more direct option: PBS can use an S3-compatible object store — Amazon S3, Backblaze B2, Wasabi, Cloudflare R2, or a self-hosted store like MinIO or Garage — as the actual backend for a datastore, not just as a sync target. In PBS 4.2, released at the end of April 2026, that S3 backend graduated out of technical preview and is now considered stable for production use.

This guide walks through what an S3-backed datastore actually is, how it differs from the local-datastore setup most PBS guides cover, and how to configure one end to end: creating the bucket and IAM credentials, registering an S3 endpoint in PBS, creating the datastore itself, sizing the mandatory local cache, and knowing where the sharp edges are before you commit your production backups to it.

This is not a guide to installing Proxmox Backup Server itself or connecting it to Proxmox VE as a storage target — that's its own topic. Here we're assuming you already have a working PBS instance and want to point a datastore at object storage instead of (or alongside) local disk.

What You Will Learn

  • How PBS's S3 backend actually stores data, and why a local cache is still mandatory
  • How to create a properly-scoped IAM user and bucket for PBS to use
  • How to register an S3 endpoint and create an S3-backed datastore, in the GUI and on the CLI
  • How to size and monitor the local cache disk
  • How to migrate an existing local or NFS datastore's contents into an S3-backed one
  • The hard limitations — object lock, versioning, multi-PBS sharing — that will bite you if you ignore them
  • How to troubleshoot the most common setup and runtime errors

How an S3-Backed Datastore Actually Works

It's worth being precise about this, because "S3-backed datastore" sounds like PBS just becomes a thin wrapper around a bucket, and that's not what's happening. PBS still uses the same content-addressable chunk store model it always has: every backup is split into variable-sized, deduplicated, optionally-encrypted chunks, each identified by its content hash. What changes with the S3 backend is where those chunks physically live — as individual objects in your bucket, prefixed by the datastore name, instead of as files on a local filesystem or block device.

That distinction matters because deduplication, garbage collection, verification, and pruning all still work exactly as they did before — PBS is just now doing object PUT/GET/DELETE/LIST calls against your S3 endpoint instead of filesystem syscalls. From the Proxmox VE side, and from the backup job's perspective, nothing changes at all.

What does change is that PBS still requires a local, persistent cache disk for every S3-backed datastore. This isn't optional and isn't just for performance headroom — it's structural. The cache holds frequently-accessed metadata and recently-written chunks so PBS isn't making a network round-trip to your S3 provider for every single read, and it absorbs writes during a backup run before they're flushed to the object store. Proxmox's own guidance is to budget somewhere in the 64 GiB to 128 GiB range for the cache, on a dedicated disk, partition, or ZFS dataset — not a directory carved out of your root filesystem. You can also set a cache size quota so it doesn't grow unbounded.

One consequence worth sitting with: an S3-backed datastore is not simply "your backups, but in the cloud." It's a local PBS instance with a local cache, talking to a remote object store for bulk chunk storage. You still need a working PBS host with enough CPU and RAM to do the chunking, hashing, and encryption — the S3 backend removes the need for large local bulk-storage disks, it doesn't remove the need for a PBS server.

Why You'd Use This Instead of Local or NFS Storage

The most common driver is offsite backup without a second physical PBS box. Renting object storage from a provider outside your own building or region gets you real geographic separation for a fraction of the cost and effort of racking a second server somewhere else and keeping it patched. For a homelab or small business, "sync my PBS datastore to Backblaze B2" used to mean a separate script and a second copy of every chunk sitting on local disk too; with a native S3-backed datastore, the bucket is the primary storage tier, not a secondary copy.

The second driver is avoiding local capacity planning entirely. Object storage scales without you provisioning a bigger RAID array or adding drives to a chassis — you're paying per gigabyte-month for what you actually use, and growing a dataset from 2 TB to 20 TB doesn't require touching hardware.

The third, more specific to PBS 4.2, is that request-count and traffic statistics are now tracked and shown per S3-backed datastore in the summary view, which makes it realistic to actually monitor egress and request volume against your provider's pricing instead of getting surprised by a bill.

None of this means S3 backing is strictly better than local disk. Restore speed from a cold S3 datastore will generally be slower than from local NVMe, and every S3 API call your provider charges for (PUT, GET, LIST, DELETE) adds up during garbage collection and verification runs, which touch a lot of objects. For a lot of setups, the right answer ends up being local storage as the primary datastore with sync jobs to an S3-backed secondary — but that's a separate topic from what this guide covers.

Prerequisites

  • A working Proxmox Backup Server 4.2 or later install (the S3 backend exists in 4.0 and 4.1 as a technical preview, but 4.2 is where it's supported for production)
  • Root or an equivalent privileged account on the PBS host
  • An S3-compatible bucket already created with your provider of choice — PBS does not create buckets for you
  • An access key / secret key pair scoped to that bucket, with at minimum GetObject, PutObject, ListBucket, and DeleteObject permissions
  • A dedicated local disk, partition, or ZFS dataset for the cache — 64-128 GiB minimum, more for larger or busier datastores
  • Outbound HTTPS access from the PBS host to your S3 endpoint (only TLS connections are supported; plain HTTP is not)

If you're using a self-hosted object store like MinIO or Garage instead of a public cloud provider, the same prerequisites apply — you just point the endpoint at your own host and, if you're using a self-signed certificate, provide its fingerprint during endpoint setup.

Step-by-Step Tutorial

Step 1: Create the Bucket and a Scoped IAM User

Do this in your provider's console, not in PBS. As an example, for AWS S3: create a bucket (pick a region close to your PBS host to minimize latency and, depending on your provider, egress cost), then create an IAM user or access key with a policy limited to that one bucket. A minimal policy needs s3:GetObject, s3:PutObject, s3:DeleteObject, and s3:ListBucket on the bucket and its contents — don't hand PBS a key with account-wide S3 access.

Two things to decide before moving on, because they're painful to change later:

  • Object Lock and versioning must both stay disabled on this bucket. PBS manages chunk lifecycle itself through its own garbage collection; enabling S3 Object Lock or bucket versioning on top of that can corrupt the datastore's internal structure, since PBS expects to be able to actually delete an object when it decides a chunk is no longer referenced.
  • Pick a bucket that only this one PBS instance will ever write to. A datastore cannot be shared between multiple Proxmox Backup Server instances — two PBS servers pointed at the same bucket will corrupt each other's chunk stores.

Step 2: Register the S3 Endpoint in PBS

In the PBS web UI, go to Configuration > Remotes > S3 Endpoints and add a new endpoint with your access key, secret key, endpoint URL, and region. The equivalent on the command line:

proxmox-backup-manager s3 endpoint create my-s3-ep \
  --access-key 'AKIAEXAMPLEKEY' \
  --secret-key 'supersecretkeyvalue' \
  --endpoint '{{bucket}}.s3.{{region}}.amazonaws.com' \
  --region eu-central-1

Notice the endpoint URL uses {{bucket}} and {{region}} as template placeholders — PBS fills these in per-datastore, so one endpoint definition can back multiple buckets in the same region if you ever need that. For providers or self-hosted stores that use path-style addressing (bucket name in the URL path rather than as a subdomain) instead of virtual-hosted-style, there's a flag to switch addressing modes — check your provider's S3 compatibility docs if you're not on AWS, since this is the single most common cause of "endpoint not found" errors during setup.

If your endpoint uses a self-signed certificate (common with self-hosted MinIO or Garage on a LAN), pass its TLS fingerprint with --fingerprint when creating the endpoint, the same way you would when registering a remote PBS instance.

Verify the endpoint was registered correctly:

proxmox-backup-manager s3 endpoint list

Step 3: Prepare the Local Cache Disk

Before creating the datastore, make sure you have a mount point ready for the cache — this needs to be persistent, local storage, not tmpfs or a network share. On a spare disk or partition:

mkfs.ext4 /dev/sdb1
mkdir -p /mnt/datastore/my-s3-store-cache
mount /dev/sdb1 /mnt/datastore/my-s3-store-cache

Add it to /etc/fstab so it survives a reboot — losing the cache mount and having PBS silently write into the root filesystem underneath it is a real failure mode, and one that's easy to miss until the root disk fills up.

If you're running ZFS on the PBS host already, a dedicated dataset works well here too and gives you the option of compression on the cache layer:

zfs create -o mountpoint=/mnt/datastore/my-s3-store-cache rpool/pbs-s3-cache

Step 4: Create the S3-Backed Datastore

With the endpoint registered and the cache mount ready, create the datastore:

proxmox-backup-manager datastore create my-s3-store \
  /mnt/datastore/my-s3-store-cache \
  --backend type=s3,client=my-s3-ep,bucket=pbs-s3-bucket

The first path argument is the local cache path, not a data path — that's the key difference from creating a normal local datastore, where that same argument points at where the chunks themselves live. The --backend string is what tells PBS this datastore is S3-backed: type=s3 selects the backend, client references the endpoint you created in Step 2, and bucket is the bucket name in your S3 account.

In the GUI, this is the same Datastore > Add Datastore flow you'd use for a local datastore, except you select the S3 endpoint and bucket in the backend section instead of a filesystem path.

Once created, the datastore shows up in the PBS UI like any other and can be added as storage in Proxmox VE exactly the same way a local PBS datastore would be — same fingerprint, same API token workflow. Nothing about the PVE side changes because of the S3 backend.

Step 5: Run a Test Backup and Confirm Objects Land in the Bucket

Kick off a manual backup of a small VM or container against the new datastore from Proxmox VE, then check two things: that the job completes and shows up as a restore point in the PBS datastore's Content tab, and — separately — that your bucket actually has objects in it, using your provider's console or the aws s3 ls / mc ls equivalent for your provider's CLI. Seeing objects appear under a prefix matching your datastore name confirms the chunk writes are actually reaching the object store and not just landing in the local cache.

It's worth doing a full restore of that test backup too, not just confirming the job succeeded. A restore that has to pull cold chunks from the object store is a meaningfully different code path — and a meaningfully different latency profile — than one served entirely from cache, and you want to know what that looks like before you're doing it under pressure during a real incident.

Step 6: Migrating an Existing Datastore's Contents into S3

If you already have a local or NFS-backed datastore and want to move its contents onto an S3-backed one rather than starting fresh, PBS supports reusing an existing dataset's chunk contents when creating the new datastore:

proxmox-backup-manager datastore create my-s3-store \
  /mnt/datastore/my-s3-store-cache \
  --backend type=s3,client=my-s3-ep,bucket=pbs-s3-bucket \
  --reuse-datastore true \
  --overwrite-in-use true

Treat this as a one-way migration path, not a live sync mechanism, and test it against a copy or a non-critical datastore first. --overwrite-in-use exists because reuse scenarios often involve a datastore that's still technically registered elsewhere — read exactly what it does in your PBS version's documentation before running it against production data, since forcing past an in-use check is inherently a step where a mistake is expensive.

Step 7: Monitor Cache Usage and S3 Request Volume

Two things are worth watching on an ongoing basis. First, cache disk usage — PBS 4.2 lets you set a cache size quota, and it's worth setting one deliberately rather than letting the cache grow to fill the disk, especially if the cache disk is shared with anything else. Second, the request-count and traffic statistics PBS 4.2 now surfaces per S3-backed datastore in the summary view — this is the number that maps most directly to your object storage bill, since most providers charge per API request in addition to per-gigabyte storage and egress. A datastore that's doing far more LIST or GET calls than expected is usually a sign that the local cache is undersized for the working set of your backup jobs, forcing more round-trips to the backend than necessary.

Limitations and Gotchas

  • No Object Lock or versioning. Covered above, but it bears repeating since it's the single most common way people accidentally corrupt an S3-backed datastore — enabling either feature on the bucket after the fact is just as dangerous as enabling it at creation.
  • No sharing a bucket across multiple PBS instances. Each S3-backed datastore is owned by exactly one PBS server. If you need two PBS servers with independent backup sets, they each need their own bucket.
  • HTTPS only. There's no plain-HTTP fallback for the S3 backend, which is generally the right call security-wise but does mean self-hosted object stores need a valid certificate — self-signed is fine with a fingerprint, but it has to be TLS.
  • The local cache is mandatory, not optional. You can't run an S3-backed datastore without a persistent local disk for the cache — this isn't a way to run PBS with zero local storage.
  • Running out of space on the S3 side degrades gracefully, but not silently. If the backend hits a hard capacity limit or quota with your provider, cleanup and garbage-collection operations can start failing rather than backups simply erroring out immediately — keep an eye on provider-side usage and billing, not just what PBS reports locally.
  • Restore latency is not the same as local disk. Cold restores of data that's aged out of the local cache have to be fetched over the network from the object store, which is measurably slower than reading local NVMe or even spinning disk. Factor this into your recovery time expectations, particularly for large VM disks.
  • PBS does not manage the bucket lifecycle. Bucket creation, deletion, and access policy are entirely your responsibility on the provider side — PBS assumes the bucket exists and the credentials it's given are valid and sufficiently scoped.

Troubleshooting Common Errors

"Access Denied" or authentication failures when creating the endpoint or datastore

Almost always an IAM policy problem — double-check the access key has all four required permissions (GetObject, PutObject, ListBucket, DeleteObject) scoped to the correct bucket, and that the bucket name and region in the endpoint match exactly what's in your provider's console. A region mismatch on AWS in particular will produce an authentication-flavored error rather than an obviously region-related one.

Endpoint unreachable or certificate errors

Confirm outbound HTTPS from the PBS host to the endpoint isn't blocked by a firewall rule, and if you're using a self-hosted store with a self-signed certificate, confirm you passed the correct fingerprint when creating the endpoint — a stale fingerprint after a certificate renewal is a common cause of this after the fact.

Datastore creation succeeds but backups fail or hang

Check that the cache mount point is actually mounted and writable — a cache path that exists as an empty directory on the root filesystem (because the intended mount silently failed) will still let datastore creation succeed, but backups will behave erratically once the "cache" fills the root disk. Confirm with df -h that the cache path shows the dedicated disk, not the root filesystem.

Garbage collection or verification jobs failing with backend errors

This is the symptom of the S3 backend running low on space or hitting a request-rate limit from your provider. Check provider-side usage and any request throttling settings before assuming it's a PBS-side bug — object stores that enforce request-per-second limits on a bucket can throttle heavy GC or verify runs that touch a lot of objects in a short window.

Frequently Asked Questions

Do I still need vzdump or Proxmox VE configuration changes to use an S3-backed datastore?

No. Once the datastore exists in PBS, you add it as PBS storage in Proxmox VE exactly the way you would a local datastore — same fingerprint, same API token setup. The S3 backend is entirely internal to how PBS stores chunks; it's invisible to PVE and to your backup job configuration.

Can I mix local and S3-backed datastores on the same PBS server?

Yes. Datastores are independent, so you can run some backed by local disk and others by S3 on the same PBS instance, and point different backup jobs or different VMs at whichever makes sense.

Is S3 backing cheaper than local storage?

It depends entirely on your provider's pricing and how much data you're storing and restoring. Object storage tends to win on flexibility and offsite resilience rather than on raw price-per-gigabyte compared to a locally-owned disk you already have sitting in a chassis. Watch request pricing specifically — a datastore with an undersized cache generating a lot of GET/LIST calls during normal operation can cost more in requests than in storage.

Does deduplication still work the same way with an S3 backend?

Yes — deduplication happens at the chunking layer before anything is written anywhere, so it's identical regardless of whether chunks end up on local disk or in an S3 bucket.

What happens if my PBS host goes offline — is my data still safe in the bucket?

The chunk data itself persists in the bucket independent of the PBS host's uptime, but you need a working PBS instance (this one recovered, or a new one pointed at the same bucket with the same encryption key if backups were encrypted) to actually read and restore from it. An S3 backend protects your data from local hardware failure; it doesn't remove PBS itself from the recovery path.

Can I use this with a self-hosted S3-compatible store like MinIO or Garage instead of a public cloud provider?

Yes, and it's a common setup for homelabs that want the operational model of object storage without a recurring cloud bill. The setup steps are identical — you just point the endpoint at your self-hosted instance's URL and, if it's using a self-signed certificate, supply the fingerprint.

Conclusion

S3-backed datastores give Proxmox Backup Server a real answer to offsite backup that doesn't require racking a second server somewhere else: point a datastore at a bucket, size a local cache disk correctly, and PBS handles chunking, deduplication, and lifecycle management exactly as it always has. The tradeoffs are real — a mandatory local cache, slower cold restores, per-request costs, and a hard rule against Object Lock or bucket sharing — but for a lot of setups, particularly ones already paying for cloud storage elsewhere, it's a meaningfully simpler path to genuine geographic redundancy than the sync-script approach most people were stitching together before PBS 4.0. Start with a small, non-critical datastore, run a full restore before you trust it, and only then move production backup jobs over.