If you're running it in docker, just backup the config and cache dirs and try the new version. If there's a problem, roll back. If that breaks (probably not, but maybe), restore the backup, then roll back.
If you're not running it in docker, that'd probably still work, if you track down those two directories. Just a bit less clean, and a little chance there's some important stuff configured to be saved other places in the non-dockerized version, so it's a little riskier.
Appreciated! I am indeed running it in docker, but it's one of those home servers that doesn't get touched very often, and every time it does get touched seems to end up needing half a day to untangle everything.
> every time it does get touched seems to end up needing half a day to untangle everything.
This is exactly why I run everything in docker :-) One shell file or docker-compose file per service, and each concisely documents exactly what's running and where all the important stuff is.
Now, if I have to touch zfs for any reason at all... that's half a day of sweating bullets, worried that one of those arcane commands will wipe out the whole volume. The UI is like Git, but what's at stake is all your stuff instead of one easy-to-restore code repo. "Oh you want to do what must be one of the five most common things someone might want to do to a zfs pool? Sure just run these six arcane commands in order. Don't mess any of it up or all your stuff is gone."
If you're not running it in docker, that'd probably still work, if you track down those two directories. Just a bit less clean, and a little chance there's some important stuff configured to be saved other places in the non-dockerized version, so it's a little riskier.