Steps to upgrade from Unencrypted to Encrypted w/ 2 TrueNAS

[user000]

Hello,

I’ve wanted to upgrade my unencrypted pool to encrypted and I have two TrueNAS systems. I was wondering if the steps I outlined below would work to do this. Has anyone done this before? Is there anything here that I’m missing?

My plan to implement encryption. Note that everything on the unencrypted pool (A) is a dataset. I have no zvols. I’d create an encrypted pool on TrueNAS (B) then do a “Full Filesystem Replication” and “inherit encryption” replication task from my unencrypted pool (A) to my encrypted pool (B). I’d do a sanity check that the data is intact and then delete my unencrypted pool on (A).

I’d create a new encrypted pool on (A) and then create a replication task on the encrypted system (B) also with “Full Filesystem Replication” and “inherit encryption” enabled to replicate to the newly created encrypted pool on (A). I’d export and save each pools unique key.

Would this work to enable encryption on a previously unencrypted pool?

This method produces two separate keys on each TrueNAS which I can change to be the same key if i wanted in the GUI tools

Thanks for the help,
Max

[winnielinnie]

What does your setup look like right now?

Do you have a root dataset on Pool A where children are nested directly beneath it? This is important.

If you’re not using a setup like this, then there’s extra consideration for the replications, if you want to maintain the same hierarchy and layout.

Sadly, the way ZFS was originally designed introduces some weird issues with replication. When a pool is created, it immediately creates a mandatory “root dataset” with the same name as the pool.

To add more flexibility, you can create “pseudo root datasets” underneath for easier management, especially when it comes to logical separation and replicating encrypted datasets.

Think of the “root dataset” as an empty extension of the pool itself, while the “pseudo root datasets” are glorified keychain holders. No files will be saved within.

[user000]

Hello, there are a few things that I’m actually confused about and feel there are some inconsistencies with some terms in ZFS and terms in TrueNAS. I’m sorry if this feels pedantic, but I’d just like to make sure my understanding is correct.

When you first setup TrueNAS and create a “Pool”. You select Storage and then select the devices in storage to create vdev’s. This is where the pools live or rather by TrueNAS terms “Datasets”. These “Datasets” are actually Pools, correct? Please forgive me regarding my setup below this was my first TrueNAS configuration and I’m still learning.

@winnielinnie

Do you have a root dataset on Pool A where children are nested directly beneath it? This is important.

Based on your question and my understanding of ZFS. Backup and main are both pools. SMB_general and Syncthing are both dataset’s and both root datasets. They have no children.

The way these are setup right now is that “main” is replicating to “backup”. You can see they share relatively the same size.

I plan to rename everything. The new encrypted pool will be “tank” (B), and I will keep everything under one pool. I’ll then delete both of these pools main and backup on (A). I’d create a new pool on (A) with a different name encrypted, and replicate from (B) → (A) once with the “Full Filesystem replication” and “inherit encryption” enabled. Then I will setup a replication task between (A) → (B). I want (A) to always be my primary NAS because it’s geographically closer to me.

[winnielinnie]

@user000

This is where the pools live or rather by TrueNAS terms “Datasets”. These “Datasets” are actually Pools, correct?

No. Datasets are not pools.

Devices construct vdevs.

Vdevs construct pools.

Pools offer capacity (preferably with redundancy from redundant vdevs), which can offer logical filesystems called “datasets”.

A pool can be comprised of one vdev. It can also be comprised of multiple vdevs.

flowchart TD

style pool1 stroke:green,stroke-width:4px
style vdev1 stroke:green,stroke-width:2px
style vdev2 stroke:green,stroke-width:2px

hdd1[[8-TiB<br>HDD]]
hdd2[[8-TiB<br>HDD]]
hdd3[[8-TiB<br>HDD]]
hdd4[[8-TiB<br>HDD]]
vdev1((8-TiB<br>mirror vdev))
vdev2((8-TiB<br>mirror vdev))
pool1[(16-TiB pool)]
ds1{dataset}
ds2{dataset}
ds3{dataset}
ds4{dataset}

