I do not use Docker but I would have expected all configuration and data to be external to the container. You would then not need to restore the backup.
It is external but that doesn’t mean unchanging. When the Docker container first starts up there is a script that runs to see if the files it has mounted to conf and userdata match the version of openHAB that will run in the container. If they don’t match, the script:
- backs up $OH_USERDATA, putting a copy in $OH_USERDATA/backup
- performs a clear the cache
- only then does it start OH.
The script doesn’t touch $OH_CONF because it makes no changes there.
I know a lot about this as I was the one who first submitted this to the Docker repo.
If you perform an upgrade and something really breaks or you need to roll back for some reason:
- stop openHAB
- restore $OH_USERDATA from the tar file that was created during the upgrade
- restart the openHAB container with the older openHAB version Docker Image.
You will be rolled back at that point.
NOTE: this automated mechanism is not meant to be a replacement for taking backups. You should always backup your userdata and conf folders independently.
openhab-cli is not available when running OH in Docker. It really makes no sense to have it since you cannot directly access the command line of the container. But the equivalents of the backup and restore commands are:
docker exec -it <openhab container ID or name> runtime/bin/backupdocker exec -it <openhab container ID or name> runtime/bin/restore
Note that the file paths are those from inside the container.
For me, I prefer to spread out the upgrade so I practice upgrading early and often. The number of differences and amount of work that you need to do and therefore the risk of something breaking during an upgrade is less from one upgrade to the next when you upgrade more often. I upgrade one of my instances a couple times a week and the other one follows the milestones.
Thus, my overall risk of needing to spend hours and hours because of an upgrade is much lower than if I only used the releases.
But even then, there is a risk that something breaks. So I have the following:
- If the update breaks something I need, I’ll just roll back to the previous version using the steps described above.
- If the update requires a lot of changes like it did when we went from OH 1 to OH 2, I’ll create a copy of my conf and userdata folders, shutdown the production container and start up the upgrade container to work on it. When I’m done for the day, stop the upgrade container and restart production. When everything is working in the upgrade container, I simply delete the old Image, container, and config directories.
- Obviously, take backups all the time.
1 Like
OK, Backing up is easy with docker. Just cp folders to a different location.
Would you guys go with a clean (empty folders) installation and add one binding and config files after the other to check if it is working (a lot of work, i guess) or is it good to go for update after backup?
Only if an in place upgrade failed big time. Then I might roll back and do a clean install. But I should say that in the fiveish years I’ve been running openHAB, I’ve only done that once in the move from OH 1.8 to 2.0. I don’t expect to do it again until the move from 2.5 to 3.0.
1 Like
i started with docker on my qnap an try to move from my vm instance to docker. i created a backup and how do i have to restore exactly ? Where the zip has to be ?
One hint: you may have access to the commandline with tools like portainer etc… so for me it would make sense to have the openhab-cli also available in the docker …
i started with a clean docker, restored my config, after that i get the following:
2020-01-01 15:10:11.319 [INFO ] [port.EventAdminConfigurationNotifier] - Sending Event Admin nofification (configuration successful) to org/ops4j/pax/logging/Configuration
2020-01-01 15:10:12.323 [WARN ] [org.apache.felix.fileinstall ] - /usr/share/openhab2/addons does not exist, please create it.
2020-01-01 15:10:12.328 [ERROR] [org.apache.felix.fileinstall ] - Cannot create folder /var/lib/openhab2/tmp/bundles. Is the folder write-protected?
2020-01-01 15:10:12.354 [WARN ] [raf.features.internal.osgi.Activator] - Error starting activator
java.io.IOException: Unexpected end of input at 1:1
at org.apache.karaf.util.json.JsonReader.error(JsonReader.java:337) ~[bundleFile:?]
at org.apache.karaf.util.json.JsonReader.expected(JsonReader.java:331) ~[bundleFile:?]
at org.apache.karaf.util.json.JsonReader.readValue(JsonReader.java:93) ~[bundleFile:?]
at org.apache.karaf.util.json.JsonReader.parse(JsonReader.java:58) ~[bundleFile:?]
at org.apache.karaf.util.json.JsonReader.read(JsonReader.java:52) ~[bundleFile:?]
at org.apache.karaf.features.internal.region.DigraphHelper.readDigraph(DigraphHelper.java:93) ~[bundleFile:?]
at org.apache.karaf.features.internal.region.DigraphHelper.loadDigraph(DigraphHelper.java:72) ~[bundleFile:?]
at org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:146) ~[bundleFile:?]
at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:312) [bundleFile:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_232]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
2020-01-01 15:10:12.330 [ERROR] [org.apache.felix.configadmin ] - [org.osgi.service.cm.ManagedServiceFactory, id=39, bundle=10/mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.4]: Unexpected problem updating configuration org.apache.felix.fileinstall.7979daf3-5f6e-413a-a48e-07bf17c27c2c
java.lang.RuntimeException: Cannot create folder: /var/lib/openhab2/tmp/bundles
at org.apache.felix.fileinstall.internal.DirectoryWatcher.prepareDir(DirectoryWatcher.java:647) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.prepareTempDir(DirectoryWatcher.java:627) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.(DirectoryWatcher.java:179) ~[?:?]
at org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:248) ~[?:?]
at org.apache.felix.fileinstall.internal.FileInstall$ConfigAdminSupport$Tracker.updated(FileInstall.java:378) ~[?:?]
at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159) ~[bundleFile:?]
at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93) [bundleFile:?]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1253) [bundleFile:?]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1197) [bundleFile:?]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:138) [bundleFile:?]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:105) [bundleFile:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
any hints ?
Put the backup file somewhere inside the container, /openHAB/userdata/backups is a good choice. Then run the restore commands passing it the path to the file.
Everything that openhab-cli does is call other commands and scripts. Everything that openhab-cli does is there inside the container.
Does the openhab user have read write permission on all the folders passed into the container as volumes?
i would like to have your advice how to do the restore correct
i have a new docker, all files are created in (conf/userdata), the mounted volumes have read and write permissons (subdirs are created during install)
openhab:latest is running i can access paperui … as it was lasttime
so, how do i get my configuration from my old instance running ? restore backup files …?
i have shell access inside the docker container
the above errors appeared after restoring my backup…
Just as I already said.
- Copy the backup file to a volume turned to the container
- run the restore command as I listed above, passing in the path to the backup file
- check the permissions on the files
- clear the cache
- restart
clean up the cache directory solved the issues
Coolio, please tick the solution. Thanks
Sorry for the delay, but today I found finally the time to do the upgrade.
My Habpanel looks quite ok after update but log is very full of entries.
Where do I find a tut for cleaning the cache. Maybe this helps in my case too
Hi rlkoshak,
I am trying to us the IOTstack Openhab docker platform.
Able to up the application and all going well but during restore native installation backup in Docker installation facing following error.
I am able to create back up for my Docker installation.
Using to restore
sudo docker exec -it openhab runtime/bin/restore /userdata/backup/OHRunBackup.zip
But zip related error . not sure what i am doing wrong
pi@PI2:~/IOTstack/volumes/openhab/userdata $ cd backup
pi@PI2:~/IOTstack/volumes/openhab/userdata/backup $ ls -a
. .. OHRunBackup01.zip openhab2-backup-20_02_20-14_50_56.zip
pi@PI2:~/IOTstack/volumes/openhab/userdata/backup $ ls -ltau
total 22804
-rwxrw-rw- 1 nobody nogroup 23175892 Feb 21 15:43 OHRunBackup01.zip
-rwxrwxrwx 1 9001 9001 162424 Feb 20 14:50 openhab2-backup-20_02_20-14_50_56.zip
drwxrwxrwx 2 9001 9001 4096 Feb 20 14:50 .
drwxrwxrwx 9 9001 9001 4096 Jan 1 1970 ..
pi@PI2:~/IOTstack/volumes/openhab/userdata/backup $ sudo chmod +x OHRunBackup01.zip
pi@PI2:~/IOTstack/volumes/openhab/userdata/backup $ ls -ltau
total 22804
-rwxrwxrwx 1 nobody nogroup 23175892 Feb 21 15:43 OHRunBackup01.zip
-rwxrwxrwx 1 9001 9001 162424 Feb 20 14:50 openhab2-backup-20_02_20-14_50_56.zip
drwxrwxrwx 2 9001 9001 4096 Feb 20 14:50 .
drwxrwxrwx 9 9001 9001 4096 Jan 1 1970 ..
pi@PI2:~/IOTstack/volumes/openhab/userdata/backup $ ....
pi@PI2:~/IOTstack $ sudo docker exec -it openhab runtime/bin/restore /userdata/backup/OHRunBackup01.zip
##########################################
openHAB 2.x.x restore script
##########################################
Using '/openhab/conf' as conf folder...
Using '/openhab/userdata' as userdata folder...
Making Temporary Directory
Extracting zip file to temporary folder.
unzip: cannot find or open /userdata/backup/OHRunBackup01.zip, /userdata/backup/OHRunBackup01.zip.zip or /userdata/backup/OHRunBackup01.zip.ZIP.
Unable to unzip /userdata/backup/OHRunBackup01.zip, Aborting...
"
Main error
Wrong location.
If you bash into the container like this, you can look around.
docker exec -it openhab bash
You can see that the “userdata” folder is located at
/openhab/userdata/backup/
docker exec -it openhab runtime/bin/restore /openhab/userdata/backup/OHRunBackup.zip
Now a little “rant” 
Why do you sudo docker? Add the docker group to your user.
See:
sudo usermod -a -G docker myUserName
EDIT
Oh an btw, thread hijacking is not nice! 
Please read the following topic:
I have a problem with the restore. I run Docker with Portainer and If I execute this:
sudo docker exec -it xxx runtime/bin/restore /home/pi/openhaby/userdata/backup/myBackup.zip
I am getting these error:
##########################################
openHAB restore script
##########################################openHAB is running! Please stop the process before restoring.
If I stop the container with Portainer and run it again I am getting this error:
Error response from daemon: Container xxx is not running
what I am doing wrong?
You can’t run a restore when openHAB is running.
The only thing the container runs is openHAB.
As long as the container is running you can’t do the restore and if the openHAB is not running the container is not running and exec -it doesn’t have a running container to execute the command in.
You might be able to execute the command in the container using
docker run -it openhab /openhab/runtime/bin/restore
I don’t know if the entrypoint script that kicks off openHAB executes in that case or if just the command you pass in does. You can try it, but you have another problem. /home/pi/openhaby/userdata/backup/myBackup.zip doesn’t exist inside the container. The whole point of a container is to constrain what the software inside it can see and do. It can’t see your /home/pi folder. So even if the command worked it wouldn’t be able to find the backup file to restore.
Honestly, I don’t see the point of trying to use the backup and restore scripts with a Docker container. You already should be mounting volumes to userdata and conf. Just tar up those folders you mount as volumes into the container and you have a backup. To restore the backup untar those folders and change the volume mounts to use the untared folders instead of what ever you are using now.
Over all, I recommend taking a small online course or read up on some Docker and containerized computing basics if you plan on continuing to run openHAB (or anything else) in Docker.
1 Like
hi is it possible to run the Script directly with a rule
My rule is has include the follow code but it don´t work. If i use the command in the sh console it works fine.
executeCommandLine (“sudo docker exec -it 011_0_openhab2 runtime/bin/backup”)
in the Docker Container only the Command “runtime/bin/backup” work but not in my rule with the follow code
executeCommandLine (“runtime/bin/backup”)