Learn NAS - Snapshot, Replication & Backup

#Introduction

A NAS protects data from disk failures through RAID and ZFS, but that's not enough. Ransomware attacks, user mistakes, and logical corruption aren't helped by disk redundancy. Episode 12 covers the next layer of defense: snapshots, replication, and backup.

Snapshots give you a time machine: you can go back to the state of your data from a few hours ago. Replication duplicates data elsewhere, including offsite locations. Together they form a protection strategy that makes data almost impossible to permanently lose.

By the end of this episode you'll be able to create manual and scheduled snapshots, set retention policies, perform rollbacks, replicate datasets between machines with zfs send and receive, and automate it all with TrueNAS Replication Tasks.

#ZFS Snapshots

#Creating Snapshots

A snapshot is an instant point-in-time view of a dataset, space-efficient thanks to copy-on-write. Only data modified after the snapshot is taken changes.

zfs snapshot tank/data@2026-08-10_1200
zfs list -t snapshot tank/data

The zfs snapshot tank/data@2026-08-10_1200 command snapshots the tank/data dataset. The list is viewed with zfs list -t snapshot. Name snapshots with timestamps so they're easy to sort.

#Scheduled Snapshots

Manual snapshots are easy to forget. On TrueNAS SCALE, create a Periodic Snapshot Task through the Data Protection menu with a frequency and retention schedule. A common policy example:

• Every hour, keep 24 snapshots.
• Every day, keep 30 snapshots.
• Every week, keep 8 snapshots.

This tiered policy balances recovery resolution and space usage.

#Rollback with zfs rollback

When data is corrupted or deleted, a snapshot can restore the dataset to a specific point in time.

zfs rollback tank/data@2026-08-10_1200

The zfs rollback tank/data@2026-08-10_1200 command returns the dataset to that snapshot's state. Note that rollback discards all changes made after the snapshot.

#Replication with ZFS Send/Receive

#The Send and Receive Concepts

zfs send streams a snapshot to an output stream, and zfs receive reads it on another machine. This combination creates an identical replica of a dataset. Incremental sends only transfer the delta since the last snapshot, saving a lot of bandwidth.

zfs snapshot tank/data@awal
zfs send tank/data@awal | ssh backup@nas-remote \
  zfs receive backup/tank/data

The commands above create an awal snapshot, then send it over SSH to a remote NAS as backup/tank/data. This is a one-way replication that can be repeated with subsequent snapshots.

#Incremental Replication

For routine replication, send only the changes between snapshots:

zfs snapshot tank/data@r1
zfs send -i tank/data@awal tank/data@r1 | ssh backup@nas-remote \
  zfs receive -F backup/tank/data

The -i tank/data@awal option sends the delta between two snapshots, and -F on receive allows replacing the last snapshot. This pattern makes offsite backups fast and bandwidth-efficient.

#Replication with rsync

#File-Level Backup

rsync is a file-level alternative that doesn't require ZFS on both sides. It suits copying data to targets with other filesystems, cloud storage, or older NAS boxes. rsync only copies the parts of files that changed.

rsync -avh --delete /tank/data/ user@nas-remote:/backup/data/

The rsync -avh --delete command syncs a directory in archive mode and deletes files missing at the source. The --delete option makes the target exactly mirror the source.

#When to Use Send vs rsync

Choose zfs send when both sides support ZFS and you need maximum speed. Choose rsync when the target isn't ZFS, or when you need filter and path-mapping flexibility. Many homelabs use both for different layers.

#TrueNAS Replication Tasks

#Creating a Replication Task

TrueNAS SCALE automates the whole process through Data Protection > Replication Tasks. You pick the source dataset, the target (another NAS or the cloud), the schedule, and the snapshot policy. The system handles snapshots, sends, and pruning automatically.

midclt call replication.query | python3 -m json.tool

The midclt call replication.query command lists replication tasks along with their status. Periodic verification ensures every task succeeds and no backlog accumulates.

#Verification and Restore

Replication is incomplete without testing restores. Periodically mount a snapshot or a replica copy to make sure the data can actually be read. A backup that's never tested is hope, not a strategy.

zfs list backup/tank/data
zpool status backup

The zfs list backup/tank/data command lists the replica dataset on the second machine, and zpool status backup ensures the target pool is healthy. Together they're proof that replication is working correctly.

#A Layered Backup Strategy

Here's the recommended protection strategy at a glance:

• Local snapshots: quick protection against mistakes and ransomware.
• Offsite ZFS replication: a full copy in a different location.
• File-level backup: an additional copy to media or the cloud.
• The 3-2-1 rule: three copies, two different media types, one offsite.

The more critical the data, the more layers you should build. Start with snapshots and local replication, then expand coverage gradually.

#Closing

In this episode 12 you built data defense: manual and scheduled snapshots with retention, rollback, zfs send and receive replication including the incremental version, file-level backup with rsync, and automation through TrueNAS Replication Tasks.

Key takeaways:

• A snapshot is a space-efficient time machine thanks to copy-on-write.
• Apply tiered retention: hourly, daily, and weekly.
• zfs send and receive replicate datasets efficiently.
• rsync is the file-level alternative for non-ZFS targets.
• A backup that's never tested isn't a backup.

In the next episode, episode 13, we'll cover access control and firewalls — from restricting management UI access, subnet whitelists, and preventing public exposure, plus SMB/NFS ACLs, IP allowlists on shares, and the principle of least privilege. Your data is protected; now it's time to lock the door.