hdd1 === vdev1
hdd2 === vdev1
hdd3 === vdev2
hdd4 === vdev2

vdev1 === pool1
vdev2 === pool1

pool1 -..- ds1
pool1 -..- ds2
pool1 -..- ds3
pool1 -..- ds4

---

[user000]

I’m talking about the menu selection Datasets, and not the “Add Dataset” button. I understand that a Dataset is for an SMB share or something that acts like a fileystem. The Datasets selection in the left menu is a Pool, right?

So, in this image below the Pool is called “Tank”?

[winnielinnie]

@user000

So, in this image below the Dataset/Pool is called “Tank”?

This is why I think the original design for ZFS was a mistake.

@winnielinnie

Sadly, the way ZFS was originally designed introduces some weird issues with replication. When a pool is created, it immediately creates a mandatory “root dataset” with the same name as the pool.

That thing in your screenshot is the “root dataset”. The root dataset is still a dataset. It is also named the same as the pool itself.

EDIT: To better help understand. In the command-line, any commands that start with zfs deal with datasets (and zvols and snapshots). Any commands that start with zpool deal with pools (and vdevs).

In the GUI, you only deal with datasets under the “Datasets” section.

[user000]

Hello, here is a text diagram of what I plan to do to upgrade my encryption and then implement the pseudo roots moving forward. I read through a lot of your past posts, thank you for sharing your knowledge! I was able to extrapolate the below diagram from your recommendations. I wasn’t sure of the implications of an un-encrypted true root dataset. Is it generally better to have your default true root dataset un-encrypted? I saw you mentioned it in one of your posts.

With each of these replication tasks do I need to tick the inherit encryption of the other one?

Does this plan look sound?

#—————————STAGE 0—————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
SITE A - This is the current state of SITE A                                             |   SITE B - This is the current state of SITE B
                                                                                         |
Main <----- TRUE-ROOT - NOT ENCRYPTED                                                    |   SiteB-TrueRoot   <----- TRUE-ROOT - NOT ENCRYPTED
│                                                                                        |   │
├── SMB_General   <---DELETE                                                             |   ├── SiteB-NVMEStrg  <-- PSEUDO-ROOT ENCRYPTED NO DATA HERE 
├── Syncthing     <---DELETE                                                             |   │    ├── SiteB-VMStorage    <-- ZVOL DATA HERE
│                                                                                        |   │    ├── SiteB-Misc.        <-- ZVOL DATA HERE
│                                                                                        |   │    └── SiteB-Misc.        <-- ZVOL DATA HERE
│                                                                                        |   │
│                                                                                        |   └── SiteB-SSD2TB    <-- PSEUDO-ROOT ENCRYPTED NO DATA HERE
├── SMB_General (NOT ENCRYPTED)  >--------------REPLICATION-STAGE0-----------------------|------> ├── SiteB-SMB          <-- DATA HERE SMB
├── Syncthing (NOT ENCRYPTED)    >--------------REPLICATION-STAGE0-----------------------|------> └── SiteB-Syncthing    <-- DATA HERE
                                                                                         |
#—————————STAGE 1——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
SITE A - Rebuild                                                                         |   Site B - replication TASK from zvols to SITE A and recovery of Encrypted Data to Site A   
                                                                                         |
