TrueNAS Cloud Sync to AWS S3, Backblaze B2 and Wasabi: when the hyperscaler detour is worth it

A recurring question from the field: “We run a TrueNAS, it is stable. How do we get the data additionally into the cloud – without runaway cost and without waiting days for a restore when things go bad?” The honest answer rarely starts with a vendor name and almost always with three counter-questions: How large is the dataset, how often do you restore, and how long is a restore allowed to take? Only then does it make sense to decide between AWS S3, Backblaze B2 or Wasabi – and whether TrueNAS Cloud Sync is the right tool at all, or whether a classic TrueNAS-to-TrueNAS replication stays the cleaner path.

This is the hands-on companion to our cloud backup provider comparison. There we sorted the providers by pricing structure, egress and EU location; here we focus on the concrete configuration on a TrueNAS 25.10 Goldeye system, on encryption decisions, and on the question of when hyperscaler S3 really is the best answer.

Why Cloud Sync instead of replication – and when the other way around

TrueNAS knows two fundamentally different ways to ship data off site. Both appear in the WebUI under “Data Protection”, but they solve different problems.

ZFS replication sends snapshots from one TrueNAS to another TrueNAS. The target system holds a full ZFS pool, replication is block-based and incremental over snapshot diffs, preserving permissions, ACLs, snapshots and dataset structure. A restore is a matter of minutes because the target already serves the data natively – in the worst case you simply boot the replication target and continue working.

Cloud Sync on the other hand pushes files over a protocol (S3, B2, SFTP, WebDAV and a few more) to a third-party service. On the target side an object store or a file tree is created, not a ZFS dataset. Snapshots are gone, permissions are rudimentary at best, metadata is lost. In exchange, the target can live anywhere, needs no hardware of your own, and cleanly fulfills the “offsite” leg of the 3-2-1 backup rule.

The honest rule of thumb from our consulting: If you have a second TrueNAS in another fire compartment or a partner location, you use ZFS replication there. If you do not, or you want to add a second independent lane, Cloud Sync toward a hyperscaler or S3-native provider is the right tool. The two do not exclude each other – on the contrary, the combination is the normal case.

Configuring Cloud Sync: the walk through the WebUI

On TrueNAS 25.10 Goldeye the workflow lives under Credentials -> Backup Credentials for the access data and under Data Protection -> Cloud Sync Tasks for the actual jobs. The split is deliberate: credentials belong in a credential store so they stay centrally rotatable and are not duplicated per task.

Create credentials

For AWS S3 you need an IAM user with an access-key pair that is scoped to exactly the target bucket – never the root account, never an admin key. Backblaze B2 uses application keys, which can also be bucket-scoped. Wasabi follows AWS logic and understands matching IAM policies.

A typical mistake we clean up repeatedly: Old TrueNAS installs still carry a global “Full Access” key that nobody wants to rotate after an admin change. The moment someone with access to those credentials leaves, that key has to go – and if it is scoped too broadly, the entire cloud backup is held hostage with it. Scope tightly, sleep better.

Task direction: PUSH, PULL or SYNC

TrueNAS Cloud Sync knows three modes.

• PUSH pushes local data into the cloud – the default for backup scenarios.
• PULL pulls data from the cloud onto the TrueNAS – useful for restore or migration.
• SYNC reconciles both sides and deletes in the cloud what no longer exists locally.

For backup SYNC is dangerous. If you lose a file locally and do not notice before the next job, it is gone in the cloud too. PUSH with the Keep option (not Replace and definitely not Sync) is the safe mode. Deleting in the cloud is handled by bucket-level lifecycle policies, not by the Cloud Sync task itself.

Schedule and direction mode

For active datasets a nightly job is usually enough. For data that changes frequently – fileservers with accounting or engineering workloads – a 4-to-6-hour cadence of incremental runs makes sense. Cloud Sync uses Rclone under the hood and reliably detects changes via size and timestamp, for S3 targets also via ETag. Important: With very large datasets the comparison pass alone can take several minutes. That is normal.

Encryption: three layers, three decisions

Encryption with Cloud Sync is not a switch but three questions stacked on top of each other.

Transport encryption

The easy one. All three providers speak TLS, Cloud Sync uses it by default. Disable any HTTP endpoints still active for legacy reasons.

Server-side encryption (SSE)

Here it gets interesting. SSE-S3 (on AWS) or the equivalent on Wasabi and B2 encrypts the objects in the bucket with provider-managed keys. That protects against theft of physical disks at the provider, not against a compromised API key. It is the lowest common denominator and should always be on – it costs nothing extra and provides the compliance minimum.

SSE-KMS (AWS only) uses KMS keys that are customer-managed. Measurable in price, more demanding to administer, but in regulated environments often required.

Client-side encryption

