Difficulty replicating native ZFS encrypted pool to new pool.

[HenchRat]

I'm preparing to move a series of datasets residing on one encrypted pool to another pool. This is primarily intended to be a move from a smaller pool of storage to a larger pool of storage, after which point I'll destroy the smaller pool.

The source pool, tank, is set up with TrueNAS 12.0-R ZFS native encryption, not GELI. Most child datasets inherit that encryption, though a couple have their own passphrase-based encryption.

It is my desire to have ALL of my data encrypted, and to NEVER have unencrypted data touch a storage medium. This is in part so that RMAs of drives, should that be necessary, are not a potential source of data leakage.

The destination pool, dozer, was also set up with ZFS native encryption, with its own key.

When I set up a replication task to send the entire pool tank and everything within it to dozer, it fails: "Destination dataset 'dozer' already exists and is it's own encryption root. This configuration is not supported yet. If you want to replicate into an encrypted dataset, please, encrypt it's parent dataset."

OK, fair enough. For the purposes of testing, I created a new dataset on dozer that inherits dozer's encryption, and copied some inconsequential files to that dataset.

I then created another new pool, frank, with no encryption. I then set up a replication task to send all of pool dozer to pool frank.

This also failed:

Error
Unable to send encrypted dataset 'dozer' to existing unencrypted or unrelated dataset 'frank'.
Logs
[2020/12/27 19:46:27] INFO [replication_task__task_21] [zettarepl.replication.run] For replication task 'task_21': doing push from 'dozer' to 'frank' of snapshot='auto-2020-12-27_19-46' incremental_base=None receive_resume_token=None encryption=False
[2020/12/27 19:46:27] ERROR [replication_task__task_21] [zettarepl.replication.run] For task 'task_21' non-recoverable replication error ReplicationError("Unable to send encrypted dataset 'dozer' to existing unencrypted or unrelated dataset 'frank'")

I have been able to replicate individual datasets from one pool to another, but that just results in encrypted datasets sitting static on the destination pool. I really want a new pool where the encryption/decryption is handled transparently as with the original pool.

I'll be the first to admit that I don't fully understand replication, but it seems that I can't replicate an encrypted pool to a new pool. What am I missing?

 

[winnielinnie]

If this is going to be a one-time transfer to the new pool, all datasets from tank to dozer, then you can possibly do it via the Shell, or SSH, or even an on-demand Cron script.

The confusion lies in the fact that the name of the "pool" also happens to be the name of its "root dataset", which also happens to have special treatment and protection. It is for this reason I now follow a practice of creating "pseudo-root" datasets, that serve as my "true" top level datasets.

As a test, try to send/recv a dataset (and all of its children) that is one level down from tank, to the new pool dozer. You will have to use the raw stream flag, -w, which sends the encrypted dataset "as is", including its properties and children's inheritance.

First make a fresh snapshot of everything in tank. Remember, you're never going to send tank, as it is your "root dataset", even if it contains a snapshot. It's for the sake of simplicity in using the recursive -r option.

Code:

zfs snap -r tank@migrate-to-dozer

Now that all your datasets (even every last child dataset) has this fresh snapshot, try sending one of the top-level (just beneath tank/) datasets to dozer. Pick a smaller one if possible, for the sake of this test. The -w flag is for a raw stream. The -R flag is for recursive. The -d flag on the recv side is to take the part after tank/ and drop it into the part after dozer/

Code:

zfs send -v -w -R tank/stuff@migrate-to-dozer | zfs recv -v -d -F dozer

If this works, you should be able to copy everything over. You will then have to change the inheritance of the datasets, and possibly redo the passphrase protected ones. The reason for this is that by sending a raw stream with -w, each individual dataset retains its properties. They technically inherited from "tank", and will not inherit from "dozer" unless explicitly changed by you.



For some other ideas, and why I use pseudo-roots:

Pseudo-roots

Native ZFS encryption doesn't hide everything

 