SiteA-RealRoot   <----- TRUE-ROOT - NOT ENCRYPTED                                        |   SiteB-RealRoot   <----- TRUE-ROOT - NOT ENCRYPTED
│                                                                                        |   │
├── SiteA-SSD500gb  <-- PSEUDO-ROOT ENCRYPTED NO DATA HERE   <-----REPLICATION-STAGE1----|--<├── SiteB-NVMEStrg  <-- PSEUDO-ROOT ENCRYPTED NO DATA HERE
│    ├── SiteA-VMStorage    <-- ZVOL DATA HERE                                           |   │    ├── SiteB-VMStorage    <-- ZVOL DATA HERE
│    ├── SiteA-Misc.        <-- ZVOL DATA HERE                                           |   │    ├── SiteB-Misc.        <-- ZVOL DATA HERE
│    └── SiteA-Misc.        <-- ZVOL DATA HERE                                           |   │    └── SiteB-Misc.        <-- ZVOL DATA HERE
│                                                                                        |   │
└── SiteA-SSD1TB    <-- PSEUDO-ROOT ENCRYPTED NO DATA HERE   <-----REPLICATION-STAGE1----|--<└── SiteB-SSD2TB    <-- PSEUDO-ROOT ENCRYPTED NO DATA HERE
     ├── SiteA-SMB          <-- DATA HERE SMB                                            |        ├── SiteB-SMB             <-- DATA HERE SMB
     └── SiteA-Syncthing    <-- DATA HERE                                                |        └── SiteB-Syncthing       <-- DATA HERE
                                                                                         |	 
#—————————STAGE 2——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
SITE A - The final form                                                                  |   SITE B - The final form
                                                                                         |
SiteA-RealRoot   <----- TRUE-ROOT - NOT ENCRYPTED                                        |   SiteB-RealRoot   <----- TRUE-ROOT - NOT ENCRYPTED
│                                                                                        |   │
├── SiteA-SSD500gb  <-- PSEUDO ROOT ENCRYPTED NO DATA HERE     <----REPLICATION-STAGE2---|--<├── SiteB-NVMEStrg  <-- PSEUDO-ROOT ENCRYPTED NO DATA HERE 
│    ├── SiteA-VMStorage    <-- ZVOL DATA HERE                                           |   │    ├── SiteB-VMStorage    <-- ZVOL DATA HERE
│    ├── SiteA-Misc.        <-- ZVOL DATA HERE                                           |   │    ├── SiteB-Misc.        <-- ZVOL DATA HERE
│    └── SiteA-Misc.        <-- ZVOL DATA HERE                                           |   │    └── SiteB-Misc.        <-- ZVOL DATA HERE
│                                                                                        |   │
└── SiteA-SSD1TB    <-- PSEUDO-ROOT ENCRYPTED NO DATA HERE     >-----REPLICATION-STAGE2--|-->└── SiteB-SSD2TB    <-- PSEUDO-ROOT ENCRYPTED NO DATA HERE
     ├── SiteA-SMB          <-- DATA HERE SMB                                            |        ├── SiteB-SMB          <-- DATA HERE SMB
     └── SiteA-Syncthing    <-- DATA HERE                                                |        └── SiteB-Syncthing    <-- DATA HERE
	                                                                                     |

[winnielinnie]

@user000

Does this plan look sound?

I think so? I’m confused by Stage 2. Why are you going in the opposite direction for SiteA-SSD1TB → SiteB-SSD2TB ? It already exists on Site B.

The names also seem odd. “SSD” and “XTB” make it seem like you’re dealing with separate pools of particular devices. Why is a “size” in the name of the datasets?

---

@user000

Is it generally better to have your default true root dataset un-encrypted?

For TrueNAS? Yes, yes, yes, yes, and yes. It will save you a future of headaches.

The only caveat is that your System Dataset (.system) and Apps dataset (ix-virt, ix-apps) will be unencrypted.

---

@user000

With each of these replication tasks do I need to tick the inherit encryption of the other one?

What do you mean by this? Are you referring to after the one-time migration replication completes?

[user000]

Sorry, for the delayed response. I was spending time all week ordering the parts that will make up the system at Site B.

@winnielinnie

I think so? I’m confused by Stage 2. Why are you going in the opposite direction for SiteA-SSD1TB → SiteB-SSD2TB ? It already exists on Site B.
The names also seem odd. “SSD” and “XTB” make it seem like you’re dealing with separate pools of particular devices. Why is a “size” in the name of the datasets?