The cleanest variant: Data is encrypted on the TrueNAS and reaches the provider only as ciphertext. The provider sees file names and sizes, or not even that, depending on configuration. Cloud Sync offers the Encryption option within the task – internally Rclone performs a password- or keyfile-based encryption. The keyfile does not belong in the cloud bucket and not only on the TrueNAS, but additionally in a second deliberately separated place (password vault at management level, paper in the safe). Without the key the backup is garbage – a lost key means a lost backup.

Our practical recommendation: For data with a personal or professional-secrecy character (law firm, medical practice, tax office), client-side encryption is mandatory. For plain company data without special confidentiality, SSE-S3 is enough – with clean provider-side key management. More in our article on backup encryption and key management done right.

Egress cost: the silent line item

Storage per terabyte is transparent at all three providers. The trap sits elsewhere: in egress, i.e. in pulling data out again when restoring.

• AWS S3 charges egress per gigabyte, tiered by monthly volume.
• Backblaze B2 grants a monthly free egress allowance of three times the stored volume; every gigabyte beyond that is billed.
• Wasabi charges no egress at all – in return there is a 90-day minimum storage time even for objects deleted earlier.

For a pure backup strategy that means: Those who restore rarely do fine with all three models. Those who run monthly restore drills (and everyone should, see restore test day) have to budget egress – or land at Wasabi where it is structurally a non-issue.

Example logic without hard numbers: 10 TB in backup, one quarterly full restore test of a single ~500 GB dataset, one annual partial restore after a real incident. With AWS and B2 the egress budget stays modest. In a full-loss scenario that pulls back the entire 10 TB the math is different – then even B2 becomes noticeably more expensive, and AWS presents a bill that will prompt questions in management. That spike belongs in the risk analysis – not the monthly budget plan, but the recovery plan.

Restore time: the number you must know up front

The most honest cloud-backup metric is not price but realistic restore time. It stands or falls with the internet uplink, not with the provider.

Rough math for inbound: A 1 Gbit/s line delivers around 450 GB per hour gross, meaningfully less net after overhead and verification. 10 TB are therefore not pulled back in a single business day, even if the provider could serve the material in milliseconds. If you actually need a 10 TB restore in under 24 hours you have to either upgrade the line (10 Gbit/s symmetric is available in cities, non-trivial in rural areas) or keep a second TrueNAS on site.

Which leads to the uncomfortable truth: Cloud Sync is an excellent last line of defense against total loss, not the primary recovery method. Primary recovery runs through the local replica or the Proxmox Backup Server in a second fire compartment. The cloud catches the “both gone” case – ransomware, theft, total fire – and is then allowed to take 48 to 72 hours.

When S3 Object-Lock, when classic rsync-style

Within S3 targets there are two configuration styles.

Rsync-style mode

No Object-Lock, with a lifecycle policy for older versions, Cloud Sync in Keep mode. This is the classic path: Nightly push, versioning on, after X days older versions are automatically cleaned up via the bucket policy. Simple, cheap on storage, flexible to maintain.

Immutable mode (Veeam pattern)

With S3 Object-Lock in Compliance Mode: Every object is undeletable for a defined retention time – not by the admin role, not by the root account. This is the hardness level Veeam uses for immutable backups and the one cyber insurers increasingly require (more in our article cyber insurance 2026: what insurers require).

Both AWS and Wasabi support Object-Lock fully. B2 supports it as well, with slightly different API semantics. For TrueNAS Cloud Sync the lock is enabled at the bucket level, not inside the Cloud Sync task. Cloud Sync writes objects, the bucket policy makes them immutable.

Important: Immutable backups only work if the attacker has no access to the configuration of the bucket. That means multi-factor delete, separate admin accounts, and – ideally – an audit trail via CloudTrail (AWS) or equivalent logs. Enabling the lock while leaving the admin key unencrypted on the TrueNAS builds an illusion of safety.

Which variant when

• Classic (rsync-style): For fileserver data with long history, moderate confidentiality, where the 3-2-1 rule is primarily satisfied by the local replica. The cloud is “just” the third copy.
• Immutable: As soon as ransomware risk dominates – i.e. everything that would cause a production halt – or when cyber insurance requires it. Always for VM backups out of Proxmox or Veeam.

A pragmatic middle ground: two buckets at the same provider. One classic with versioning and lifecycle (for active datasets), the other immutable with 30 to 90 days of retention (for monthly snapshots and for Veeam). Cloud Sync runs as two separate tasks, operations stay simple.

Which provider for which workload

Short rule of thumb from our TrueNAS projects (more in TrueNAS support and the TrueNAS configurator):

• AWS S3: Where AWS workloads already exist, where KMS encryption is required, where compliance certifications (BSI C5, ISO 27001) have to be shown formally. Often the most expensive on pure storage, but with the deepest integration and the most granular policies.
• Backblaze B2: For workloads with little egress and a clear price frame. Technically solid, S3-compatible, EU location in Amsterdam. A good fit for mid-sized backups without special compliance demands.
• Wasabi: Where frequent restores or regular restore tests are part of the strategy and the 90-day minimum storage time is acceptable. Frankfurt location available.