[HenchRat]

Yeah, I can send individual encrypted datasets without any issue, but as you note, there's work to do to recreate the various properties and behaviors of the source dataset, which isn't exciting. I'd really like the dataset unlocking/decryption to be handled in the destination pool as it is in the source pool.

I ultimately plan to rename dozer to tank when all is said and done, so I shouldn't have to recreate all of my shares/snapshots/other tasks.

Portability of filesystems/pools/datasets is meant to be a strength of zfs, and that seems greatly complicated by encryption.

 

[HenchRat]

So, it seems that I can't replicate entire pool to a different pool, one for one. zfs objects to the fact that the target already has a filesystem.

root@truenas[~]# zfs send -v -w -R dozer@migrate-to-frank | zfs recv -v -d -F frank
total estimated size is 21.0G
cannot receive new filesystem stream: zfs receive -F cannot be used to destroy an encrypted filesystem or overwrite an unencrypted one with an encrypted one
warning: cannot send 'dozer@auto-2020-12-27_19-46': signal received
warning: cannot send 'dozer@migrate-to-frank': Broken pipe

It seems like one cannot replicate a pool, only the datasets in that pool. This makes some sense, in that if the send were successful, I'd have two "tank" pools, which would certainly be problematic.

If this weren't an encrypted pool with inherited encryption on child datasets, it'd be simple. Just replicate the datasets to another pool, export the old pool, rename/import the destination pool, and frank's your uncle.

It's the encryption that makes this more complex, because I have to somehow restore the inheritance of encryption and keyfiles so that automatic unlocking/mounting of datasets Just Works. I need to do some testing to discern my options.


I begin to see what you mean about pseudo-roots. Given a structure of pool/pseudocryptroot/many-child-datasets, I think I'd be able to replicate pseudocryptroot/many-child-datasets en masse regardless of inheritance, and then just import the keyfile for pseudocryptroot, and all would be well. I'll need to lab this out.

While this particular use case is one time, I'll eventually have to do this operation again when I outgrow this set of disks, or they age out, or I need to move to a new system. So, I might as well get the structure right now.

I wonder how much of this is known-difficult and roadmapped for future enhancement.

 

[winnielinnie]

Yeah, I can send individual encrypted datasets without any issue, but as you note, there's work to do to recreate the various properties and behaviors of the source dataset, which isn't exciting. I'd really like the dataset unlocking/decryption to be handled in the destination pool as it is in the source pool.

Since this is a one-time migration, you can transfer all datasets (and their respective children) to the new pool. After doing so, you'll have to re-inherit encryption properties, likely working your way upwards towards the root dataset. Before you destroy anything on the original pool tank, make sure everything is accessible and checks out on the new pool, dozer.

Portability of filesystems/pools/datasets is meant to be a strength of zfs, and that seems greatly complicated by encryption.

My assumption is that with the new native ZFS encryption, they want to put as many safeguards as possible to avoid overwrite/destroying an existing dataset, let alone the very top root dataset. See my approach below in regards to "pseudo-roots".

I whole-heartily agree with you, unfortunately I think there is a natural rigidness of ZFS when it comes to the interpretation of creating pools. Why is a root dataset created, with the same name, upon creation of said pool? Why can't there exist a zpool without a single dataset, and leave it up to the user to create their own top-level root datasets? (I say that outside of the scope of what ZFS already has become.) It would be in the same light as creating a new, empty folder. I would have designed it differently, but what do I know?



Pseudo-root datasets
Another approach you can do is to create the pool dozer, which automatically creates the root dataset named "dozer". Upon creation, you can have it encrypted (if you wish for your jails in iocage and your .system dataset to inherit encryption.) Theoretically, these two special datasets should be able to be encrypted regardless of the root dataset's lack of encryption, but how TrueNAS currently behaves is you are not prompted with "Would you like .system to be encrypted and unlock automatically upon boot? Make sure to download the pool's encryption keys which will contain .system's key!" The same prompt can be given for the first time you create iocage for your jails. However, I doubt that's ever going to be a feature any time soon, as from a development standpoint, it's simpler to just follow the mantra of "If root dataset is encrypted, this equals 'encrypted pool'. This equals encrypted .system and encrypted iocage. Done. Next."

