Proxmox Backup Server (PBS) is the deduplication hub of your Proxmox environment: Proxmox VE backs up VMs and containers via vzdump to PBS, while hosts and files land in the datastore through the proxmox-backup-client — chunk-based, deduplicated and incremental. What the local setup lacks is the spatially separated copy. intercolo i3 provides exactly that as S3-compatible object storage: you keep the fast, deduplicated datastore local and push an off-site copy to region de-fra via the endpoint https://de-fra.i3storage.com — no second data center, no tape robot, at 99.999999% durability, with data that never leaves the Frankfurt facility. Newer PBS versions address S3 object storage directly as a datastore backend; if you still run an older version, you reach the same goal via a sync job to an S3-backed datastore.
First create a bucket for the off-site copy — via aws-cli against https://de-fra.i3storage.com in region de-fra (see the code below) or with any S3 tool. A dedicated bucket per environment keeps responsibilities and billing cleanly separated.
In the PBS web interface under Configuration → S3 Endpoints, enter endpoint https://de-fra.i3storage.com, region de-fra and your access/secret key pair (SigV4). Access runs exclusively through these keys — no password login. TLS stays on and the certificate is valid.
Under Datastore → Add Datastore, create a datastore with backend S3 pointing at your bucket and specify a local cache directory. PBS stores the deduplicated chunks in the bucket and keeps metadata and cache local for snappy operations.
Instead of backing up straight to S3, the recommended pattern is a local dedup datastore plus an off-site sync: set up a sync job that mirrors your local datastore (source) to the S3 datastore (target). Backup and restore stay fast locally while the distance copy flows automatically to Frankfurt. On older PBS versions without an S3 backend, the sync job points at a remote, S3-backed PBS in Frankfurt instead.
Set a schedule for the sync job (e.g. daily after the backup window) and define retention via the PBS prune policy (keep-daily/-weekly/-monthly/-yearly). Garbage collection then frees chunks that are no longer referenced — in the S3 datastore too. So PBS controls retention, not the storage.
Path-style: https://de-fra.i3storage.com/pbs-offsite · Virtual-hosted: https://pbs-offsite.de-fra.i3storage.com. The S3 endpoint and datastore are configured in the PBS web UI; the AWS CLI here only serves as a pre-check.
Set expectations correctly: i3 Object Storage provides NO storage-side immutability (no Object Lock/WORM, no versioning). The S3 copy is therefore your spatially separated off-site copy under 3-2-1 (3 copies, 2 media, 1 off-site) — not a ransomware-proof vault. For hard immutability against encryption attacks, rely on a locally separated, strictly access-limited PBS datastore (own hardware, separate credentials, ideally with offline or verify windows) and use the S3 copy as the cheap distance backup. Client-side PBS encryption (below) adds a further layer: object storage then holds only encrypted chunks.
PBS plays to its strength locally: chunk-based deduplication and incremental backups ensure only changed blocks are written — that saves storage and makes restores fast. That is exactly why the active datastore belongs on local, fast disks. Object storage takes on the other half of the 3-2-1 rule: the cheap, scalable copy in another location. Since PBS already deduplicates and (optionally) encrypts, only compact, unreadable chunks travel to Frankfurt. You pay for effectively used storage from €2.49 per TB/month — without the egress surprises of US hyperscalers, because 1 TB of egress is included per booked TB.
How many restore points are kept and for how long is defined by the PBS prune policy (keep-last, keep-daily, keep-weekly, keep-monthly, keep-yearly). Prune marks expired snapshots — storage is only reclaimed by garbage collection.
GC removes chunks no longer referenced by any snapshot. Schedule it regularly per datastore; on the S3 datastore it likewise clears objects that are no longer needed. That way used storage matches exactly what your retention dictates.
The sync job keeps the S3 datastore up to date as an off-site mirror of the local datastore. It transfers only missing chunks (incremental) and can be scheduled after the backup window — the distance copy is created automatically, with no manual effort.
Verify jobs check chunk integrity by checksum. On the local datastore that is cost-neutral; on the S3 datastore verify reads data back and generates egress — schedule the frequency deliberately or verify primarily on the local datastore.
| Wasabi | Backblaze B2 | intercolo i3 | |
|---|---|---|---|
| Location / data residency | EU region selectable, US corporation | EU region selectable, US corporation | Frankfurt DC, 100% DE, GDPR/DPA |
| Endpoint | s3.eu-central-*.wasabisys.com | s3.eu-central-*.backblazeb2.com | https://de-fra.i3storage.com (de-fra) |
| Egress model | 'free' up to storage limit, then throttled | 1 TB free/day, then per GB | 1 TB incl./TB, then +€3.99/TB |
| Starting storage price | List price US$/TB | List price US$/TB | €2.49/TB |
| Storage immutability | Object Lock available | Object Lock available | No — off-site copy in 3-2-1 |
| Support / contact | Ticket, EN | Ticket, EN | Direct, German, DC team |
| Power | varies | varies | 100% green power |
i3 does not encrypt at rest — which is precisely why you should keep control yourself: PBS supports client-side encryption. Store an encryption key in Proxmox VE for the PBS storage (or in the proxmox-backup-client), and the chunks are encrypted BEFORE upload. Both the local and the S3 datastore then hold only unreadable ciphertext; the key never leaves your infrastructure. Transport is additionally secured by TLS. That is the clean path for sensitive data: no provider, us included, can read the backups. Store the key separately and redundantly — no key, no restore.
The most expensive off-site backup mistake is the untested restore. US hyperscalers penalise every retrieval and every integrity run with egress fees. Here 1 TB of egress is included per booked TB of storage: you pull individual VMs, containers or files back from the S3 datastore and validate your recovery chain without the next invoice exploding. Restores and verify runs on the S3 datastore read chunks back and generate egress accordingly; traffic beyond that is billed transparently at +€3.99/TB — predictable, not surprising. Tip: for fast, cost-neutral recovery, reach for the local datastore first and use the S3 copy as the fallback when nothing remains locally.
Naše skúsenosti hovoria za seba: Úspešne sme dokončili migrácie zahŕňajúce viac petabajtov dát a viac ako 500 miliónov súborov.