What is the Right Way to pull back an encrypted remote dataset after disaster?

[madsci1016]

I have two full up Scale installs at home. One will eventually go offsite. The main machine has replication jobs to the 'remote' machine for all my datasets, which are encrypted.

In the meantime i want to reorganize the disk layout of my main pool on my main machine (mirror pairs to raidz2). I assume that means destroying the pool (make sure to move system pool) creating a new pool with the new arrangement, and pulling back my datasets from the 'remote' machines.

But i'm trying to test this first. I can't just click recover in the replication task or create a pull task from scratch without error. I point it to a empty local dataset to dump into and i get the error "Unable to send encrypted dataset 'RemoteMainPool/OffsiteHDD' to existing unencrypted or unrelated dataset 'MainPool/Test"

So i guess i'm at a loss, how is recovery from an "offsite " replicated encrypted dataset to a fresh local machine (assuming the disaster destroyed the original) suppose to work exactly, since the new pool will never be not "unrelated". Is it suppose to be just unlock the remote data set locally(at the remote) and rsync back to a new machine?

Tried googling this but wasn't finding a clear answer.

 

[winnielinnie]

What is the dataset layout on your "remote" machine?

Code:

zfs list -r -t filesystem -o name,encryptionroot,encryption <poolname>

 

[madsci1016]

What is the dataset layout on your "remote" machine?

Code:

zfs list -r -t filesystem -o name,encryptionroot,encryption <poolname>

Code:

root@truenas[~]# zfs list -r -t filesystem -o name,encryptionroot,encryption RemoteMainPool/OffsiteHDD
NAME                       ENCROOT                    ENCRYPTION
RemoteMainPool/OffsiteHDD  RemoteMainPool/OffsiteHDD  aes-256-gcm
root@truenas[~]#

 

[winnielinnie]

Did you try in the command-line? You'll need to pass the "-d" option for the receiving side's root dataset as the "target".

Something like this:

Code:

zfs send -vRw RemoteMainPool/OffsiteHDD@snapshot | zfs recv -vsd MainPool

You'll end up with MainPool/OffsiteHDD. (Is that what you want?)

You can then use the "zfs rename" command to rename it something else. (Such as the original dataset's name.)


* Large transfers should be done in a tmux session, so that you don't need to leave the window/terminal open.

tmux cheat sheet: https://tmuxcheatsheet.com

 

[Davvo]

I'm not sure you can replicate an encrypted dataset into an unencrypted one.

 

[madsci1016]

I'm not sure you can replicate an encrypted dataset into an unencrypted one.

I had tried creating an encrypted dataset to restore into and it failed, but seeing your comment i tried again, but created an encrypted child of an encrypted dataset and it's now NOT failing right away so it looks like it's working.

So i guess the unspoken rule is an encrypted dataset must be restored into the encrypted child of an encrypted parent. Since my root pool is not encrypted, just my child datasets, it wasn't working.