You will never touch the root dataset dozer again, with the exception of importing/exporting the pool itself. Now you can create multiple (or just one) "pseudo-root" using the following format:

• dozer <--- never touch this
  • zroot1 <--- send/replicate this to backup pools or secondary pools, but no further than up here
    • archives
    • documents
    • downloads
    • media
  • zroot2 <--- send/replicate this to backup pools or secondary pools, but no further than up here
    • isos
    • temp-dump

As you can infer, you will never be sending/replicating "dozer". Rather, the "highest level" dataset you would ever send is zpool1, zpool2, zpool3, etc. No higher than those. (You can even be creative and use names such as zRootMyStuff, zRootUnimportant, etc.)

This is the method I use, and it has given me the fewest headaches. There will naturally be a "break" of inheritance when sending the pseudo-root datasets to a backup / secondary pool, but it's the best I could do. So you'll get something like this (seen below).

In my example, similar colors are using the same keystring/passphrase to encrypt their master key. Notice the difference between them and the root datasets? Notice that the children datasets beneath each "pseudo-root" naturally still inherit the pseudo-root's encryption properties (except for any specific datasets you chose to break inheritance, e.g, using its own unique keystring or passphrase.)


Main pool structure

• tank
  • zroot1
    • archives
    • documents <--- inheritance broken from parent, using different keystring/passphrase)
    • downloads
    • media
  • zroot2
    • isos
    • temp-dump

Backup / secondary / USB / offsite pool structure

• backup-tank
  • zroot1
    • archives
    • documents <--- inheritance broken from parent, using different keystring/passphrase)
    • downloads
    • media
  • zroot2
    • isos
    • temp-dump

