TrueNAS Replication with Encrypted Datasets

[svtkobra7]

Hi,

Is there a solid resource on working with encrypted datasets in TrueNAS that anyone can point to?

Non-encrypted datasets work just fine - but I can't seem to get it to work for encrypted datasets, receiving the error:
Destination dataset 'Tank-01/01-01' 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.

In my case ... Prior to migrating to TrueNAS, both TrueNAS-01 & -02 (then "FreeNAS") had legacy GELI-encryption and I had no issue seeding replication and then handing over to the GUI for management, as needed. See Figure 1, below for general schema, adapted to TrueNAS. See Figure 2, below for seed commands.

Now with TrueNAS, I've attempted to utilize a similar schema, but I've had no luck. On both instances, the pool does not have encryption, but Tank-01/01-01 on TrueNAS-01 is encrypted, and similarly I would like the corresponding dataset on -02 to be encrypted as well.

I've poked and prodded ... and attempted to find the answer myself, to no avail. Can anyone provide a much needed hand here, please?

FIGURE 1. REPLICATION SCHEMA

Code:

TrueNAS      DIRECTION   TrueNAS      Incremental  Seed          Comment
-01          (=> or <=)  -02          Task         Task

  Tank-01                  Tank-01    N/A (Pool)   N/A (Pool)

    01-01        =>          01-01    Inc_Task-01  Seed_Task-01  01-01 & 01-01 both encrypted DS with passphrase
      DS_01                    DS_01  Inc_Task-01  Seed_Task-02
      DS_02                    DS_02  Inc_Task-01  Seed_Task-03

    01-02        =>          01-02    Inc_Task-02                Not encrypted
    02-01        <=          02-01    Inc_Task-03                02-01 & 02-01 both encrypted DS with passphrase
    02-02        <=          02-02    Inc_Task-04                Not encrypted

for clarity, via #zfs list
NAME                 ...  MOUNTPOINT
Tank-01                   /mnt/Tank-01
Tank-01/01-01             /mnt/Tank-01/01-01
Tank-01/01-01/DS_01       /mnt/Tank-01/01-01/DS_01
Tank-01/01-01/DS_02       /mnt/Tank-01/01-01/DS_02

FIGURE 2. REPLICATION SEEDING

Code:

Seed_Task-01  zfs send Tank-01/01-01@SNAP-YYYY-MM-DD_HH-MM | mbuffer -s 128k -m 1G -O <TrueNAS-02 IP>:9001
              mbuffer -4 -s 128k -m 1G -I 9001 | zfs receive -F Tank-01/01-01

Seed_Task-02  zfs send Tank-01/01-01/DS_01@SNAP-YYYY-MM-DD_HH-MM | mbuffer -s 128k -m 1G -O <TrueNAS-02 IP>:9002
              mbuffer -4 -s 128k -m 1G -I 9002 | zfs receive -F Tank-01/01-01/DS_01

Seed_Task-03  zfs send Tank-01/01-01/DS_02@SNAP-YYYY-MM-DD_HH-MM | mbuffer -s 128k -m 1G -O <TrueNAS-02 IP>:9003
              mbuffer -4 -s 128k -m 1G -I 9003 | zfs receive -F Tank-01/01-01/DS_02

 

[winnielinnie]

I don't want to sound rude or harsh, and I really want to see if I can help (or if others can help), so maybe it's a deficiency in my own reading and comprehension abilities. I struggle with non-meaningful names; in the case: numbers.

My brain keeps skipping and looping between Tank-01, Tank-02, 01-01, Tank-02's 01/01-01, DS_01 and DS_02, TrueNAS-02, and as I'm writing this I realized there is no Tank-02. I must have mistaken it somewhere.

When I write out examples, I tend to use easily distinguished names (e.g, media, downloads, documents, backups) or names of animals, etc.


I'll try to re-read your post again. In the meantime, you might find these threads helpful. What I laid out might click with an "aha!" in your situation:

Confused by native ZFS encryption, some observations, many questions

Help moving pool to new disks


I linked to the entire threads, rather than specific posts, since they make more sense with their original context. You will see some "example scenarios" I wrote inside. I have never used mbuffer to speed up send/recv, so I defer that to you and assume it changes nothing with the general principles of native ZFS encryption.

 

[svtkobra7]

I don't want to sound rude or harsh, and I really want to see if I can help (or if others can help), so maybe it's a deficiency in my own reading and comprehension abilities. I struggle with non-meaningful names; in the case: numbers.

• Not harsh at all. I'd rather receive your genuine feedback than praise for what I know is an unenthusiastic naming convention, which believe it or not is aligns to actual, e.g. SMCI-01, ESXi-01, TrueNAS-01, repeat ;)

My brain keeps skipping and looping between Tank-01, Tank-02, 01-01, Tank-02's 01/01-01, DS_01 and DS_02, TrueNAS-02, and as I'm writing this I realized there is no Tank-02. I must have mistaken it somewhere.

• You didn't miss it and point noted ;)

When I write out examples, I tend to use easily distinguished names (e.g, media, downloads, documents, backups) or names of animals, etc.

• Other than the actual names of the datasets, that "diagram" was accurate, and while I'm not sure how much value it adds, or the code block did to begin with, here is a screen capture.
• I have a miniature schnauzer already, so with a standard and a giant, my less than creative self will be able to emulate cats, kittens, runts. He will be 16 in a few days, so I suppose he could be "old_schnauzer" ("oldpool") and as succession planning implemented, the puppy could be "new_schnauzer" ("newpool"). Or, in the alternative, sending his dna to South Korea, could result in "cloned_schnauzer". ;)
• Here he is in a cage of easystore boxes (unsure how he slept through that) ...
• 
  ... I digress, and about that screenshot:

I'll try to re-read your post again. In the meantime, you might find these threads helpful. What I laid out might click with an "aha!" in your situation:

• It may not be worth your trouble, now ...
• I was able to replicate another encrypted dataset previously, but prior to drafting my post yesterday, forgot how I landed there.
• The answer = I had to let the GUI "seed" the replication, instead of performing that via CLI.

Confused by native ZFS encryption, some observations, many questions

Help moving pool to new disks

I linked to the entire threads, rather than specific posts, since they make more sense with their original context. You will see some "example scenarios" I wrote inside. I have never used mbuffer to speed up send/recv, so I defer that to you and assume it changes nothing with the general principles of native ZFS encryption.

• I lightly perused your post (which is solid btw) ... and definitely look forward to a deeper dive later today when I have some unadulterated time). But I believe I see the answer in there already.
• mbuffer was probably more relevant in days of yesteryear when it seemed impossible to top 2Gbps via replication, but given replication speed has increased handsomely and ssh + netcat is even inbuilt now, there may be little to no difference in speed, CLI v. GUI.
• Again, nice compendium and thanks for the help.

Happy Holidays.