The 3-2-1 backup rule is now standard: three copies, two media, one offsite. The “offsite” piece for many SMBs today lives at an S3-compatible cloud provider — because it integrates effortlessly with TrueNAS Cloud Sync, Proxmox Backup Server and Veeam. But which provider? Backblaze B2, Storj, Wasabi and AWS S3 are the four heavyweights; each has a different profile. We don’t deliver a price list — those change monthly — but an evaluation matrix with criteria to help an SMB choose in a structured way.
Why S3-compatible?
S3 isn’t only an Amazon service but the de-facto protocol for object storage. All common backup tools (Veeam, Borg, Restic, Duplicacy, TrueNAS Cloud Sync, Proxmox Backup Server 4.x+) speak S3 — which concretely means:
- Multi-vendor strategy: B2 today, Wasabi tomorrow, your own MinIO cluster the day after — backup tooling doesn’t change
- Object Lock: S3 Object Lock enables immutable backups (ransomware protection)
- Replication: cross-region replication is a built-in standard
- Versioning: S3 automatically keeps versions (when enabled)
Anyone picking a provider that only speaks a proprietary protocol (classic “online backup providers”) is effectively bound to that tool — switching later gets expensive.
The four providers at a glance
Backblaze B2
- Model: pure cloud storage provider, one of the pioneers of cheap object storage
- Locations: US-West, US-East, EU (Amsterdam)
- Geo-redundancy: within a region via erasure coding across multiple data centers
- Egress: first 3× of stored data per month free to the internet, billed beyond
- Minimum retention: none
- API: native B2 API plus S3-compatible layer
- Strength: very simple pricing, one of the cheapest options on the market
- Weakness: limited region choice, no German location
Storj
- Model: decentralized storage network — files are split into erasure-coded fragments across hundreds of nodes
- Locations: globally distributed, geofencing selectable (e.g., “EU only”)
- Geo-redundancy: structurally built-in via erasure coding across multiple nodes/regions
- Egress: flat per GB, often cheaper than classic providers
- Minimum retention: none
- API: native Storj API plus S3-compatible gateway (Storj S3 Gateway)
- Strength: very high redundancy by architecture; iX-Storj is the TrueNAS-specific Storj variant with seamless TrueNAS web-UI integration
- Weakness: conceptually unusual — anyone who wants “one data center” as a target is conceptually wrong here
Wasabi Hot Cloud Storage
- Model: S3-compatible “hot storage” — no tier distinctions, no lifecycle management
- Locations: US, EU (Amsterdam, Frankfurt, London, Paris, Milan), APAC
- Geo-redundancy: per region
- Egress: no egress charge (very unusual on the market!)
- Minimum retention: 90-day minimum storage time — files deleted earlier are still billed for 90 days
- API: S3-compatible
- Strength: no egress = predictable cost, especially during frequent restores; Frankfurt location available
- Weakness: the 90-day minimum is a show-stopper for short-lived backups (e.g., build artifacts)
AWS S3 / S3 Glacier
- Model: hyperscaler with full AWS integration; storage classes Standard / IA / Glacier / Deep Archive
- Locations: worldwide, eu-central-1 (Frankfurt) and eu-central-2 (Zurich) for EU workloads
- Geo-redundancy: three AZs per region for standard storage; cross-region replication optional
- Egress: per GB with tiered volume discounts
- Minimum retention: none for Standard; Glacier 90 days, Deep Archive 180 days
- API: S3 (the original)
- Strength: full maturity, compliance certificates (BSI C5, ISO 27001, etc.), deepest AWS integration
- Weakness: tends to have the highest list price, complex pricing with many variables
Evaluation matrix
| Criterion | Backblaze B2 | Storj | Wasabi | AWS S3 |
|---|---|---|---|---|
| Price (storage, ballpark) | Cheap | Very cheap | Medium | High (Standard) to very cheap (Glacier DA) |
| Egress cost | Free up to 3×, then medium | Flat per GB | None | Per GB, tiered |
| EU location | Amsterdam | Geofencing possible | Frankfurt, more EU | Frankfurt, Zurich |
| DACH compliance | Solid | Via EU geofencing | Solid | Very comprehensive |
| S3 Object Lock | Yes | Yes | Yes | Yes |
| Minimum storage time | None | None | 90 days | 0 (Standard) / 90 / 180 days |
| Glacier-class | No, uniform class | No, uniform class | No, uniform class | Yes (Glacier IR / DA) |
| TrueNAS integration | Standard | iX-Storj native | Standard | Standard |
| API maturity | Very good | Mature S3 compat since 2024 | Very good | Reference |
| Multi-region within provider | Medium | Structural | Good | Very good |
Important: concrete dollar amounts per TB-month fluctuate at all four providers. We deliberately don’t quote them here — they would be stale by publication. Instead, the price lists are linked directly:
Three typical SMB scenarios
Scenario A: daily server backups, rare restores
- Volume: 5 TB
- Restore frequency: 1× per quarter for testing, 1–2× per year for real
- Retention: 90 days daily, 12 months monthly
Recommendation: Wasabi or B2. Wasabi drops egress charges — good for rare restores that tend to be large. B2 is slightly cheaper on pure storage but charges egress on restores. Both offer Frankfurt/Amsterdam in the EU.
Scenario B: Veeam M365 backup with frequent item-level restores
- Volume: 2 TB
- Restore frequency: multiple times per week (single mails/calendar items)
- Retention: 7 years, tamper-resistant
Recommendation: AWS S3 with lifecycle to Glacier IR after 30 days. Hot tier for recent mail (fast item-level restores), Glacier IR for older — the tiered model plays to its strengths here. Alternative: Wasabi, if the 90-day minimum is tolerable.
Scenario C: TrueNAS replication as a second offsite rail
- Volume: 50 TB
- Restore frequency: rare, worst case “data center gone”
- Retention: TrueNAS snapshot chain
Recommendation: Storj / iX-Storj. The decentralized architecture provides structural redundancy, the per-TB price is competitive, the TrueNAS integration is native. For very large data volumes a comparison with AWS S3 Glacier Deep Archive pays off — it is unbeatably cheap for rarely accessed data.
What really drives the choice
From our advisory practice:
- Restore frequency is the most important factor — frequent restores make egress the dominant cost line
- EU location is non-negotiable as soon as personal data or professional confidentiality is in play
- API maturity matters — we have hit edge cases on newer S3 implementations that didn’t pair ideally with classic backup tools
- Minimum storage time is the most frequent trap for buyers who anchor “cheap” only on the storage price
- Compliance certificates are formally needed by few SMBs but reassuring during audits
Configuration tips
- Enable Object Lock — at least “Governance Mode” for 30 days as ransomware protection
- Use lifecycle policies — automatically push old versions to cheaper tiers (especially on AWS)
- Bucket versioning — without it, an accidental “delete backup” has catastrophic effect
- Multi-factor delete — decisive safeguard against compromised API keys
- Client-side encryption — even if the provider encrypts, client-side is the clean variant
DATAZONE recommendation
We usually set up cloud backup for our customers with a multi-provider strategy: a primary provider matching the workload and location, a secondary one (for critical data) at a different provider in a different region. That guards not only against hardware failures but also against vendor insolvencies or API incompatibilities after a provider update.
Related articles:
- 3-2-1 backup rule for SMBs
- TrueNAS Cloud Sync: offsite backup with S3
- Immutable backups against ransomware
- Backup strategy for SMBs with Proxmox and TrueNAS
- Proxmox Backup Server 4.1 release
Sources
More on these topics:
More articles
TrueNAS API with Python: Automating Custom Reports
TrueNAS WebSocket and REST API with Python: generate an API key, examples for pool usage, snapshot age, SMART status. Complete script for an 80% pool alert via email.
TrueNAS Cloud Sync to Backblaze B2: Affordable Offsite Backup
TrueNAS Cloud Sync to Backblaze B2 as an offsite backup target: B2 application key, bucket setup, push mode, encryption and bandwidth management. With best practices for SMBs.
Disaster Recovery Plan for SMBs: What to Do on Total Server Failure
Concrete 4-phase emergency plan for SMBs facing a total server failure: detect, contain, restore, learn. Checklists, roles, restore sequence and RTO/RPO.