From this point onward, any "new" zpools, which have a root dataset by default (named after the pool's name itself), you can send your "pseudo-roots" to them, and they will live comfortably underneath the top-level root dataset. For example:

Code:

zfs send -v -w -R tank/zoot1@snap-XXXXXXXX | zfs recv -v -d -F backup-tank

And for incremental, same principle:

Code:

zfs send -v -w -R -I tank/zoot1@snap-old tank/zoot1@snap-new | zfs recv -v -d -F backup-tank

This should, hopefully, work in the same spirit using the GUI. You would select the "pseudo-root" to replicate; not the top-level root dataset itself.




UPDATED DISCLAIMER: Keep in mind that the keystring / passphrase of the very top-level root dataset will not be associated with any datasets underneath (including the pseudo-roots), thus there will always be a "break" of inheritance at this top level. When importing and unlocking such a pool, you will naturally have to unlock at minimum two items: (1) the root dataset; (2) the pseudo-root dataset

For multiple pseudo-roots, and for special children datasets further down that use their own unique encryption properties, you would have to unlock more than two items.

Remember to backup and save the .json file, which holds all non-passphrase 64-character keystrings for each "encryptionroot" dataset. One keystring per "inheritance group". Passphrases are never saved in such a file, and must be memorized by the user.

The same applies to all pools, even backup pools. You'll just have to "accept" and "live with" the idea that the top-level root dataset of each pool will never have its encryption properties inherited by any datasets underneath (including the pseudo-roots).

Check out this post, in which I explain why you might have to manually edit the .json file in a text editor to reflect the name of the new pool if you did not save the .json file: Same 64-character keystrings, different pool names, different references, different .json files




ANOTHER UPDATE: There's no mandatory reason to use more than one "pseudo-root". The reason I used more than one in my examples is to illustrate the possibilities and flexibility of using this method. (In my personal case, I actually have three pseudo-roots, as each one has a very different role and they are separate from each other. They do not need to replicate nor backup together.)

 

[HenchRat]

To avoid issues, I think my best course of action may be to create a new unencrypted pool with encrypted pseudo roots, and new datasets, inheriting the encryption of the pseudo root, within those pseudo roots, and rsync everything over. That's a pain, but certainly doable.

Unless there's a way to zfs send encrypted datasets to a different pool, stripping the old inherited encryption and adding the new inherited encryption. I know I can specify inheritance of destination encryption using -x encryption but am less sure about stripping old encryption in transit.

 

[winnielinnie]

To avoid issues, I think my best course of action may be to create a new unencrypted pool with encrypted pseudo roots, and new datasets, inheriting the encryption of the pseudo root, within those pseudo roots, and rsync everything over.

Keep in mind that if this ever becomes a pool where you wish your System Dataset (.system) to reside, the System Dataset will be non-encrypted. That's because upon creating .system, it defaults to inheriting encryption properties from the root dataset. (In this case, it inherits "no encryption".) I don't believe there is a way to override this, nor are there plans for such a feature in the future. The same issue technically concerns the first-time creation of iocage for your jails.

Unless there's a way to zfs send encrypted datasets to a different pool, stripping the old inherited encryption and adding the new inherited encryption. I know I can specify inheritance of destination encryption using -x encryption but am less sure about stripping old encryption in transit.

I believe there is a way, which requires sending the key to the receiving side, so that it may decrypt (source key) and then re-encrypt (destination key) upon receiving the stream. I haven't tried this myself. I'm happy with using raw streams -w, and the destination ends up with "locked" pseudo-roots / datasets. Occassionally, I will try to unlock them with my passphrase or 64-character keystrings *(or .json file that contains all such keystrings) to make sure they are still accessible when needed.


* I had to unlock all "encryptionroots" on the secondary dataset, then export the pool's encryption keys, and save this .json as a separate file with an identifiable name. Technically, I can copy+paste the same 64-character keystrings from the original pool's .json file with a text editor, and manually paste them when unlocking the secondary pool, since such pseudo-roots are using the same encryption properties when they were received with the raw -w flag. This doesn't apply to passphrases, as those are left to the user to "memorize" or write down somewhere safe.


Keep in mind, if you change the encryption properties of the source dataset (or pseudo-root), and then send them (incremental old-to-new snapshots) to the destination pool that already contains these pseudo-roots / datasets, the raw flag -w will update the destination's pseudo-root / dataset encryption properties to reflect the source.


Example:

You lock the dataset tank/zroot1 with a passphrase of "myPass1234". All children under tank/zroot1 are configured to inherit their encryption properties from zroot1. The first time you do a full recursive raw send of tank/zroot1 to the pool named "backup", you end up with backup/zroot1, and all its children.

Currently, at this stage, backup/zpool1 is locked with the passphrase "myPass1234".

Later you change the passphrase for tank/zroot1 to be "soDifferent9876". All children under tank/zroot1 are configured to inherit their encryption properties from zroot1. Now with a subsequent incremental recursive raw send of tank/zroot1 to the pool named "backup", you end up with all the changes (updated data, updated snapshots, etc) to backup/zroot1, and all its children. But now backup/zroot1 has its encryption properties changed to reflect what was done on the source. It cannot be unlocked with "myPass1234" anymore. It has been updated to unlock with "soDifferent9876". (Keep in mind this is all possible when everything is in the "locked" state, and nothing is sent in the plain. Both sides can leave their datasets encrypted and locked, and no keys need to be exchanged. The reason -w and -R work, even when the source and destination is "locked", is because it replaces the encryption metadata and hashes, "as is". It's still up to the owner to provide the keyfile, 64-character keystring, or passphrase in order to unlock and decrypt the data within.)

 

[HenchRat]

I decided to punt a bit and just replicate the entire pool tank to pool dozer, without the pseudo roots. I'm not ready to make that change.

My plan is this:
Create new pool dozer, with encryption enabled. (Complete)
Ensure I have a copy of the keyfile in two places. (Complete)
Snapshot and replicate each dataset to dozer (Complete)
Go through, unlock each dataset, and configure it to inherit encryption from dozer. This should result in changing the keyfile associated with each dataset to the root dozer keyfile. Of course, for those datasets with passphrase encryption, I will treat those differently.
Export dozer from GUI.
Import dozer from GUI.
Verify that all dozer datasets are accessible and consistent.
Reboot.
Verify that all dozer datasets unlocked on boot, are accessible, and consistent.
Stop all services.
Ensure I have a copy of tank's keyfile in two places. (I do)
Export tank, leaving all share configuration intact, and NOT destroying data on tank.
Export dozer from GUI
Import dozer from CLI, renaming it to tank in the process. (It will not show up in the GUI after this import.)
Export new tank (erstwhile dozer) from CLI.
Import new tank (erstwhile dozer) from GUI, so it shows up in the GUI.
This should allow all still-extant share configuration to be associated with the (new) tank without any further effort.
Re-enable services, and test.
Reboot.
Verify that new tank (erstwhile dozer) and all datasets are unlocked on boot, accessible, and consistent.
Verify that services are working as expected.
Retain old tank disks for some time until I'm certain things are ok.

What am I missing?

 

[winnielinnie]

What am I missing?

Seems to look good to me, though I've never tried renaming pools in FreeNAS/TrueNAS after they were already created.

Though I must say, using pseudo-roots has made everything moving forward much more streamlined for me, especially for making backups.

Let us know how it works out for you!

 

[HenchRat]

I'm at the point just after re-enable services and test. So far, so good.

The renaming was simple.

zpool import tank old-tank
zpool export old-tank
mv dataset_tank_keys.json dataset_old-tank_keys.json
vi; s/tank/old-tank/g; in dataset_old-tank_keys.json :wq
GUI import old-tank

 

[HenchRat]

One edit:
I had to go through and change each dataset to read/write from read-only.

Past that, seems to have worked perfectly.

 

[HenchRat]

This seems to be the proper sequence:

Create new pool dozer, with encryption enabled. (Complete)
Ensure I have a copy of the keyfile in two places. (Complete)
Snapshot and replicate each dataset to dozer (Complete)
Go through, unlock each dataset, and configure it to inherit encryption from dozer. This should result in changing the keyfile associated with each dataset to the root dozer keyfile. Of course, for those datasets with passphrase encryption, I will treat those differently.
Export dozer from GUI.
Import dozer from GUI.
Verify that all dozer datasets are accessible and consistent.
Reboot.
Verify that all dozer datasets unlocked on boot, are accessible, and consistent.
Stop all services.
Ensure I have a copy of tank's keyfile in two places. (I do)
Export tank, leaving all share configuration intact, and NOT destroying data on tank.
Rename tank to old tank: zpool import tank old-tank then zpool export old-tank
Change keyfile for old-tank. Change the name of the pool in the keyfile from tank to old-tank.
Export dozer from GUI
Change keyfile for dozer. Change the name of the pool in the keyfile from dozer to tank.
Import dozer from CLI, renaming it to tank in the process. (It will not show up in the GUI after this import.)
Export new tank (erstwhile dozer) from CLI.
Import new tank (erstwhile dozer) from GUI, so it shows up in the GUI.
Choose the proper keyfile for (new) tank.
This should allow all still-extant share configuration to be associated with the (new) tank without any further effort.
Go through and change each dataset on (new) tank from read only to read/write.
Re-enable services, and test.
Reboot.
Verify that new tank (erstwhile dozer) and all datasets are unlocked on boot, accessible, consistent, and writable.
Verify that services are working as expected.
Retain old tank disks for some time until I'm certain things are ok.

 

[davidpellerin]

I'm preparing to move a series of datasets residing on one encrypted pool to another pool. This is primarily intended to be a move from a smaller pool of storage to a larger pool of storage, after which point I'll destroy the smaller pool.

The source pool, tank, is set up with TrueNAS 12.0-R ZFS native encryption, not GELI. Most child datasets inherit that encryption, though a couple have their own passphrase-based encryption.

It is my desire to have ALL of my data encrypted, and to NEVER have unencrypted data touch a storage medium. This is in part so that RMAs of drives, should that be necessary, are not a potential source of data leakage.

The destination pool, dozer, was also set up with ZFS native encryption, with its own key.

When I set up a replication task to send the entire pool tank and everything within it to dozer, it fails: "Destination dataset 'dozer' already exists and is it's own encryption root. This configuration is not supported yet. If you want to replicate into an encrypted dataset, please, encrypt it's parent dataset."

OK, fair enough. For the purposes of testing, I created a new dataset on dozer that inherits dozer's encryption, and copied some inconsequential files to that dataset.

I then created another new pool, frank, with no encryption. I then set up a replication task to send all of pool dozer to pool frank.

This also failed:

Error
Unable to send encrypted dataset 'dozer' to existing unencrypted or unrelated dataset 'frank'.
Logs
[2020/12/27 19:46:27] INFO [replication_task__task_21] [zettarepl.replication.run] For replication task 'task_21': doing push from 'dozer' to 'frank' of snapshot='auto-2020-12-27_19-46' incremental_base=None receive_resume_token=None encryption=False
[2020/12/27 19:46:27] ERROR [replication_task__task_21] [zettarepl.replication.run] For task 'task_21' non-recoverable replication error ReplicationError("Unable to send encrypted dataset 'dozer' to existing unencrypted or unrelated dataset 'frank'")

I have been able to replicate individual datasets from one pool to another, but that just results in encrypted datasets sitting static on the destination pool. I really want a new pool where the encryption/decryption is handled transparently as with the original pool.

I'll be the first to admit that I don't fully understand replication, but it seems that I can't replicate an encrypted pool to a new pool. What am I missing?

Hi... I faced the same problem for a while and it's a real pain. I had to manully SMB transfer some things instead of using replications... Yet, if this is still important for you, I found a simple workaround that works everytime.

When creating your replication task, to the left, select the remote dataset you want to sync and then, to the right (on the local machine) DO NOT SELECT any already created datasets; else the system will always give you that message.

Instead, do this:

1. Click / Select the root of the system
2. When the root appears next to the Folder icon with the + sign, then add a front slash and type a new dataset name.

This will create a new dataset exempt of any permissions and Truenas will no longer complain. Data will be synced as needed AND will remain encrypted throughout the process (SSH transfer and to stationary + encryption) using the encryption key of the originaal Truenas Dataset/Pool...

Hoping this helps.

David

 

[Johnny Fartpants]

This was very helpful, thanks @davidpellerin

 

[DD4711]

I'm still struggeling with that. davidpellerins workaround works, but: when unlocking the replicated datasets I have to enter the key for every single dataset instead once at pool level.

This is really painful.

Isn't there an easy to go procedure for the easy intention "replicate an encrypted pool to another place as is (same encryption, same settings, inherit encryption...) for backup purposes"?

 

[winnielinnie]

Isn't there an easy to go procedure for the easy intention "replicate an encrypted pool to another place as is (same encryption, same settings, inherit encryption...) for backup purposes"?

You have to use "pseudo-roots" to achieve that. (See my above post.)

Here's an (old) color-coded version: https://www.truenas.com/community/t...observations-many-questions.89081/post-626232

Unfortunately, a ZFS pool always has a single mandatory "root" dataset imbued upon pool creation, which shares the same name as the pool itself. (No means to create an "empty" pool with the possibility to add multiple top-level root datasets.) I think this is a huge oversight in design by the developers.

If the top-level root dataset is encrypted, it cannot be "replaced" or overwritten by another encrypted dataset from a different pool. (Hence, your frustrations.)

The only change I would make going forward is to always create an "unencrypted pool" (which really means the top-level root dataset will be unencrypted), and then create encrypted pseudo-root datasets and children underneath, as needed. (This is due to recent changes.)

 

[DD4711]

Hello @winnielinnie ,

thanks for your answer. Maybe i misunderstand something.

I have an encrypted pool "local" with datasets and inherit encryptions in my test environment:

local
- 1
- - a
- - b
- - c
- iocage


I created an unencrypted pool "backup" on an external device.

Replication Task:
Source: "local/1,local/iocage" - checked: "recursive", "include Dataset Properties"
Target: "backup" - Checkbox Encryption not checked

After replication finished all replcated datasets ("1" and "a"...) have a lock symbol, the source datasets not. When I now unlock the replcated datasets at the level "1" I have to enter for every dataset under "1" the same password. And in a second step I have to unlock "iocage".

I thought that this behaviour shouldn't occur with your pseudo-root proposal. Or am I doing something wrong?

 

[winnielinnie]

The "encryptionroot" needs to begin at local/1

Currently, your only encryptionroot is local (your top-level root dataset). However, each pseudo-root needs to be its own encryptionroot, of which its children will inherit.

On your local pool, change the encryption properties for 1, and uncheck "inherit". This will make it its own encryptionroot. (Be careful on this part. Don't mistype the "new" password. Double-check. You can use the same exact password.) Verify that the children below 1 are inheriting from it now.

Repeat for iocage on your local pool. (Consider iocage as a pseudo-root in a sense.)

Now when you replicate, your two pseudo-roots (1 and iocage) should be their own encryptionroots on the backup pool, and their children should inherit their encryption properties.


Is this a "test" pool? The sizes seem like this is only a test (which is good, as you don't want to mess up with your actual data.)

Do you plan on housing the System Dataset on your data pool? If so, you won't be able to use a passphrase for the top-level dataset. (If you are going to keep the System Dataset on the boot-pool, then this isn't an issue.) To be honest, a System Dataset on the boot-pool (with quality SSDs) is much less of a headache and simplifies things.

The iocage dataset (the way TrueNAS was designed) will always be nested one-level directly under the top-level root dataset of your pool. (Thus, it will always be its own pseudo-root and encryptionroot on the backup pool.)

Make sure to verify you can unlock and access the datasets on the backup! Even if you won't be accessing the backup pool often, routine "checks" help to avoid an unexpected surprise.



In short, on your local (test) pool, the hierarchy needs to look like this:

local (pool)

• local
  
  • 1 <--- replicate this to backup (full filesystem or recursive with properties)
    
    • a
    • b
    • c
  • iocage <--- replicate this to backup (full filesystem or recursive with properties)

Your backup (test) should look something like this:

backup (pool)

• backup
  • 1 <--- unlock with same passphrase used on source
    
    • a
    • b
    • c
  • iocage <--- unlock with same passphrase used on source

red = encryptionroot
green = encryptionroot
blue = encryptionroot
black = unencrypted

 

[DD4711]

Thanks first for your detailed answer.

Yes, this is just a test installation.

My System Dataset is on the boot-pool.

I changed "1" and "iogace" and unchecked "inherit". a, b and c have still "inherit from parent". So it should now be as per description.

Now I replicate in one task:

• Source Dataset: local/1,local/iocage
• Target Dataset: backup
• Recursive: true

Then I try to unlock "1" and "iocage" on the backup pool and again get the attached unlock window presented. For dozens of encrypted datasets (with same key) it is not really viable :( .

 

[winnielinnie]

Now I replicate in one task:

• Source Dataset: local/1,local/iocage
• Target Dataset: backup
• Recursive: true

What about "Full Filesystem Replication"? It will be recursive and include all properties.

Can you share a screenshot of the Replication Task configuration?