Offsite encrypted backup
for TrueNAS

The TrueNAS offsite backup options, ranked

From most efficient to least:

1. ZFS replication to another ZFS host - block-efficient, snapshot-preserving
2. Restic over SFTP to a managed vault - encrypted client-side, deduplicated, snapshot history
3. rsync task to an SFTP host - simple, no encryption unless paired with filesystem-level encryption
4. Cloud Sync task to S3/B2 - built-in TrueNAS UI, egress fees on restore

Option 1 is best if you have a ZFS target. Option 2 is best if you do not. Options 3 and 4 are fine for secondary copies but have specific limitations you should know before choosing.

Option 1: ZFS replication

ZFS send/receive is the fastest and most storage-efficient backup possible for ZFS pools. Block-level, lossless, preserves snapshot history, handles incremental sends cheaply. The downside: both sides need ZFS.

On TrueNAS SCALE, go to Data Protection → Replication Tasks → Add. Source is a pool or dataset on the local TrueNAS. Destination is SSH-accessible ZFS on the remote side.

# Remote side must have zfs and an SSH key from source
# Example destination: another TrueNAS, or a Debian box with ZFS

# On the source, configure SSH keypair-based auth to the destination
# Then in TrueNAS UI: Replication Task
#   Source: tank/data
#   Destination: backup-pool/truenas-replica
#   Recursive: yes
#   Encryption: handled by ZFS native encryption if set on source

Pick ZFS replication if you have: another TrueNAS at an offsite location, a colocated server running ZFS, or a friend with a compatible setup.

ServerCrate does not currently expose raw ZFS receive endpoints. If you want that specifically, ZFS-based providers exist - they are a different product category.

Option 2: Restic over SFTP (recommended for most)

If you do not have a ZFS destination, Restic over SFTP is the right choice. You get encryption before upload, deduplication, snapshot history, and the destination can be any SFTP host - including ServerCrate vaults.

On TrueNAS SCALE, the easiest path is a small Debian VM or a sandbox app running Restic. SCALE's Docker-based Apps are the simplest - install a Restic container, mount your dataset read-only, and run backups on a schedule.

On TrueNAS CORE, install Restic in a jail:

# Create a jail with internet access
iocage create -n restic-jail release=13.3-RELEASE ip4_addr="vnet0|10.0.0.50/24"
iocage start restic-jail
iocage exec restic-jail pkg install -y restic

# Inside the jail, set up /etc/restic/env
iocage exec restic-jail 'echo "RESTIC_REPOSITORY=sftp:vaultuser@vault.servercrate.net:22150:/data" >> /etc/restic/env'
iocage exec restic-jail 'echo "RESTIC_PASSWORD=your-repo-password" >> /etc/restic/env'
iocage exec restic-jail 'chmod 600 /etc/restic/env'

Mount the datasets you want to back up read-only into the jail, then run Restic nightly. The initial backup will take a while depending on size and upload speed; subsequent backups are fast because Restic only uploads changed blocks.

Option 3: rsync task to SFTP

TrueNAS has a built-in rsync task UI. Point it at an SFTP target and it mirrors files across. This works with ServerCrate out of the box.

The limitation: no client-side encryption. The backup host can read your files. If you trust the provider, this is fine. If you want zero-knowledge, pair rsync with a filesystem-level encryption layer (TrueNAS's native ZFS encryption on the source, plus something like gocryptfs if you need encryption in transit beyond SSH).

rsync is also not snapshot-aware in the Restic sense. If ransomware encrypts your TrueNAS and rsync runs, the encrypted files replace the good files on the backup. Restic would have kept yesterday's snapshot with the original files; rsync mirrors whatever the source has right now.

Option 4: Cloud Sync to S3 / B2

TrueNAS's Cloud Sync task supports S3, Backblaze B2, Wasabi, and others. This is easy to configure in the UI. The catches:

• Egress fees on restore. AWS S3 is about $0.09/GB egress. A 500GB restore is $45. Backblaze B2 is $0.01/GB - still $5 for 500GB.
• No client-side encryption by default. You can wrap files through TrueNAS's encryption options, but it adds complexity.
• Request charges per file. For a NAS with millions of small files (photos, source code), the per-request costs add up on monthly syncs.

Flat-price SFTP storage sidesteps all three.

What to actually back up from a TrueNAS

Not everything. Backing up a 40TB media library of rippable content wastes bandwidth and storage. The high-value targets:

• User home datasets (tank/home/*)
• Photo and video originals that cannot be re-acquired
• Application data for jails and apps - Nextcloud data, Plex metadata databases, Home Assistant config
• System config - export via System → General → Save Config and back up the file
• iocage / Apps configurations so you can rebuild jails and containers

Skip: ISO libraries, rippable media, scratch datasets, transcode caches, OS snapshots (not portable across hardware anyway).

Ransomware, ZFS snapshots, and why "offsite" matters

ZFS snapshots on the TrueNAS protect you from your own mistakes and some types of corruption. They do not protect you from:

• Ransomware that gains root on the TrueNAS and runs zfs destroy on snapshots
• Physical destruction (fire, theft, flooding)
• Deliberate sabotage by someone with credentials
• Failed pool / corrupt pool you cannot import

Offsite backup is the answer to all four. An offsite copy that the source system cannot reach - because it uses different credentials, different hosts, different administrative domain - survives incidents that take out the primary.

Restic to an SFTP vault fits this model cleanly. The TrueNAS has a Restic password and SSH credentials, but the vault is managed by someone else. A full compromise of the TrueNAS cannot destroy the offsite backup unless it also gets the attacker through to deleting snapshots in the vault - and with Restic's append-only mode, even that is possible to prevent.

Using Restic's append-only mode

Restic can use a separate credential for backup (write + read only, cannot prune) and another for maintenance (full access). On TrueNAS, configure the nightly backup to use the append-only credential. A compromise of that credential lets the attacker write junk - they cannot destroy existing snapshots.

On ServerCrate vaults this is done at the Restic layer with --no-lock backup users; we have guidance in our security documentation.

Restoring a TrueNAS from Restic

Three scenarios:

1. Single file: restic mount /mnt/restore, browse, copy back.
2. Whole dataset: restic restore latest --target /mnt/tank/restored-dataset. Move it back into place when done.
3. Bare-metal rebuild: install TrueNAS fresh, restore System Config from the saved file, recreate datasets, run Restic restore into each.

Plan on 8-24 hours for a full-NAS restore on typical home connections. The initial upload took weeks; the restore takes a while too. This is where having a local backup in addition to offsite matters - the local copy restores in hours, the offsite copy is your last resort.