After having had recent troubles migrating to 4.10, I’ve been left pondering what part of the server configuration is actually useful to backup.
Restoring the whole userdata folder pretty much always fails and this time all I ended up copying over was the jsondb folder located inside it and nothing else.
Even the addons got selected automatically for re-install(except HABpanel, which I think used to be installed by default since I don’t remember installing it before).
Is my setup simply too basic to need anything else or am I missing stuff and just haven’t realized it yet?
It’s hard to find up-to-date information about the openhab configuration so any help would be appreciated.
use openhab-cli backup to create a backup zip file that contains everything that is necessary.
openhab-cli also has an option to create a fullbackup that one will put more than the minimum required into the backup.
There are two locations that are required to backup parts of the userdata folder and /etc/openhab/.
This answer my be not accurate enough in case you don’t use an linux apt based installation which I don’t know if that is the case.
I use freebsd and it doesn’t have openhab-cli(or I haven’t installed it if it is a separate thing) but I already have a backup solution for my whole system which is backuping the userdata, etc/openhab and the log folder.
But the issue I always run into is that I can’t restore by copying those back because it always breaks openhab every time I tried after an update hence why I’m asking this question.
Is there a detailed description of what is saved where in those folder so that I can know what to try and remove when restoring a backup if I run into issues?
jsondb from the userdata folder even contains my user config and addon list that I would have expected to be in the etc folder so I’m not really sure what’s left outside of that folder.
Sounds like you are used to scripting etc. and you would be able to read a script file.
openhab-cli calls a script called backup. Do you have that one in your system ?
On my system ( not freebsd ) is located at /usr/share/openhab/runtime/bin/backup.
For non-Linux systems there is a backup.sh and restore.sh scripts in the openhab/bin folder. Assuming a manual install of OH I think that’s $OH_HOME/runtime/bin.
There are a number of folders that should be excluded from userdata unless you want a full backup. In particular userdata/tmp ad userdata/cache can cause problems.
If your backup does include those folders, and you are restoring to a version of OH different from the version you are running, you must Clear the Cache.
There are a number of folders in userdata that are optional. If you don’t care about saved persistence data you can exclude persistence. If you don’t care about your configs outside of Things/Items/et al (e.g. regional settings, installed add-ons, etc) you can exclude the config folder. Some add-ons create their own folder in userdata which may or may not be optional to exclude (e.g. I think you’ll have to rediscover your Things for Zwave if you exclude the userdata/zwave folder). userdata/etc has the configs that OH manages but you might have some changes there (e.g. users, logging config, etc).
Not really but if you want to see what to save and not save, I recommend looking at the backup.sh script and see what it excludes when doing a regular backup.
I meant that command doesn’t exist and I never really had enough of a need for the cli to try and find the details of how it might work differently outside of linux, but trying it now, it’s failing to use the correct location for the userdata folder so it’s failing to execute(by either running client(what I should use for my config) or start).
It tries to make a userdata folder in the same place as where the runtime folder is but that’s a completely different path for the userdata stuff.
Edit: Connecting via ssh to the console works well though.
The backup script sets the userdata folder location to “/var/lib/openhab” instead of “/var/db/openhab” at the start by default and testing it give these errors so using it is not really an easy option:
Configuration paths are invalid...
Try setting OPENHAB_USERDATA and OPENHAB_CONF environment variables.
The service script for it adds “_dir” at the end of those variables so I’m assuming that’s the issue, with the package install at least.
I do want a full backup(better be safe than sorry) which is why I copied the whole folder, but knowing what does what inside is what I’m trying to learn so I know what I can afford to exclude when necessary.
Thanks for the details about clearing the cache and what a few of the folders do, that’s exactly what I wanted to know.
Looking at it, it’s only the 2 you told me can cause issues that are excluded in a normal backup, tmp and cache.
It’s usually simply after updating the package and not actually restoring the backup(but that inevitably comes later too while trying to fix things), but knowing to remove the tmp and cache folder in case of issues should hopefully help a lot in the future.
Have you tried defining those environment variables before running the script? If they are not defined, it’s not unreasonable for the defaults to be set to the most common installation type (apt on Linux).
Every time you change the OH version through an upgrade or a downgrade you must clear the cache. The cache is where the add-ons get installed to and add-ons are not usually compatible with a different version of OH than they were compiled for.
Yeah, I know it wouldn’t work right without those being set, I’m just saying the package installation that most people will use sets different variables(adds _dir at the end) so people on freebsd can’t use it without messing around with things they shouldn’t have to mess with(I’m certainly not blaming openhab for this, unless that package is official but I’d be surprised if it was).
Once again, I’d blame the installation package for this since it doesn’t do it automatically and, alternatively, also doesn’t write a warning after the upgrade that this should be done.
I’ve gone through multiple updates without realizing it was mandatory until now and somehow all of my forum and doc searches didn’t make me realize that either.
Some kind of different version cache detection from openhab would be nice but I’m sure there’s much more important things that still need to be done first rather than that.
Frankly, FreeBSD isn’t even an officially supported OS at all. Clearly it can work but unless you’re willing to take up the work to create some docs and maybe a port (that’s what packages are called in FreeBSD IIRC, right?) then you will largely be on your own and very likely to need to mess around with things you shouldn’t have to. FreeBSD simply isn’t in anyones mind when building the packages.
But there is no installation package. That’s kind of the point. You have what amounts to a portable installation. Installation is “unzip this file and run this script to run the software.” It’s not really installed at all.
For MacOS and Windows which both are similar types of “installations” (i,.e. unzipped and run) there are instructions and even an upgrade script. But since FreeBSD isn’t actually a supported OS…
One of the things the upgrade tools for these platforms do (but not the only thing) is clear the cache. Given that macOS is kinda sorta BSD, maybe the macOS upgrade script will work.
I realize it wasn’t clear, when I said package, which is a very common term, I meant a freeBSD package made and maintained by people for FreeBSD and managed by the pkg app specifically. Sometimes the software creator will maintain these themselves but I’d assume more often than not they don’t, I just haven’t looked into it for this one.
There are the ports you have to compile yourself and “packages” installed with the pkg app that are pre-compiled versions and act like an installer, creating and modifying files for them to work, they create the service files, send messages to the user depending on the task they did, stuff like that. It’s not just an unzip type of installation when using those.
The things I said before are usually things that are considered when making those packages, but I’m assuming whoever made it isn’t familiar enough with openhab that they would know about those details or not familiar with what the package system in freebsd can do(or didn’t want to put that much work in or something).
I only tested the backup script to see if it would work out of the box, I prefer to do it myself anyway(in my own backup script) so I’m not really interested in using it. Good to know it exists though.
