Returning to 11.3 - how to recreate pools without losing config

[seb101]

Hi,

After a disasterous trial of TrueNAS Core (not production ready FYI), I need to return to FreeNAS 11.3, however I upgraded the ZFS feature flags on my pools so I am not able to simply return to 11.3. Instead I need to recreate all my pools and copy the data over. Question is, can I do this without losing all permissions, shares, config etc etc related to the pools?

The crux is, is it *only* the pool name that FreeNAS uses to attach permissions/shares/configs or are there some hidden GUIDs etc? I guess this is the same situation as if needing to restore a complete pool from any external backup due to data corruption.

What I want to do is bascially this:

1. Create a fresh FreeNAS 11.3 installation.
2. Create a new Pool named exactly the same as my original (now upgraded) Pool.
3. Copy files from the the upgraded Pool to the new Pool (with all permissions etc intact) - this will be done nas-to-nas via an NFS mount.
4. Restore my 11.3 backup.

After restoring the 11.3 backup, will FreeNAS treat my recovered pool as if it was the original pool simply because it is named the same thing?

If not - is there any way to do this without losing all the extraneous config and having to recreate all my shares?

Thanks!

 

[Nick2253]

You should be able to use zfs send/receive to copy the data over, instead of (I'm presuming) rsync over an NFS mount. That will also preserve all the datasets properly.

As far as I can tell with sharing, all that matters is the path, which is based on the pool and dataset names.

I'm curious, what were your issues with TrueNAS Core 12? If there are issues that need fixed, I know the dev-team would definitely appreciate the bug reports.

 

[seb101]

Thanks for the advice.

Problem with TreuNAS 12 was stability, my NAS which was rock solid under FN11 for years has crashed (kernel panic and reboot) over 30 times in the few weeks since moving to TN12. Suspect a driver kernel module, but with TN being a closed system, very hard to play about with this.

 

[Nick2253]

crashed (kernel panic and reboot) over 30 times in the few weeks since moving to TN12

That's obviously a pretty big deal. Your hardware is pretty common around these parts, so it would surprise me that it was a driver kernel module, though, obviously, gross errors like that sometimes slip through on the .0 releases.

If you still have an image of your boot drive, I'm sure the dev team could help you pull logs off of that to troubleshoot. I'm no expert at hardware/driver troubleshooting in *nix land, so I'm probably at the limit of my knowledge here.

but with TN being a closed system, very hard to play about with this.

TrueNAS Core is just a rebranding of FreeNAS. It's still open source software, and it's internals are no more open or closed than FreeNAS was. Unless you mean closed in a different sense.

 

[seb101]

Closed was probably the wrong word, I just mean that with the complex swap disk configurations and the middleware taking control of large parts of the system it's very hard to apply standard debugging techniques to it. I can't even get it to output a full vmcore core-dump from the crashes which is needed by the FreeBSD devs for the next level of debugging. On a vanilla FreeBSD system this is a single line in rc.conf, but in Free/TrueNAS the middleware takes control of this and due to the pooled and encrypted swap disks, makes it very difficult. I haven't figured it out yet and the advice from the FreeNAS devs has not worked.

 

[Nick2253]

Ahh, gotcha. Yeah, I know what you mean about the middleware inaccessiblity, though I'm surprised that the devs couldn't give you an easy 1-2-3 on getting those logs out.