Storage and BackupRecovery ValidationIntermediate2-4 hoursLab

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.

Last reviewed4/30/2026
snapshot verification
TrueNASZFSNetworking

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

Keep Moving

Build on what you just completed

Continue with a related Lab or return to this build path for a different implementation.