Ok, I have tested this on TrueNAS 9.3 (behavior
should be the exact same for FreeNAS 9.3).
If you have a clone environment and you do a rollback, the config file is included in the rollback. Ex:
You have a clone that was made on April 1.
April 5 you add a NIC to your system.
April 7th you install an update and realize the update sucks. So you roll back to the April 1 clone.
The clone *will not* keep the settings from April 5th. This is both a good and bad thing.
This is a good thing because if you've either used really stupid settings that break the OS from booting properly, the config gets corrupted for any reason (including a failed "upgrade" to the database), or any scenario occurs that makes the config "not a good thing" for the OS, then rolling back the boot environment does save you from a bad config.
This is a bad thing because you are rolling back your config, so changes you make to your config are potentially lost across clones.
So clones are great as they potentially save you from OS corruption as well as a fubared config file. But they
won't save you from config problems. So having good configuration backups are just as important as before. For those that don't have an automated backup routine for the config file, might I recommend you read this link:
https://forums.freenas.org/index.php?threads/backup-config-file-every-night-automatically.8237/
So what's the
best way to tackle this potential issue? Make a clone just before you do an upgrade. I've also submitted a ticket for this:
https://bugs.freenas.org/issues/9090
It might be a good idea for someone to test this on FreeNAS 9.3 with the latest build just to be sure the behavior isn't actually different. I'm a but confused because I was pretty sure that when I worked with FreeNAS 9.3 rollbacks it did not work this way. /shrug