Map TrueNAS replication keys to destination dataset names

Bottom line: Map the receiving dataset names to the required source keys before relying on an encrypted replica for recovery. Keep the key material in controlled custody and test the exact receiving paths with harmless data.

Source fact: what the authority says

The TrueNAS replication unlock guide describes exporting a key for every child dataset with a unique key and constructing a JSON manifest using destination dataset names and source keys. For a key-encrypted replica, its procedure edits the exported key file’s pool and dataset name to match the receiving system or supplies the key code directly. The receiving dataset is unlocked using the edited file or the Dataset Key field, with trailing space removed from a pasted key. The guide separately describes replication without properties, which leaves the remote dataset unencrypted and removes its unlock-key requirement.

What the source does not establish

The documented unencrypted destination is a different security decision, not a repair to apply casually when an encrypted replica cannot be opened. This article does not approve disabling encryption or establish an organization’s key retention and recovery authority.

Applicability questions

• Which replicated child datasets have their own unique keys?
• What exact pool and dataset names exist on the receiving system?
• Who can retrieve the required key or manifest through the approved recovery process?
• Must the destination remain encrypted, and who owns that requirement?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a mapping record with source dataset, destination dataset and controlled key reference in separate columns. Include uniquely keyed children explicitly rather than assuming the parent’s entry covers every required object. Have another authorized operator check the names without exposing the key values in the general recovery report.

Prepare a proposed disposable parent and child dataset with harmless files and a destination name that differs from the source. Use the source’s documented mapping method for the selected key-encrypted branch. Keep the encrypted-destination requirement visible throughout the rehearsal.

Separate a naming mismatch, missing key and copy-and-paste problem in the investigation record. Review the precise selected dataset before supplying a credential. Avoid switching to replication without properties merely to obtain a quick readable destination; that changes the stated protection requirement.

Keep an independent authorized recovery route to the key material and name the person responsible for reviewing added children. Update the mapping whenever a destination is renamed or the protected dataset population changes. Preserve the old mapping as historical context under the same access restrictions.

Verification and evidence

Proposed verification: unlock the specifically named receiving test dataset using the approved manifest or key-entry method, then read the harmless marker files. Repeat for a uniquely keyed child included in the plan. Record the selected path, credential reference and observed result without saving key values in screenshots.

Ask a second authorized recovery operator to follow the written map in the rehearsal rather than relying on the creator’s memory. Retain redacted evidence of destination encryption and actual access. Treat successful replication, available keys and a demonstrated unlock as separate observations before accepting the recovery procedure.

Official references

• TrueNAS — Unlocking a Replication Encrypted Dataset or Zvol — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.