Site A is physically closer to me and I’ll be able to access SMB over LAN here. I want to keep my regularly accessed files on the NAS at Site A and replicate them to Site B as offsite backup. The other ZVOL storage will be used only at Site B, attached to my hypervisor, so replicating it back to Site A will give me my second location.

Regarding the naming, I’m not committed to this scheme. I just threw names into the diagram and based them on the devices comprising each dataset. If you have any tips for naming, thanks! I plan to change them later.

@winnielinnie

The only caveat is that your System Dataset (.system) and Apps dataset (ix-virt, ix-apps) will be unencrypted.

I actually was considering making another post about this. I still do not understand this part. Is this referring to the data that is stored in a dataset as indicated by the TrueNAS logo? So, that .system file is stored in my main dataset as indicated by the TrueNAS logo to the left of that share icon?

@winnielinnie

What do you mean by this? Are you referring to after the one-time migration replication completes?

I was saying at each stage i would tick the “inherit encryption” option, but maybe this is unnecessary.

Do I only need to select “inherit encryption” option for Repliaction-STAGE0? Then after that is completed after the replication-STAGE1 is completed I can just import my key from Site B into Site A? Then I’d need to just store one key for all my encrypted data on both sites.

[winnielinnie]

@user000

I just threw names into the diagram and based them on the devices comprising each dataset.

I’m not being pedantic. Understanding the differences between drives, vdevs, pools, datasets, folders, zvols, snapshots, and clones isn’t simply academic. You need to have a grasp on these terms and concepts to minimize mistakes in the future.

“devices comprising each dataset”

This doesn’t make sense. I think you mean “pool”, but then that also doesn’t make sense, since you are replicating datasets.

I won’t dwell on this. I do recommend you take the time to understand the fundamentals of ZFS, even if it won’t play into your current migration task.

---

@user000

Is this referring to the data that is stored in a dataset as indicated by the TrueNAS logo? So, that .system file is stored in my main dataset as indicated by the TrueNAS logo to the left of that share icon?

The “System Dataset” is unique to TrueNAS. A “hidden” dataset named .system is nested under the root dataset of whichever pool you select. (It can also be place in the boot-pool instead.) You cannot see the System Dataset in the GUI. (It will, however, inform you which pool holds the System Dataset. Alternatively, you can view it in the command-line, like with any other dataset.)

With Core, you can have the System Dataset encrypted, simply by having the pool’s root dataset encrypted. This allows you to store your syslogs in an encrypted space, and it also decouples your logs from your boot-pool. (Boot drive dies? New install? You get to keep the syslogs.)

Unfortunately, with SCALE (and now “CE”), they removed the ability to choose where the syslogs are saved.

---

First of all, do you really need a key? Is there a reason you don’t want to use a passphrase? You can lose a key/keyfile. You can’t “lose” a passphrase, unless you forget it.

There’s also one less thing to worry about backing up and keeping safe: a keyfile. With a passphrase, you never have to remember to “backup” or “verify” a keyfile.

@user000

I was saying at each stage i would tick the “inherit encryption” option, but maybe this is unnecessary.

@user000

Do I only need to select “inherit encryption” option for Repliaction-STAGE0?

Once the pseudo-root datasets are the state of encryption you want (desired keyfile/passphrase), and once you have the children inherit their respective pseudo-root dataset’s encryption properties, then each “encryptionroot” is all that matters going forward in regards to unlocking and replicating. (In your case, you’ll have a total of 2 encryptionroots. Each pseudo-root dataset will be an encryptionroot.)

If the “Site B” side of “STAGE 0” is the final state of encryption you want (after the children inherit the encryption properties of their respective parents), then you don’t need to mess with inheritance any more. Just don’t replicate any children. Only replicate the pseudo-roots datasets (aka the “encryptionroot” parents.)

You can even use “raw streams” for your replications, in which no unlocking, keys or, passphrases are necessary in order to replicate. The replication will happen “raw”. You’ll still need the key/passphrase to unlock and access the data within, but you can replicate without the need to unlock anything on either end.

---

