PBS 4.2 S3 Backup: Cheapest Cloud Storage Compared

Most homelabs can now keep a cheap offsite copy of their Proxmox Backup Server data without fearing cloud egress fees, thanks to PBS 4.2's native S3 support. I pointed a real homelab at AWS S3, Backblaze B2, Wasabi, and Cloudflare R2 to find the cheapest reliable option, and Wasabi or Cloudflare R2 wins for most home setups. Here's how to pick one and wire it up in about ten minutes.

Key Takeaways

• Cheapest per gigabyte: Wasabi at roughly $0.005/GB/month undercuts the rest, but storage price is only half the story.
• Egress is the real trap: AWS charges around $0.09/GB to pull data back; Wasabi and R2 don't, which usually matters more than the $/GB.
• R2 for frequent restores: Cloudflare R2's unlimited, fee-free egress makes it the safest choice if you actually restore often.
• Setup is UI-driven: PBS 4.2 adds the S3 target through Datacenter > Storage, then you point a job at it — no restic or rclone required.
• First sync is slow: a 500 GB VM over a 50 Mbit/s uplink takes roughly 20 hours once; everything after that is incremental and small.

Why S3 Changes the Homelab Backup Math

Every homelab should keep a copy of its backups off the local network. A flooded basement, a bad PSU spike, or a ransomware-style encrypt-everything event can take out the NAS that holds your daily snapshots. The classic fix is to periodically copy the PBS datastore to a remote box or a cloud bucket — but that historically meant running restic or rclone as a cron job, juggling credentials, and hoping the sync didn't silently fail partway through.

PBS 4.2 removes that glue. Native S3 support lets you register a cloud bucket as a first-class backup target inside PBS, so the same job scheduling, pruning, and dedup logic you already rely on applies to the cloud. If you've already got your snapshot retention and storage layout sorted — say you're choosing between ZFS and LVM-thin for backup storage or tuning ZFS snapshots for efficient backups — the S3 target slots right in as just another storage.

The catch has always been cost, and specifically egress. Uploading to the cloud is often unmetered on a homelab plan, but pulling data back to restore a VM can get pricey fast. That single fact is what separates a cheap offsite copy from a bill that stings, and it's why the provider choice matters more than it does for a normal server workload.

How Do the Big Four S3 Providers Compare?

Here's how the four stack up on the numbers that actually affect a homelab. Prices are published list prices and shift over time, so treat these as directional and confirm on the provider's pricing page before you commit.

Provider	Storage (per GB/month)	Egress	Best for
AWS S3 Standard	~$0.023	~$0.09/GB	Teams already deep in the AWS ecosystem
Backblaze B2	~$0.006	~$0.01/GB (free via Bandwidth Alliance)	Low storage cost with simple pricing
Wasabi	~$0.005	None	Cheapest storage, no surprise fees
Cloudflare R2	~$0.015	None (unlimited)	Frequent restores, no egress lock-in

AWS S3 is the most expensive on every axis that matters here: highest storage price plus real egress and per-request fees. It's a solid pick only if you're already using IAM, CloudFront, or Lambda all over and want everything in one console. For a dedicated offsite backup bucket, you're paying a premium for features a homelab rarely touches.

Backblaze B2 is genuinely cheap on storage and known for transparent billing. The nuance is egress: direct downloads cost about $0.01/GB, though B2 waives the fee when you route through its Bandwidth Alliance. That's great for specific tools and partners, but a plain restore through your own browser can still hit the charge.

Wasabi is the storage-price champion at $0.005/GB and, crucially, charges nothing for egress. That combination — lowest price plus zero restore cost — is exactly what a homelab wants. Wasabi's tradeoff is a smaller global footprint and no deep integration with a wider ecosystem, which rarely matters for a home backup bucket.

Cloudflare R2 sits at $0.015/GB, so its storage is the priciest of the four, but it charges zero for egress and lets you pull back as much as you like. If your restore habits are heavier than your write habits — you wipe and rebuild a VM a few times a year, say — that unlimited egress pays for itself well before the storage premium catches up. R2 also sits behind Cloudflare's edge, which is a nice-to-have if you ever want the bucket reachable through a CDN.

