TrueNAS Cloud Sync to Backblaze B2: Affordable Offsite Backup

The 3-2-1 backup rule requires one copy offsite — and this is exactly where many SMBs fail. A second NAS at a branch office is expensive, a second site does not even exist. Cloud object storage is the obvious answer, but pricing structures vary widely between AWS S3, Azure Blob, Wasabi and Backblaze B2. Backblaze B2 has established itself as a pragmatic choice for many SMBs: S3-compatible, transparently billed and natively integrated into TrueNAS Cloud Sync.

This article shows how to set up a clean Cloud Sync task from TrueNAS to Backblaze B2 — including application key setup, encryption and bandwidth management. We deliberately do not quote specific prices: B2 adjusts pricing periodically, and anyone distributing thousands of euros in cloud budget per quarter should check the current Backblaze B2 pricing page, not a blog post.

Why Backblaze B2 as a Cloud Sync Target?

Backblaze B2 differs from AWS S3 in several important ways:

• Uniform pricing structure for storage, no tiered cold/hot model
• Transparent egress costs with free egress volumes via the Cloudflare partnership
• Fully S3-compatible API since 2020 — tools that speak S3 speak B2
• Native B2 API also available, natively supported by TrueNAS
• Object Lock for immutability — important against ransomware attacks on the backup itself

Compared to Wasabi: B2 has no 90-day minimum retention. Compared to AWS: B2 is much cheaper per GB for pure backup targets without high egress. Compared to MinIO: B2 is a cloud service without your own hardware.

When B2 does not fit: When data has to be read back daily from the cloud (active storage, not backup), or when EU data residency must be strictly EU only — B2 has EU regions, but anyone needing 100% German sovereignty should evaluate a German provider.

Prerequisites

• TrueNAS SCALE 24.04 or newer (Cloud Sync also runs on older versions, but newer releases have more B2 options)
• Backblaze account with B2 Cloud Storage enabled
• Enough outbound bandwidth — the first sync uploads all data
• A thoughtful selection: which datasets/directories really belong offsite?

Step 1: Create Bucket and Application Key in Backblaze

In the Backblaze console:

1. Create new bucket under B2 Cloud Storage -> Buckets -> Create a Bucket

   • Name: globally unique (e.g. company-truenas-offsite-prod)
   • Files in Bucket are: Private
   • Default Encryption: Enable (SSE-B2, AES-256, key managed by Backblaze)
   • Object Lock: Enable (Governance or Compliance mode, more below)
   • Lifecycle Settings: as needed (e.g. delete old versions after 30 days)

2. Create application key under Account -> Application Keys -> Add a New Application Key

   • Name: truenas-cloud-sync
   • Allow access to: only this single bucket — never a master key in TrueNAS
   • Type of Access: Read and Write
   • File name prefix: leave empty
   • Duration: no expiry if the backup runs permanently (alternative: rotate annually)

3. Copy keyID and applicationKey immediately — the applicationKey is only shown once

Step 2: Store Cloud Credentials in TrueNAS

In TrueNAS under System Settings -> Credentials -> Cloud Credentials -> Add:

• Name: Backblaze B2 Offsite
• Provider: Backblaze B2
• Key ID: from step 1
• Application Key: from step 1

After saving, a Verify Credential button appears — it checks via a small API call whether login works. If not: verify that the application key really has bucket access.

Step 3: Configure Cloud Sync Task

Under Data Protection -> Cloud Sync Tasks -> Add:

Field	Value
Description	”Offsite backup important datasets”
Direction	PUSH (from TrueNAS to B2)
Transfer Mode	COPY (alternatively SYNC, see below)
Path	/mnt/tank/important-data
Credential	Backblaze B2 Offsite (step 2)
Bucket	as in step 1
Folder	path inside the bucket (e.g. /truenas-prod)
Schedule	Custom, e.g. daily 22:00
Take Snapshot	enabled — take a snapshot at start and back up from it
Pre-script / Post-script	optional
Encryption	enabled (see below)
Transfers	number of parallel uploads (default 4 is usually fine)
Bandwidth Limit	see below
Exclude	e.g. *.tmp, *.lock, trash directories

Transfer Modes: COPY, SYNC or MOVE?

Mode	Behavior	When to use
COPY	Local files are added to the bucket; nothing is deleted	typical backup mode
SYNC	Bucket mirrors local source; locally deleted files are deleted in bucket	when the bucket must be an exact mirror
MOVE	Files are uploaded and deleted locally	archiving, not backup

