Legacy Encryption, system dataset pool, upgrading to zfs encryption

[onlineforums]

Friends,

I need some reassurance of the process to not screw up my configurations, settings, jails, etc!

I recently upgraded from Freenas to Truenas-13.0-U3.1 (CORE) on an Freenas-mini-xl. Everything went totally fine.

My pool (tank01) uses legacy encryption which requires a passphrase to unlock after locking or after a reboot. This works totally fine.

I recently backed my photos, documents and jails (both the dataset and the jails export command tarbar method) from tank01 to an external hard drive using zfs send|receive and verified the data on the external drive contains the irreplaceable photos, documents and jails data. I have disconnected this external hard drive and connected it back in, unlocked it and everything is this looks fine.

I believe now would be a great time to upgrade the tank01 main pool to use the latest and likely the only foreseeable future supported encryption method. My understanding is in doing so I would need to destroy the tank01 pool, upgrade the zfs feature flags and then create the tank01 pool fresh with zfs encryption enabled. If this understanding is incorrect please correct it.

Here are my concerns:
1. System Dataset -> On this page it has the System Dataset Pool as my tank01 (not freenas-boot). Is this the correct setup method? Wouldn't this mean that when I destroy tank01 that I'll also destroy everything about my configurations in Truenas? For example, I have a few simple cron jobs, periodic snapshot tasks, scrub tasks, users accounts, etc. Will this all get destroyed when I destroy tank01 or is all of that data found in the freenas-boot drive/pool? Help me understand the pros and cons of having the "system dataset pool" on the main pool which I believe is common practice since I can have multiple hard drive failures on the main pool but not the freenas-boot pool.

2. Jails and configurations: Right now I have a few jails that run some services that I use internally on my local network. I recursively backed up the iocage dataset and used the jails export command which created a tarball. My concern is that destroying the tank01 pool that the Jails will still show up in the web interface and when i import the jails from the backup to the new zfs encrypted tank01 pool that it will duplicate or cause some problems within the Jails section of the web interface.

Should I just bag the whole idea and keep everything the way it is and forego the zfs encryption? I just want to future proof myself just incase the team decides to totally deprecate, not support and actually remove GUI interfaces to work with legacy encryption created during the FreeNAS era.

 

[winnielinnie]

Will this all get destroyed when I destroy tank01 or is all of that data found in the freenas-boot drive/pool?

All your settings and configurations live in a database file on the boot-pool. (You should have saved a backup of your configuration somewhere safe.)

You can relocate the System Dataset to your boot-pool in the meantime while you do this process. (Even keeping it on the boot-pool might be preferable.)

My understanding is in doing so I would need to destroy the tank01 pool, upgrade the zfs feature flags and then create the tank01 pool fresh with zfs encryption enabled.

You don't need to upgrade any feature flags. The new pool will support native encryption by default. When you create the pool, the option to "encrypt" the pool doesn't actually encrypt the pool. It simply encrypts the root dataset with a keyfile. You can change this to a passphrase later (however, doing so will prevent the System Dataset from living on this pool.)

Help me understand the pros and cons of having the "system dataset pool" on the main pool which I believe is common practice since I can have multiple hard drive failures on the main pool but not the freenas-boot pool.

Losing the System Dataset won't affect your main data pool(s). Nor will you lose your configuration, granted you've backed up your configuration file somewhere safe. It's up to you where to place the System Dataset. If you keep it on your main pool (with spinning HDDs), you'll notice constant drive activity and writes every 5 minutes.

2. Jails and configurations: Right now I have a few jails that run some services that I use internally on my local network. I recursively backed up the iocage dataset and used the jails export command which created a tarball. My concern is that destroying the tank01 pool that the Jails will still show up in the web interface and when i import the jails from the backup to the new zfs encrypted tank01 pool that it will duplicate or cause some problems within the Jails section of the web interface.

Why not delete the jails, and then re-import them from your backups/exports? (I've never tried it myself.)

hould I just bag the whole idea and keep everything the way it is and forego the zfs encryption? I just want to future proof myself just incase the team decides to totally deprecate, not support and actually remove GUI interfaces to work with legacy encryption created during the FreeNAS era.

Waiting for now could be the safer option. Especially considering that once you commit to this, you're in a temporary dangerous spot (since all your data is on the USB drive and nowhere else.)

 

[onlineforums]

All your settings and configurations live in a database file on the boot-pool. (You should have saved a backup of your configuration somewhere safe.)

You can relocate the System Dataset to your boot-pool in the meantime while you do this process. (Even keeping it on the boot-pool might be preferable.)



You don't need to upgrade any feature flags. The new pool will support native encryption by default. When you create the pool, the option to "encrypt" the pool doesn't actually encrypt the pool. It simply encrypts the root dataset with a keyfile. You can change this to a passphrase later (however, doing so will prevent the System Dataset from living on this pool.)



Losing the System Dataset won't affect your main data pool(s). Nor will you lose your configuration, granted you've backed up your configuration file somewhere safe. It's up to you where to place the System Dataset. If you keep it on your main pool (with spinning HDDs), you'll notice constant drive activity and writes every 5 minutes.



Why not delete the jails, and then re-import them from your backups/exports? (I've never tried it myself.)



Waiting for now could be the safer option. Especially considering that once you commit to this, you're in a temporary dangerous spot (since all your data is on the USB drive and nowhere else.)

@winnielinnie thank you for your reply. I hope you don't mind me asking a few follow up questions for myself and lurkers in the future.

What are some pros and cons associated with the System Dataset on the boot-pool versus the storage-pool?

What does the System Dataset even contain?

I like your idea of simply deleting the jails from the UI before destroying the storage pool and then using the jail import feature (probably in the command line).

 

[winnielinnie]

What are some pros and cons associated with the System Dataset on the boot-pool versus the storage-pool?

In my opinion...

System Dataset on the boot-pool pros:

• Spares your data pool drives from frequent writes
• Keeps the System Dataset (and all of its clutter and snapshots) from living on a "pure storage archive" pool.

System Dataset on a data pool pros:

• Can be encrypted (if, and only if, the root dataset is encrypted and protected with a keyfile; not a passphrase)
• Spares the boot drives from frequent writes (if you're still using USB sticks, which is discouraged)

What does the System Dataset even contain?

The System Dataset contains parts of a decentralized database with public (and sometimes private) information about U.S. and Canadian citizens, which originates from a law enacted back in 2006. No two TrueNAS deployments have the exact same information stored on their System Datasets, due to the nature of the database being broken up among a multitude of systems. Because iXsystems has an agreement with the United States Department of Defense, they are legally bound to track and store this user information. (Only applies to U.S. and Canadian citizens. Those who live in the EU are exempt.)

Any attempts to delete a System Dataset on a running/active system is illegal and punishable by law. (I forget the exact amount, but there is a hefty fine involved, somewhere around 3,000 to 4,000 USD.) The one exception is you are allowed to delete the System Dataset, if and only if, you are decommissioning a TrueNAS server.

Truthful (boring) answer: The System Dataset just contains stuff related to SMB caches/permissions, debug dumps, and system logs, among other things. If you lose it or install a brand new TrueNAS system, there is nothing in there that affects your configuration. Meaning that it's "safe to lose" or "start all over", so long as you made a backup of your config file; this config file is unrelated to the System Dataset anyways. (The documentation is incorrect when it claims that the encryption keys for protected pools live here. This is not true. The encryption keyfiles actually live on the boot-pool.)

I like your idea of simply deleting the jails from the UI before destroying the storage pool and then using the jail import feature (probably in the command line).

I never tried it, so I can't say how smooth the process will be.