For the TrueNAS-native world there is also iX-Storj – the Storj integration with geofencing. That one is covered in our provider comparison article in detail; it is out of scope here because Storj follows an architecturally different path.

Configuration checklist

Anyone setting up a new Cloud Sync task should walk this list:

1. One dedicated bucket per TrueNAS, not per dataset – less config, bucket-wide policies possible.
2. IAM user or application key with minimal rights, rotation planned before any admin change.
3. Server-side encryption on, add client-side encryption when needed.
4. Object-Lock active if the strategy is immutable – before the first push, not retroactively.
5. Lifecycle policy for version management and optional tiering (AWS: after 30 days to Glacier IR, after 180 to Deep Archive).
6. Multi-factor delete on the bucket.
7. TrueNAS task in PUSH with Keep, not Sync.
8. Schedule with a pre-script for a ZFS snapshot upfront, so Cloud Sync copies a consistent point in time.
9. Monitoring: TrueNAS sends job notifications by email or into a central alert manager; review silent jobs after three quiet days.
10. Restore test: Within the first four weeks run a test restore of a mid-sized dataset. The number you get out (real GB per minute) is the planning figure for all later recovery considerations.

What we actually recommend to our customers

For a typical TrueNAS M-Series system in a law firm or SMB context with 10 to 40 TB of payload the standard architecture runs like this: ZFS snapshots per policy, ZFS replication to a second TrueNAS in another fire compartment or at a partner site, Cloud Sync as the third lane toward Wasabi Frankfurt or B2 Amsterdam with Object-Lock at 30 days. Encryption is client-side, the key lives with management – not only on the device.

This three-lane construction is not the cheapest – but it is the most honest. It survives hardware total loss, site total loss and ransomware with compromised admin credentials in equal measure. More in our backup strategy for SMB with Proxmox and TrueNAS.

As an authorized iXsystems partner we plan and operate such setups turnkey. For a review of an existing TrueNAS estate or a greenfield design the IT service packages are the right starting point.

FAQ

Can I back up directly to Glacier Deep Archive with TrueNAS Cloud Sync?

Not sensibly. Deep Archive has multi-hour retrieval times and a 180-day minimum storage. The clean path: Cloud Sync writes to S3 Standard, a bucket lifecycle policy moves objects to Glacier IR after 30 days and to Deep Archive after 180. Recent restores stay fast, older material is stored cheaply.

Does the hyperscaler detour make sense at all for a small SMB with 2 TB of data?

For the pure data volume each of the three providers is economical. The more important question: Is there a second site with a TrueNAS? If no, Cloud Sync is the only clean “offsite” lane – and then the effort pays off at 2 TB too. If yes, the cloud is the third lane and does not need to be optimized at any price; it is insurance, not the main component.

What happens if the cloud provider goes insolvent?

None of the three providers is going out of business tomorrow – but the question is fair. That is why a multi-provider strategy makes sense for critical data: primarily one provider, secondarily (only for genuinely critical data) a second one. Also: client-side encryption makes the data portable – anyone who wants to leave a provider pulls the data out and ships it to another S3-compatible target. Vendor lock-in effectively does not exist for pure object storage as long as encryption stays in your own hands.

Isn’t a rotating USB disk setup enough instead of the cloud?

For very small environments with disciplined rotation yes – and we do use that where it fits. Two drawbacks remain: Rotation is manual and in practice often lax, and the disks usually live physically close to the NAS. For the 3-2-1 rule you need a real offsite leg – either a second NAS at another location or a cloud target. USB as an additional layer is fine; as a replacement for the cloud it is wishful thinking.

What about data crossing into US hyperscalers?

AWS and Wasabi have EU data centers (Frankfurt and Amsterdam/Frankfurt respectively), B2 as well (Amsterdam). With the right region set the data stays inside the EU. For personal data that is the hard minimum. With client-side encryption the transfer is additionally opaque at content level – the provider sees ciphertext, not content. Still, for professional secrecy and especially sensitive data an EU region plus client-side encryption is standard, not an option.

How often should I test a cloud restore?

At least a partial restore quarterly, a serious scenario with a larger dataset annually. More in our article on the 30-minute restore drill. An untested backup is not a backup but an optimistic assumption.

What will it realistically cost me per month?

There is no serious one-size answer – too many variables (data volume, egress profile, region, encryption mode, retention). What we do in a consulting conversation: roughly calibrate the data volume, derive restore frequency from the operational reality, then compute a concrete quote on the current provider price sheets. Blanket “per TB per month” numbers from marketing material are almost always incomplete. For a defensible calculation get in touch.