Build a TrueNAS Replication Lab with Snapshot Schedules and Rollback Validation
Use a disposable ZFS dataset to prove snapshot, replication, retention, destructive-change recovery, and rollback between two TrueNAS systems.
Expected Outcome
A known dataset is snapshotted on a schedule, replicated to a defined destination, deliberately changed/deleted on the source, and recovered from the correct snapshot with evidence of what replication does and does not protect.
Assumptions
Two supported TrueNAS lab systems or a supported source/destination arrangement
Dedicated disposable source and destination datasets
Enough destination capacity for the test and retention policy
A dedicated replication credential/key with limited dataset rights
A known test file set with checksums before the drill
Bill of Materials
TrueNAS installation media (USB or ISO)
Two or more servers or virtual machines
Network switch or router
Cables for network connectivity
Sufficient storage for data replication
Build Steps
- Define source, destination, direction, and retention
Name the exact datasets, replication direction, snapshot naming pattern, retention on each side, and credential scope. Clarify that replication can copy deletions depending on policy and is not automatically an immutable/offsite backup.
- Create a known dataset and baseline evidence
Create several test files including nested paths and record filenames, sizes, and hashes. This becomes the acceptance set for recovery.
- Configure periodic snapshots and prove creation
Create a short lab snapshot schedule, wait/run through the supported TrueNAS control, and verify the snapshot exists with the expected timestamp and dataset contents.
- Configure replication using least privilege
Create the replication task to the dedicated destination dataset and prove the first transfer completes. Verify the destination snapshot/data independently rather than relying only on task status.
- Create a second state and replicate the delta
Modify one file, add one, delete one, create the next snapshot, and replicate again. Record which source states exist on the destination according to retention.
- Run a destructive recovery test
Delete or corrupt selected source test data, then recover from the intended snapshot/replica using the supported restore/clone/rollback approach chosen for the lab. Avoid rolling back a broad production dataset.
- Compare recovered data with baseline
Recalculate hashes and confirm the restored point matches the intended snapshot, then document recovery time and any metadata differences.
Validation
Source/destination datasets and retention are explicit
At least two source snapshots exist with known differences
Replication completes and destination state is independently inspected
A deliberate delete/change is recoverable from the selected point
Recovered files match expected names/sizes/hashes
The guide states replication limitations and does not equate successful replication with a complete backup strategy
Troubleshooting
Replication auth failure: validate credential/key and dataset permissions before broadening access
No delta: confirm a new snapshot actually contains a changed state
Recovery mismatch: verify selected snapshot point before retrying or rolling back
Cleanup or Rollback
Remove disposable datasets/snapshots/credentials only after recovery evidence is captured
Restore normal snapshot/replication schedule if the lab temporarily changed it
Next Improvements
Explore additional TrueNAS features such as cloud sync and user permissions.
Consider implementing alerts for snapshot and replication failures.
Expand the lab by adding more datasets and replication targets.