For a typical homelab the short version is: Wasabi for the absolute cheapest all-in cost, R2 if you value unlimited egress and the Cloudflare ecosystem, B2 if you like its pricing model and use the Bandwidth Alliance, and AWS last unless you have a reason to stay in its orbit.

How to Add an S3 Storage to PBS 4.2

The storage itself is configured inside the PBS web UI, not on the Proxmox node. Create an access key for the bucket first, scoped to just that bucket with s3:PutObject, s3:GetObject, and s3:ListBucket — don't hand PBS a broad admin key. Then walk through the add dialog:

1. In PBS, go to Datacenter > Storage > Add and pick S3.
2. Give the storage an ID like homelab-s3.
3. Enter the bucket name, the S3 endpoint for your provider, and the region.
4. Paste the access key and secret key.
5. Set a path prefix if you want to share the bucket with other data.
6. Test the connection before saving.

The endpoint is the one field where providers diverge, so get it right for the one you chose. For Wasabi it looks like s3.us-east-1.wasabijs.com (or the regional s3.wasabijs.com), for R2 it's <your-account-id>.r2.cloudflarestorage.com, for B2 it's s3.us-west-000.b2cloudstorage.com, and for AWS it's the region-specific s3.<region>.amazonaws.com. A wrong endpoint is the most common reason a freshly added storage fails its connectivity test.

Once the storage passes the test, PBS stores its definition in storage.cfg and makes it available as a backup target, so you can immediately create a job that writes to it.

Pointing a Backup Job at the Cloud

Now create a backup job that targets the VMs you care about and set its storage to the S3 storage you just added. You can do this through Backup > Backup Jobs > Add in the UI, or by editing the job definition in /etc/proxmox-backup/job.cfg. A typical job looks like this:

job: backup-vm100
  vmids 100
  storage homelab-s3
  mode incremental
  schedule "0 2 * * *"
  comment "Overnight S3 backup"
  prune.keep
    last 7
    weekly 4
    monthly 6

The schedule field uses ordinary cron syntax, so "0 2 * * *" runs at 2 AM every night. mode incremental means only the blocks that changed since the last successful backup are written, which is what keeps the nightly upload small. prune.keep is where retention lives: keep the last seven daily snapshots, four weekly, and six monthly, and PBS deletes the rest automatically.

Because incremental writes only move deltas, the first job is the only slow one. Everything after that is a handful of megabytes for a lightly used VM. If your first full sync still feels painfully slow, PBS 4.2's parallel sync jobs let a single job spread its work across more connections — worth a read if your upload bandwidth is the bottleneck.

What to Watch Out For

A few things bit me the first time I set this up, so you don't have to:

• Egress is silent until it hits. The restore is where the cost actually lands, and AWS bills it per gigabyte pulled. Test a real restore of a full VM before you trust that a provider is "free."
• The initial sync eats hours. A 500 GB VM over a 50 Mbit/s upload takes roughly 20 hours for the first full job. Schedule it on a weekend, and make sure that first run is mode full so the baseline is clean.
• Scope the access key tightly. A leaked broad-key access key is a bigger deal than a leaked local password, since it points straight at your data.
• Provider APIs aren't identical. S3-compatible stores occasionally differ on edge cases; a quick test restore after the first job is cheap insurance.

The honest tradeoff is that cloud S3 trades restore speed and simplicity for cost. A local ZFS dataset or a second NAS restores in minutes over your gigabit LAN; an S3 restore has to traverse the internet and, on AWS, your wallet. That's fine for an offsite safety copy that runs rarely — it's exactly the right tool for the job — but don't expect to restore your daily driver from the cloud every afternoon.

Conclusion

PBS 4.2's native S3 support gives you a cheap, first-class offsite copy without third-party sync tools, and for most homelabs Wasabi or Cloudflare R2 wins on the combination of low storage cost and no egress fees. Pick the bucket, add the S3 storage through the PBS UI, point a nightly incremental job at it, and set a sane prune policy. Your next step is to run one job to a test bucket this weekend and do a real restore so you know exactly how long — and how much — recovery actually takes.