replication with remote encrypted and locked?

[daemonix]

I have an unencrypted source dataset that I would like to replicate in a remote truenas but in an encrypted form.
My problem is that after the first replication with remote encryption, the remote dataset is unlocked.

How can I get replication to work but without leaving remote data exposed?
Where can I find the right RTFM?

Thanks!

 

[winnielinnie]

Not sure if this is possible in the GUI.

Are you using a passphrase or HEX key for the destination's encryption?

 

[Davvo]

You could use SSH or VPN tunnelling.

 

[daemonix]

Not sure if this is possible in the GUI.

Are you using a passphrase or HEX key for the destination's encryption?

I tested both. The remote side is encrypted but stays unlocked. The remote side allows you to export the key so its unsafe

 

[daemonix]

You could use SSH or VPN tunnelling.

Im not talking about the network traffic, the remote dataset remain unlocked after the competition of the replication task.

 

[Davvo]

Im not talking about the network traffic, the remote dataset remain unlocked after the competition of the replication task.

As it should, since the origin dataset is not encrypted; afaik, you can't replicate an unencrypted dataset into and encrypted one.
But I might be wrong.

 

[winnielinnie]

You might have to submit a feature request for this.

You desire for an automated process to look like so:

1. Source (plain)
2. Encryption key loaded (needed for the next step)
3. Data is encrypted (to be sent to destination)
4. Send over to destination (encrypted)
5. Unload encryption key ("lock") on destination side

Not possible via the GUI as far as I know. (Unless someone knows how.)

It's possible using a script, but this veers away from using the "NAS"-nature of the NAS, and is trickier to automate.

 

[bluonek]

OP - not sure if you're still around and/or if you solved this yet, but there is an extremely simple solution. I'd also hate to be the barer of bad news, but specifically what you're asking will not become a feature of TrueNAS (just my honest opinion, I don't make the rules)

Solution:
1. Encrypt your source data
2. Replicate to a remote machine/dataset without checking the "Encryption" checkbox

This will effectively use the "-w" flag of zfs send and will both send and store your data encrypted at the target. No keys will be sent/saved outside of your local NAS. Snapshots will continue to work and incremental send replication will also continue to work properly even though your data is encrypted at the target.

When you need to recover your data, do a send/recv back to your source from the target, you will *not* need to unencrypt to do this! ZFS replication doesn't care if the dataset remains encrypted during it's operations. The magic of zfs.

 

[winnielinnie]

i just unknowingly necro'd - oh well.................................

Twice within the span of minutes.

@bluonek is an all-powerful necromancer.

 

[bluonek]

meh, this one was on purpose =P

 

[daemonix]

OP - not sure if you're still around and/or if you solved this yet, but there is an extremely simple solution. I'd also hate to be the barer of bad news, but specifically what you're asking will not become a feature of TrueNAS (just my honest opinion, I don't make the rules)

Solution:
1. Encrypt your source data
2. Replicate to a remote machine/dataset without checking the "Encryption" checkbox

This will effectively use the "-w" flag of zfs send and will both send and store your data encrypted at the target. No keys will be sent/saved outside of your local NAS. Snapshots will continue to work and incremental send replication will also continue to work properly even though your data is encrypted at the target.

When you need to recover your data, do a send/recv back to your source from the target, you will *not* need to unencrypt to do this! ZFS replication doesn't care if the dataset remains encrypted during it's operations. The magic of zfs.

Thanks for taking the time.

This is what I did. I started making encrypted copies of the dataset and the replicated each one. All fine!
I dont like the idea that if the source system restarts I need to unlock everything (its not in an insecure location) but I think Ill add something on a rc file (I know.. not a secure practice).

 

[winnielinnie]

1. Encrypt your source data
2. Replicate to a remote machine/dataset without checking the "Encryption" checkbox

This will effectively use the "-w" flag of zfs send and will both send and store your data encrypted at the target. No keys will be sent/saved outside of your local NAS. Snapshots will continue to work and incremental send replication will also continue to work properly even though your data is encrypted at the target.

The GUI doesn't make this obvious. That's why it causes confusion for people who want to use "encryption" for their replications. ("Surely I have to check the encryption box if I want the destination to be encrypted? Right?")

 

[daemonix]

The GUI doesn't make this obvious. That's why it causes confusion for people who want to use "encryption" for their replications. ("Surely I have to check the encryption box if I want the destination to be encrypted? Right?")

Indeed is weird, but it make sense if you read how replication happens with raw “bytes“.

 

[winnielinnie]

Still should be outright explained in the GUI. As it stands now, it's unclear. By all means, they make it seem like you need to "enable encryption" for the destination by checking the encryption box.

I guess in iXsystems' defense, there was no such thing as sending raw encrypted streams back then when they designed the TrueNAS GUI. (This probably means if it does get fixed, it'll only be for SCALE.)

 

[Gigajoule]

OP - not sure if you're still around and/or if you solved this yet, but there is an extremely simple solution. I'd also hate to be the barer of bad news, but specifically what you're asking will not become a feature of TrueNAS (just my honest opinion, I don't make the rules)

Solution:
1. Encrypt your source data
2. Replicate to a remote machine/dataset without checking the "Encryption" checkbox

This will effectively use the "-w" flag of zfs send and will both send and store your data encrypted at the target. No keys will be sent/saved outside of your local NAS. Snapshots will continue to work and incremental send replication will also continue to work properly even though your data is encrypted at the target.

