FreeNAS/TrueNAS migrate whole server including users/shares/pools and datasets

Dear Gurus,

this question came up in the context of a potential migration that I might have to do, as consequence of the upgrade to TrueNAS 12.0. I’m using GELI encryption on my FreeNAS 11.3-U5 filer and I understand that this encryption technology is deprecated under TrueNAS 12.0 since the move to ZFS 2.0.

The only “safe” way to upgrade is apparently to delete the encrypted POOL and recreate it without encryption and then after version upgrade to TrueNAS 12.0 with ZFS 2.0 use the Dataset Encryption going forward (if desired).

Now, how can I copy my data back-and-forth to survive the destruction of the pool?
Fortunately I have a secondary filer, which alreday holds replicated snapshots from the primary filer. (Total data size ~ 10 TB) .

My plan is as follows:

1.) Perform additional backup of everything, including data and keys to diffrent media, i.e. USB drives, cloud etc
2.) Test backup
3.) Save configration of primary filer
4.) While all servers still run FreeNAS 11.3-U5 destroy and recreate the pool on the primary filer - this time without encryption
5.) Then replicate back my snapshots from the secondary filer (where they already reside)
6.) Make latest snapshot “read-write” - if necessary (see question below)
7.) Restore saved configuration

Key questions:

  • Have I missed something?
  • Will the save/restore operation on configuration data preserve the existing users/groups/shares and permissions?
  • What is the “correct way” to make the re-replicated snapshot “read-writable” again on the primary filer? I understand they are mounted in read-only mode to prevent them from being changed accidentally. So in essence: how to I make those the “Master Copy” again after restoration? I assume the command would be "zfs set readonly=off POOLNAME - is that all?

Does anybody have experience with such an approach?

Best regards,
Guido

The TrueNAS backups do have the users and shares but do not have the permissions. Once you restore the data back (using ZFS replication is fine for that) you will have to configure the permissions and shares again depending on if they line up to the same directory structure (probably rebuilding them would be the easiest).

An alternative option is to do an in place upgrade as the GLEI keys are still supported in TrueNAS 12. The old encryption can still be mounted and used, just not created in TrueNAS 12.

Hello Tom,

many thanks for your swift reply — and of course also for those great videos on the topic!!!
May I just try to clarify and make sure I fully understand your response:

IF I would rebuild the system with 100% the same directory structure, would anything be lost or need to be reconfigured? What this comes down to: Is there any way to reliably backup and recover a broken filer (using ZFS replication) without huge manual reconfiguration of shares and permissions? What will happen to the ACLs on the CIFS shares by the way?

Thank you for confirming that GELI is still supported on TrueNAS 12.
I tried that with my test machine and it worked! I did have to remove the passphrase before doing the upgrade (well I had to switch back the boot environment to 11.3, remove the passphrase and switch back to 12 to perform that), but afterwards the pool came up ok.

What I will do next is try out what you described above: I’ll wipe the pool on the test system, setup a fresh unencrypted pool and “copy over” the configuration of the primary machine. I assume this should give me in the optimal case an exact copy of the primary. I’ll report any findings if that is ok…

Best regards,
Guido

If the directory structure is the same the shares should work, but the system was not really designed to be “Cloned” to another system so that it could be restores to the exact way another one was setup.

Hello Tom,

again thank you for the response. I get your point of “the system was not really designed to be “Cloned” to another system”. What I’m trying to do is in fact a “Cloning” of the system - onto itself as would be the case here.

But if that is the case - what do you advise your customers when it comes to “disaster recovery”?

Maybe I’m still missing the point, but that effectively means there is no really supported way to take a complete backup of a filer which would allow a 1:1 recovery?

I can live with that, since I’m not running a business. This is just private data from our family, so we have a handfull of users and some ~20 shares. I created some decent documentation and could rebuild the machine from scratch and then “re-upload” the data from either USB drives or from read only clones of datasets on the secondary filer. But still this would be taking considerable time and be prone to error when it comes to bits potentially missing in the documentation. (Note to myself: “Update documentation asap!”)

Best regards,
Guido