Encrypted replication crashes Truenas

I have 2 encrypted pools:

  • apps (1x DISK | 1 wide)
  • tank (1x RaidZ2 | 4 wide)

I want to do a daily full backup of the apps-pool.
Therefore I created a replication task like this:

As described in the Truenas docs here, I think this shouldn’t even work.

However it did the first time and the whole apps root-dataset was replicated to tank/apps-backup and still was encrypted with the original key.
I then unlocked the dataset (tank/apps-backup) and everything seamed fine.
But now the next snapshot was created and when I now run the replication I get this error:

[EFAULT] Last full ZFS replication failed to transfer all the children of the snapshot apps@auto-2026-01-15_03-30. The snapshot tank/apps-backup/.system@auto-2026-01-15_03-30 was not transferred. Please run `zfs destroy -r tank/apps-backup@auto-2026-01-15_03-30` on the target system and run replication again.

If I then run zfs destroy -r tank/apps-backup@auto-2026-01-15_03-30 like told in the error and start the replication again, Truenas crashes.

I tried reading logs, but I can’t find anything useful to me.

What would be the proper way to backup the apps pool here?
How can I debug a crash?

PS:
My initial setup were two unencrypted pools with a similar replication task and that worked. Also my Truenas System is already running for several months without any other crashes, so I don’t think it’s about hardware, like some other topics suggest.

You need to exclude the hidden .system dataset from the source. Not sure how this is done in the TrueNAS GUI, other than selecting all children directly under the root dataset.

This is another reason why I use pseudo-roots.

Since 7 years ago, I have never replicated a root dataset. The highest level I ever replicated was a pseudo-root dataset.

4 Likes

Thank you! It seems to work now.

I changed the replication task to replicate the child-datasets of apps (apps/vms, apps/configs). This works without issues so far.

However, from a usability and structural standpoint, this is not really what I hoped for.

I now have to unlock all destination datasets one by one and the parent destination dataset tank/apps-backup is encrypted with the key from tank.

  • apps (encrypted with apps-key)
    • configs (inherited encryption: apps-key)
    • vms (inherited encryption: apps-key)
  • tank (encrypted with tank-key)
    • apps-backup (inherited encryption: tank-key)
      • configs (encrypted with apps-key)
      • vms (encrypted with apps-key)

It would be nice to get a hint or warning in the “Replication Task Wizard”, that replicating a root-dataset could crash the system.