When you need to recover your data, do a send/recv back to your source from the target, you will *not* need to unencrypt to do this! ZFS replication doesn't care if the dataset remains encrypted during it's operations. The magic of zfs.

Hi, Sorry if I'm restarting this conversation. But I have a similar requirement.

Currently I have several unencrypted truenas systems that sync to rsync.net via Truenas replication task. The datasets are encrypted during transit and encrypted with an encryption key on the remote end.

If I understand right this method only works if the source dataset is encrypted (which is unfortunately a performance hindrance for us at the moment)

Is there a way to remove/offload the encryption keys and the datasets after a replication has happened. If not from the GUI is it possible to identify on the remote end that a replication task is running/has finished so I could manually script something that just unloads the keys and the datasets etc...?

 

[bluonek]

Hi, Sorry if I'm restarting this conversation. But I have a similar requirement.

Currently I have several unencrypted truenas systems that sync to rsync.net via Truenas replication task. The datasets are encrypted during transit and encrypted with an encryption key on the remote end.

If I understand right this method only works if the source dataset is encrypted (which is unfortunately a performance hindrance for us at the moment)

Is there a way to remove/offload the encryption keys and the datasets after a replication has happened. If not from the GUI is it possible to identify on the remote end that a replication task is running/has finished so I could manually script something that just unloads the keys and the datasets etc...?

You probably could, since anything is possible - but I'd recommend encrypting the source and using the method described in this thread. Trying to go against the grain of ZFS or TrueNAS usually leads to a life of pain and misery =p

 

[bluonek]

(This probably means if it does get fixed, it'll only be for SCALE.)

Don't get me started on this one. Here, I thought we as a human race were moving away from explicitly inefficient systems like bitcoin's proof processing, snap and docker.....................................

 

[daemonix]

Don't get me started on this one. Here, I thought we as a human race were moving away from explicitly inefficient systems like bitcoin's proof processing, snap and docker.....................................

docker? (its ok no?)

 

[Davvo]

docker? (its ok no?)

HA, they wish.

 

[jaceknowak8424]

Here is my (tested) solution.
Assumption: I wanted to use as much as possible built-in functionality.

It should work with both Scala and Core. Tested on Scala->Core and Scala->Scala. Basically you need to 'initiate' backup manually for the first time. Then you configure it via GUI and it works nicely.

What will not work, not tested

• you cannot set up this without initial sync done via command line
• never tested form locked source system - but should possibly work as well

What is end-result:

• you end up with very nice gui-driven replication task
• you can use built in feature to preserve snapshots (nice)
• on target system you have UNENCRYPTED pool with ENCRYPTED datasets
• your target system don't need to be unlocked for backup to succeed
• most probably you can restore full snapshot from target -> source but NEVER TESTED
• you can unlock dataset(s) on target system and move needed data (rsync, copy etc) to source TESTED

I've originally used script to detect soource / target systems snapshots dates to calculate proper parameters for send '-i' incremental and run backup as a script. But gui-driven version is much nicer because 'incremental' parameter is handled in background.

Procedure:

1. Create on target (one used to store backup) system your pool. Use 100% defaults. (no encryption, no fancy stuff)
   • BTW: this should also work on any decent (open)ZFS supported system -> only problem is probably with replication wizard (gui) ; never tested (yet)
2. Get your ssh keys / connectivity ready from SOURCE to TARGET system. Much, much better to do with keys!
   • in ssh you use '-i /path/to/priv_key/file.key' parameter to indicate key that has corresponding priv key in target system
   • for ssh you can use ssh connection keys from freenas (you will need this! anyway),
   • for key scenario DO TEST CONNECTION so the key is added to trusted
3. Check your latest or latest-1 snapshot name(s) for your dataset(s)
   • easy way: zfs list -t snapshot -o name -s creation | grep 'SOURCE_POOL_NAME/DATASET_NAME.*' | tail -n 2 this will give you two latest names
   • if you have a lot of data that will initially replicate longer than your snapshot window -> go for latest snapshot in following instruction (step 4)
   • if your initial replication will be fast to finish before next snapshot, yous latest-1 name, so you can quickly test 'final' setup with latest snapshot.
4. For each SOURCE dataset prepare command to run. If you have maaaany datasets then script it out, but it is one-time action so why to bother.
   • for each SOURCE dataset have line like that (example, replace 'tank' & 'files@...' with your details):
     • zfs send -vwR tank/files@auto-2024-01-01_00-00 | zfs receive -vF tank_backup/files (for situation that has backup media directly attached to SOURCE system for initial backup)
     • zfs send -vwR tank/files@auto-2024-01-01_00-00 | ssh -i /path/to_ssh_key_file/file.key 192.168.1.2 zfs receive -vF tank_backup/files (for situation that has backup media is on TARGET 192.168.1.2 system via SSH for initial backup)
   • I do this by preparing line by line commands in notepad and then pasting it all together via SSH (don't forget to have extra newline at the end of copied text) and then leave it for a looong while
5. Verify if you get your datasets on TARGET system. Unlock, browse, check files ETC. All should be there.
6. Set up you replication task via TNAS GUI
   • important: set up ANY replication task (even not working) and only then go end edit it. Using wizard it will AutoStart after edition! After saving, run it manually first and click on 'pending' to see if all is good in background.
   • as on picture
   • 
     
   • important: if you have only one dataset you configure SOURCE dataset explicitly and TARGET dataset explicitly; but if you have multiple datasets you configure SOURCE datasets explicitly (as on picture) and root pool as a target!
7. Verify & enjoy