EDIT: Please be careful. I recommend using “checkpoints” and to avoid destroying anything, even after a successful replication, until you can confirm it was a success and that you can access your data.

If you have a spare, large USB drive lying around, it doesn’t hurt to create a single-drive pool and do a full replication to it to hold onto everything temporarily, just in case something goes horribly wrong.

[user000]

@winnielinnie

I’m not being pedantic. Understanding the differences between drives, vdevs, pools, datasets, folders, zvols, snapshots, and clones isn’t simply academic. You need to have a grasp on these terms and concepts to minimize mistakes in the future.

I wasn’t implying you’re being pedantic. I agree, I should go back and make sure I have the fundamentals down. I was being quick with my words.

@winnielinnie

The “System Dataset” is unique to TrueNAS.

So, the below option is unique to TrueNAS and totally separate from the .system that is in the root dataset?

I’m sorry, but I’m a bit confused at what you’re talking about below.

@winnielinnie

The “System Dataset” is unique to TrueNAS. A “hidden” dataset named .system is nested under the root dataset of whichever pool you select. (It can also be place in the boot-pool instead.) You cannot see the System Dataset in the GUI.

Do you mean you cannot see the .system dataset in the GUI? I thought if you encrypt with either key/passphrase the dataset that is storing the TrueNAS specific System Dataset then you would need the key to unlock it and it won’t auto unlock?

@winnielinnie

First of all, do you really need a key? Is there a reason you don’t want to use a passphrase? You can lose a key/keyfile. You can’t “lose” a passphrase, unless you forget it.

I take password management pretty seriously. I wouldn’t recommend anyone memorize passphrases other than to unlock a password manager.

I want a key because It allows my dataset to be auto unlocked at boot. As far as I understand this is not possible with passphrases with CE?

@winnielinnie

You can even use “raw streams” for your replications, in which no unlocking, keys or, passphrases are necessary in order to replicate

I’ll test this out…

@winnielinnie

EDIT: Please be careful. I recommend using “checkpoints” and to avoid destroying anything, even after a successful replication, until you can confirm it was a success and that you can access your data.

If you have a spare, large USB drive lying around, it doesn’t hurt to create a single-drive pool and do a full replication to it to hold onto everything temporarily, just in case something goes horribly wrong.

Thank you, I appreciate your help and advice. I was planning on creating some sort of backup before making this attempt.

[winnielinnie]

@user000

So, the below option is unique to TrueNAS and totally separate from the .system that is in the root dataset?

It’s poor UI design.

All it does is confuse people. They see “System Dataset Pool”.

What it should read is:
main (contains hidden .system dataset, "System Dataset")

What do I know? I’m just an end-user.

You have pools. You have datasets. TrueNAS creates and uses a hidden dataset named .system, which it uses to house important system files, separate from the base OS. It can place this dataset (.system) under the boot-pool or any pool of your choice.

It calls this hidden dataset “System Dataset”.

For some reason, whichever pool has this hidden .system dataset, the UI refers to it as the “System Dataset Pool”. I think that’s silly and only confuses people…

---

@user000

Do you mean you cannot see the .system dataset in the GUI?

Correct. There’s nothing special about it.

Using zfs in the command-line will show it and treat it like any typical dataset. The TrueNAS UI does not let you directly interact with it and hides it from being displayed. (Intentionally.)

---

@user000

I thought if you encrypt with either key/passphrase the dataset that is storing the TrueNAS specific System Dataset then you would need the key to unlock it and it won’t auto unlock?

If you encrypt the pool’s top-level root dataset, TrueNAS will not allow this to be passphrase-protected. This is because TrueNAS demands that the System Dataset (.system) is immediately available at boot.

If you use a key, that’s fine, since the key is stored on the unencrypted boot-pool, which allows the root dataset to be automatically unlocked, which also unlocks the .system dataset. (Whatever the root dataset has, the .system dataset inherits. You could override this with the command-line, bypassing the GUI, but it will most likely break your system.)

---

@user000

As far as I understand this is not possible with passphrases with CE?

Correct.