This is not just the plan, this is how it is! You can use OH2 exactly the way as OH1, i.e. you can define all details of your setup on the “conf” folder and that one should be all you need to backup, if you want to reconstruct your instance (with a few exceptions like the logging configuration, which is still at a different place).
The Paper UI approach is meant for people who do not want to deal with text files, but prefer UIs.
Technically, it is not really feasible to make the UIs editing the files in “conf”, so that these two ways would be more or less doing the same. I agree that this is confusing and we have to work on solutions that make this easily understandable and usable for people. For all the tech-savvy people, my clear advice for the moment is to stick to the textual configuration - you do not need the Paper UI at all for that.
However, am I correct to say, the way to backup can be
2 If somehow UI(e.g. Habmin2) has been used, both conf/ and userdata/ should be copied for backup?
Is this way of backup is totally impossible?
Or instead of userdata/, some subdir should be copied?
All, I have started looking deeper in the problems that exist with backup/restore/upgrade and you find the current state at https://github.com/openhab/openhab-distro/issues/299 - please feel invited to help on it, be it by clever ideas how to solve problems or by testing PRs that mean to address issues in this area.
After reading through most of the previous answers I want to emphasize this statement. Seems like there is a very common misconception among new openHAB2 users.
PaperUI is not needed to accomplish what you want to do with openHAB2! After having my initial difficulties I completely abandoned PaperUI from my personal workflow and am 100% relying on conf files in my OH2 setup. The PaperUI is just one way of interacting with the openHAB 2 core system. Configure your bindings in addons.cfg, services in the corresponding *.cfg files, your things in the things folder, items in the items folder, rules in the rules folder, … you get it
My personal feeling is, that people first interacting with openHAB2 are drawn to the interesting new PaperUI feature and get misleading expectations. We are trying to solve this problem in the documentation, which is supposed to grow strong in the next two months. Please anyone with clear input on what the documentation should describe, take part in the discussion at Add warnings and/or deemphasize use of PaperUI · Issue #110 · openhab/openhab-docs · GitHub
In another thread I already proposed my idea of an approach to unify the “classic” configuration and the database. Here’s the short version:
I want to vote towards the database approach in combination with what I and others mentioned before:
Thing/item discovery and adoption through PaperUI
Thing/item handling and modification though PaperUI
Increase of UI functionality over time
While there are not all functions available in PaperUI, mainly for the tech-savvy user:
Direct database access through some existing frontend like phpmyadmin (not offered for mapdb? mapdb alternative an option?)
More powerful options on the karaf console (random example: smarthome:items 5 rename 'Bathlight')
So as the next Beta is just around the corner and im always tempted to update to the latest and greatest. If im already on a snapshot with the new json db. and want to create a Backup . Would this process work now? 1. Backup conf/ userdata. 2. Update via apt get ( yes im on raspberry). 3.Install all my bindings. 4. restore conf/ userdata? Or is this something which will be introduced in a future Build and i will at least have to setup everything once again?
This was the state in May 2016. In the meanwhile the jsondb was introduced, which stores the configuration in text files too. Should I derive .items and .things files from it in order to upgrade to a new openhab2 version without loosing my configuration?
That sounds great! Since #299 isn’t closed yet I thought this is still in work. Do you know if the new upgrade mechanism works for apt/deb-based installations as well?
Yes. And the upgrade mechanism didn’t change so much as the location and format of the data files changed. There are still a couple of minor outstanding issues, such as the branding you see when you log into karaf not updating to show the build number but for the most part it is safe to proceed.
Can i still install whole openhab2 into one single folder like the manual install on OH1?
So i can only copy the whole folder to my backup-drive and all will be good. Now with OH2 storing the installation into many folders in different directorys, i have to backup many folders manually.
But it think the apt-get update/upgrade will only work, if i use OH2 with the given installation folders on many different places? If i use OH1 all-in-one folder i will have to update OH2 manually by simply copy the new files to the install-place and overwrite the old files?
That shouldn’t be a problem. That’s how every Linux software works. Backup is as simple as this.
I’d recommend the package repository based installation in general as a few things are managed for you, makes it easier for the end user.
I made a backup (most of my config was done through the paper ui) as per http://docs.openhab.org/installation/linux.html#backup-and-restore and the resulting files were over 90MB compressed. lulz – that’s just embarrassing. I certainly hope there’s a better solution on the way. I strongly believe having the UIs store data in something human-editable would be a big improvement, for configuration purposes. These binary databases can’t be diffed, can’t be meaningfully stashed into version control, can’t be manipulated outside the UI… and it’s the recommended method for new users. Having the system r/w text files, or json files, or xml files, or… really just about anything else seems like it’d be a big improvement. I worry that OH2 is overengineered at every turn, like many enterprise java apps these days. Forcing a one-time upgrade and edit of OH1 text files into OH2 files (probably via some kind of tool, if needed) seems easy enough, but I’m sure this was debated already long before I started trying OH2. Oh well.
But seriously – 100MB of “configuration data” in a backup? It seems like the vast majority is in the ‘cache’ dir. Can that be omitted? What about ‘tmp’? Maybe update the backup script? Or will things go poorly if ‘cache’ isn’t restored properly, for example?