Critical warning about SYNC: If ransomware locally encrypts or deletes all files and the Cloud Sync task then runs in sync mode, the originals are also overwritten/deleted in the bucket. Sync is not a backup against ransomware — you need Object Lock + versioning on top.

Step 4: Object Lock — Immutability Against Ransomware

Object Lock on the B2 bucket is the most important defense against ransomware that wipes or encrypts the cloud backup. Two modes:

• Governance Mode: Protection can be overridden by authorized admins — sensible for internal discipline, but compromised admin accounts can still modify data
• Compliance Mode: Protection cannot be overridden before retention expires — not even by Backblaze itself. Most robust variant against insider threats and ransomware

Recommendation: Compliance Mode with retention of e.g. 30 days. Combined with versioning, this means: every file version uploaded in the last 30 days is immutable. Ransomware can upload new (encrypted) versions, but old versions remain untouched — restore is possible.

Step 5: Encryption — What Is Encrypted Where?

Three encryption layers that should not be confused:

1. TLS in transit — from TrueNAS HTTPS to the B2 API. Always on, not configurable.
2. Server-Side Encryption (SSE-B2) — B2 encrypts objects on its own storage with B2-managed keys. Recommended by default, free, transparent.
3. Client-Side Encryption — TrueNAS encrypts before upload with a passphrase known only inside TrueNAS. Backblaze only sees encrypted data.

When to use client-side encryption? When compliance requires “the cloud provider must not be able to read the data”. Downside: the passphrase must be available at restore — passphrase loss = data loss. Anyone enabling client-side encryption must store the passphrase in two safe places (password manager AND offline vault).

In TrueNAS under Cloud Sync Task: Remote Encryption -> Encrypt and set a strong passphrase + salt. Document passphrases outside TrueNAS.

Bandwidth Management

The first sync uploads all selected data. At 5 TB and 100 Mbit/s upload, that is about 5 days of continuous upload — which can block the normal internet line.

TrueNAS offers a Bandwidth Limit per task that can be set differently by time window:

Time window	Bandwidth Limit
Mon-Fri 08:00-18:00	10 MB/s (= 80 Mbit/s) — business hours, throttle
Mon-Fri 18:00-08:00	unlimited — evenings/nights full bandwidth
Weekend	unlimited

Format in TrueNAS: 08:00,10M 18:00,off (enterable as “Bandwidth Schedule” in the UI).

Tip for the initial sync: If the data volume is very large (>10 TB), Backblaze also offers Backblaze Fireball — a pre-built storage device that is physically shipped back and forth. Usually only relevant for large volumes; for typical SMB data volumes the normal initial upload phase over a weekend is enough.

Restore Strategy

A backup is nothing without a tested restore. Three scenarios:

1. Single file restore

Create a second Cloud Sync task in TrueNAS (Direction PULL) and point it at a temporary restore directory. Alternatively download a single file directly from the B2 web console.

2. Full recovery after site loss

On a new TrueNAS system, store the same cloud credentials and create a PULL task to the new target. With client-side encryption, use the same passphrase.

3. Restore test every 6-12 months

Restore a representative sample (e.g. 100 files from different datasets) and check integrity. Skipping the restore test means having an unverified backup.

Monitoring and Alerting

Cloud Sync tasks run autonomously — but their success status must be monitored:

• Configure recipients for task failures in TrueNAS under System Settings -> Email
• Connect TrueNAS alerts to your monitoring solution (webhook, email forward)
• At least monthly check the bucket contents: last upload time, total size plausible?
• Review Cloud Sync job logs in TrueNAS regularly

Best Practices Summary

• Application key per task with minimal rights — never the master key
• Object Lock in compliance mode with retention aligned to RPO/RTO
• Enable bucket versioning — ransomware protection
• Encryption at least SSE-B2, and client-side on top for compliance requirements
• Bandwidth windows set so that business operations are not impacted
• Snapshot before sync in TrueNAS — consistent source state
• Restore test at least annually, documented

Conclusion

Backblaze B2 as a TrueNAS Cloud Sync target is a practical compromise between cost, convenience and robustness. Setup takes less than an hour, the initial sync takes one to several days depending on data volume. What remains is a second data location not in the same fire zone — and that is not optional under 3-2-1.

Most important design decision: enable Object Lock plus versioning. Without these two features, the cloud backup is also a potential ransomware victim. With them, it is a real second line of defense.

Related Articles

• TrueNAS Cloud Sync: Offsite Backup with S3-Compatible Storage
• TrueNAS Replication: Air-Gap Backup
• 3-2-1 Backup Rule for SMBs
• Immutable Backups: Ransomware Protection
• TrueNAS Data Protection: Concepts and Best Practices