It's worth pointing out that zfs-send / recv does not require the encryption keys. So you can have a remote server which uses a user account which only has zfs-send rights (thanks to the zfs permissions structure) to receive an encrypted dataset, which it also cannot read. Agentless, immutable, remote backups with zero trust.
Off topic but I saw on the forum there was a post about the TrueCharts version of Plex with issues on remote access and someone suggesting a video on it. I second that and would love to chip in with the costs for a video on that in the near future if possible!
They used to have it where the key was not kept on the system boot disk. I wish there was an option to keep the key off the server and supply when unlocking...
On vanilla BSD I store the keys on a very small ramdisk, I boot to single user and copy them to the ramdisk from USB, then continue booting. I dont use Truenas so im not sure if that is possible here, might be worth checking.
I wish there were another protection layer or options to protect when you export the key files. So even people who get physical access to machines still cannot steal your key. I guess the passphrase always is an option.
Great video! I have a question. If the Unencrypted dataset is within an Encrypted dataset, It could be a way to read the Unencrypted data even if the Parent Dataset is locked and encrypted?
It is excluded by default when you encrypt the root. So it will likely a bad idea, if it even allows you to do this. You of course can try this using a VM
The real challenge with deduplication is that it requires an absurd amount of RAM to run well. As a very(!) rough rule of thumb you should have at least 256 GB of RAM. That is more a warning than guidance, though. If you really want to use deduplication, please check with the TrueNAS forum first and get input from the experts there.
if you have your main dataset encrypted, but you have an unencrypted dataset below that, I assume the unencrypted set is not accessible if you haven't unencrypted the parent dataset ?
So, if I have a strong password to admin and all SMB shares are restricted to users with good passwords, then my data is safe even if I loose the whole system, right?.... Right?
If the datasets are not encrypted, and your drives are stolen, your data can be accessed by accessing your drives through another system without any need for passwords at all.
For passphrase it would have been nice if Samba would able to pass that phassphrase from the client. So share would never be unlocked on the server side.
I don't undrestand where is the key for encrypting the data. I think passphrase or keyfile is just ways to unlock the encryption key. If passphrase or keyfile would be actual encryption keys, then changing passphrase would require decrypting and again encrypting all TB of data which is long process. Does it take long time? This is how Veracrypt or PGP works: Keyfile or passphrase aren't actual encryption keys. Locked (encrypted) encryption keys are in the header of the volume with copies in other places. Passphrase decrypt encryption key which is used for decrypting data.
TrueNAS Documentation
www.truenas.com/docs/core/coretutorials/storage/pools/storageencryption/
www.truenas.com/docs/core/coretutorials/systemconfiguration/configuringkmip/
Dedupe Discussion
github.com/openzfs/zfs/discussions/9423
It's worth pointing out that zfs-send / recv does not require the encryption keys. So you can have a remote server which uses a user account which only has zfs-send rights (thanks to the zfs permissions structure) to receive an encrypted dataset, which it also cannot read. Agentless, immutable, remote backups with zero trust.
That opening line is so true, awesome way to put it. New T-Shirt designs may be coming soon, check back frequently? ;)
it would be amazing on a shirt now that you mention it
Encyrption , i like it.
Deduplication and encryption working together... sounds interesting. Probably not for the faint of heart. Or at least not those without math degrees.
Has been done routinely in Solaris for 20 years.
I know 8th grade math at best.
Off topic but I saw on the forum there was a post about the TrueCharts version of Plex with issues on remote access and someone suggesting a video on it. I second that and would love to chip in with the costs for a video on that in the near future if possible!
They used to have it where the key was not kept on the system boot disk. I wish there was an option to keep the key off the server and supply when unlocking...
You might be able to set one up with symlinks.
On vanilla BSD I store the keys on a very small ramdisk, I boot to single user and copy them to the ramdisk from USB, then continue booting. I dont use Truenas so im not sure if that is possible here, might be worth checking.
It is of course possible, but not from the GUI, and almost nobody knows grub or indeed the OS well enough to do it.
I wish there were another protection layer or options to protect when you export the key files. So even people who get physical access to machines still cannot steal your key. I guess the passphrase always is an option.
Great video! I have a question. If the Unencrypted dataset is within an Encrypted dataset, It could be a way to read the Unencrypted data even if the Parent Dataset is locked and encrypted?
I don't think so.
@@LAWRENCESYSTEMS honestly I don't understand why they should give that option..
Do you run into any trouble if the ix-applications (dataset for applications in Truenas scale) dataset is encrypted?
It is excluded by default when you encrypt the root. So it will likely a bad idea, if it even allows you to do this. You of course can try this using a VM
The real challenge with deduplication is that it requires an absurd amount of RAM to run well. As a very(!) rough rule of thumb you should have at least 256 GB of RAM. That is more a warning than guidance, though. If you really want to use deduplication, please check with the TrueNAS forum first and get input from the experts there.
if you have your main dataset encrypted, but you have an unencrypted dataset below that, I assume the unencrypted set is not accessible if you haven't unencrypted the parent dataset ?
It depends whether you configured the child dataset to include the encryption value of the parent dataset.
So, if I have a strong password to admin and all SMB shares are restricted to users with good passwords, then my data is safe even if I loose the whole system, right?.... Right?
Having a password on a dataset protects the data if the machine is physically taken.
If the datasets are not encrypted, and your drives are stolen, your data can be accessed by accessing your drives through another system without any need for passwords at all.
For passphrase it would have been nice if Samba would able to pass that phassphrase from the client. So share would never be unlocked on the server side.
That would not be good for security
I don't undrestand where is the key for encrypting the data. I think passphrase or keyfile is just ways to unlock the encryption key. If passphrase or keyfile would be actual encryption keys, then changing passphrase would require decrypting and again encrypting all TB of data which is long process. Does it take long time?
This is how Veracrypt or PGP works: Keyfile or passphrase aren't actual encryption keys. Locked (encrypted) encryption keys are in the header of the volume with copies in other places. Passphrase decrypt encryption key which is used for decrypting data.
The key is located in the TrueNAS config database and because the encryption is done at the ZFS file system level it can happen that fast.
Just going to point out the "encyrption" typo in the thumbnail. Not a big deal really
Thanks, fixed it
How the download looks like?? What?