I looked at the doc’s in the past and for a new user it’s a bit much especially when there are warnings like Don’t use unless you understand what these commands do ! That was when I was very new and I found openhab-cli way to simple so I dropped the idea of using Amanda. Maybe I will give it a go with one of my test systems, but I think you get (not saying you agree) my point.
For a complex topic like this one is, no docs whatsoever will ever be able to safely cover expectations of the full range of users including Windows newbies.
Simple and effortless, flexible and comprehensive but safe and idiot proof ?
Forget it, pick any two.
For me even more important than the down time is the work required to get things up and running again. Everytime you extent the configuration you add more time into it. Recreating everything is just a lot of work which I prefer to spend in creating a smarter home (or just chilling) instead of doing everything again.
I’m not interested in finding the right command to do something, i don’t now anythig about**(see below). In this tread i’m looking forward to something like a simple backup strategy.
Maybe some other good questions are: what was the openhab commandline backup made for? Which system-files (oops: already not openhab universe anymore) are changed even by unexperienced users at times (see typical serial port issues)? I’d expect these could be identified / are well known to experienced users.
Don’t get me wrong: at the first place i want to know, what to do. Than we can move ahead and discuss how to do it. I do not see any reason to end up with “just an other Amanda (or Kevin)” here. As you say: copying files to a save place will do 85% of the job.
I wonder why so few people seem to be interessted in this topic. Maybe this is because of the not so enjoyable start of this thread. Or i’m overlooking the obvious.
** I have some knowledge in linux as i have been admin of a bag full (linux, solaris, windows, ascend, …) servers for a non profit organisation some ten years ago. Today I always have to dig deep in my brain to correctly remember. But that’s an other issue i don’t want to elaborate on here.
I thought kind of the same way at the beginning. “backing up your smarthome”
But now i tend to give this some more thoughts.
- what do i need
- what may others need also from this
- how they can benefit from my thoughts
I believe, this was the idea of oh cli backup anyway. Oops: i still have to look at the docs for this if these exist.
I have to admit that although i’m propagating “do not tell me anything about the solution now, tell me the requirements first”, i’m also thinking solution-driven.
An idea i like is:
- let the user get the result of cli backup via webinterface
- let the user add a list of files (typical list to pic from, free text also) which are also to be copied
- let the user configure, where to store these filecopies (download, directory/share, cloud [i.e myopenhab preferably if is not a starage issue])
- when selected an “alway on” destination, let the user initiate a cron job
As an addition there should be some documentation (most of which might be available). Which also clarifies this tool is not the all-singing-all-dacing-swiss-knife-solution which restores the light bulb when it becomes defective. Which gives the reader a hint that it’s a good idea to create an image of the SD card at times. And why. Possibly with the commandline for Amanda to do this or a pointer to etcher or whatver.
So: don’t try to hide the complexity. Just put exiting knowledge together and try to make the result easily excessable.
I just started to read part of this thread here from 2018 (even started long before). Wohoho! Everyting already discussed with some connoisseurs of matter. I’ll go back there and try to understand a bit more.
As for additional files, I will try and descripe this as clear as possible. And I will be recommending tools to be used, such as WinScp (for Windows OS), and if I knew simular for Mac, I will note this as well.
I want this to be as clear and as simple for a new user, without adding to much warnings.
There will be some additional suggestions and examples for backup of InfluxDB and Grafana. Its not because I feel they belong in the doc, but since both InfluxDB and Grafana are often used and included directly from openhabian-config. There is a need to mention those, somehow. But this part it twisting my head these days, mainly because influxDB just doesnt use one simple way of doing backups. And I want this doc to be as clear and simple as possible.
There is a issue I need to clear with someone, (maintainer).
I study all the files in the backup archive from openhab-cli yesterday. And there are a few of them in the userdata directory which contains raw static IP number of the system.
That may become an issue here which somehow needs to be taken care of. Cause unless the user restore the backup to a new system with the same IP, there will be issues with the restored backup, I think. Thats a abit of a bummer. I was very surprised when I saw this.
The files which contains IP number are:
** \userdata\config\org\openhab\influxdb.config **
** \userdata\config\org\eclipse\smarthome\network.config **
The influxdb.config is probably a copy from the influxdb setup in \conf\services\influxdb.cfg. This means its important to tell the user to edit the influxdb.cfg, and I believe (hope) the userdata file will be written over with when the user change the settings.
As for the other file network.cfg I cant seem to figure where it comes from. It´s probably written when setting the network adress in PaperUI/System menu. And this may become a problem, as I cant figure out, if it will have any influence on the user accessing the system after retoring the backup.
Perhaps @Benjy have a comment on this? Situation - The user is restoring his backup to a new system, which do not have the same IP as the system where the backup was created. Will this become a problem?
I just read the doc… Unfortunatly it didnt change my mind.
One note regarding restoring:
To restore a file, you need to use the
amrecover command as the
How on earth do the user login as
root on an openhabian install? Thats not really expected, as far as I recall.
Of course it is. The same applies to
openhabian-config and it’s explained in various places
I suggest you better get yourself up to date on openHABian before you continue suggesting/commenting/…
Thats the same in my opinion. For every work you have to do, in most cases it will add to the down time.
Thats why it´s imporant to limit whatever work you have to do, to backup and restore your system. Thats the goal of my idea, and why I focus on using the backup scripts build into openhab.
I have done quite a few changes to my system, specially regarding the use of manuall installed bindings. I have to keep notes of everything, and do manual copying of files, simply because there isnt a decent (simple) backup procedure for this. And I hate it. Thats not how backup procedures should be.
My hope is that the doc will cover most of these things. I dont consider myself beeing unique (I know some may not agree on this :-D) Where I feel a need or a lacking, I´m pretty sure there are alot of others as well. This is why this has become a serious matter to me. I hate seeing people struggle with something I believe could have been alot easier to handle.
This is a smarthome system people are using 24/7 and their house often depend on it. An effective and decent backup procedure should have been a top priority long time ago, without the user have to study Linux to a higher level first. But thats just my opinion.
I agree totally with you on this one.
Noone should “struggle” finding the right commands for a backup strategy. Just as well as noone should have to study a OS language to a higher level, to be able to make a backup/restore.
Its plain and simple stupid. The result often become, just a few people will be using it. And thats bad!
Anyone should be able to backup and restore their system, with a little hassle as possible!
Exactly - The experience users already know… They dont struggle. They may even be using external services (Amanda) for their strategy. Unfortunatly they also have forgotten how much they have struggled themselves. Some of them might even say, “If I can do it, so can he. And then let him struggle”: This I simply cant accept. Its wrong to look at it this way. It doesnt do any good for anyone, and specially not for openhab and future new users.
Insted I turn this upside down - What has been and still is hard for me to comprehend, there will most certain be quite of lot of others users out there with the same or worse struggling. This I will not just turn my back onto. I will help those as far as I can, any time. And I will fight (and provide my help) to get things more simple and clear.
I believe this is how to deal with it. If I dont use my experience to try change what I have been struggling with, there will never be any changes.
Unfortunatly I think you´re right And I´m sorry for beeing part of that. I really tried to behave and keep my continuing arguing with Marcus away… If was never my plan to discuss Amanda like that. I dont mind Amanda beeing mentioned. Its still an option. But it can not be part of the doc I plan, except as mentioning. Amanda is an external service, which means a few words and a link to its doc should be enough.
$OPENHAB_RUNTIME/bin/backup as a backup strategy is whats needs to be documented.
I know what you mean.
There are users out there who do not know using
sudo is equal to command as the root user.
That specific sentens did not help those.
Just forget it - I know the outcome of this one… I was actually trying to give you a hint. Unfortunatly you didnt get it… For that I´m sorry!
I will not comment on Amanda anymore.
Maybe i missunderstand again but a backup-solution or a backup-script can’t be a backup strategy.
To define a strategy for openhab running on a rpi f.e. (although not being specialist on that) i’d seek answers to questions like (sorry for repetitions an writing down the obvious again here an there):
- why do i need a backup -> I am happy with my smarthome implementation in with openhab. It has been a lot of work to this and i’ve been struggeling a lot. I want to keep the results to be able to recover from defects.
- what work did you do, which is worth to conserve -> After i understood how to setup, i defined a lot of things (or had them discovered). I defined items etc. I’d expect everything of this is stored by openhab, otherweise openhab couldn’t do, what i want it to.
- where does openhab store this data, rules etc -> i learned from the docs that most of it is stored in files. Even if a store somethings in a simple database (rrd4j, mapdb) , these are sored in files.
- what are the name of the files and where to find -> i don’t know. But i learned there is a script, which gathers all the files and put them in a zip file.
- do you understand, what’s in the zip file -> no. if i need to know, i could investigate a bit, but would prefer to ask someome who knows.
- which cases do you need these data for: file deleted, file corrupted, did some changes which made the system spit. i’d also need the data after a system crash, possibly from defect SD card, etc.
- what storage is available on your rpi -> SD card
- do you have other storage available, which is (nearly) always on -> yes, sysnology and cloud
- how often will you change these data -> logs i want to preserve are written constantly. Persistence data are written constanly too. What i work on maybe ion a daily bases, but somtimes i don’t even change anything for a month or more.
- is this all you need -> no. i remember i did somes changes not based on “input for openhab” in files like /etc/udev/rules.d, /etc/default/openhab2, /etc/fstab. I also used several steps in openhabianconfig, i don’t remember exactly.
- what do you expect to be done with the data preserved -> restore easily, if one of the risks described has materialized. get back system running fast. get back my changes fast (not the faulty ones, though)
Let’s have a break here. With the last line we entered - as i sad before - a new univers. I’m quite shure, i forgot a bunch of questions in the first section. From that, i’d think about to formlate a draft for - let’s say - an order and begin to talk to a developer about this. In my case thisone would be the same i asked about the zip file content. I’d be able then, to discuss my needs which i know about best. He will know how to implement (or if not possible with a sensible effort).
Methinks it is absolutely the wrong way to talk about software like the backsript or Amanda or what ever (even though it might be helpfull to get a starting point). People using this software on a daily basis, even implement these or just have fun while investigating how to get it up an running will know better than you. Let’s say: it’s their job.
Your job is to express what you need. Nobody knows better. If users concentrate on this, the discussions with maintainers, developers, heavy users etc. are a lot more enjoyable for everyone involved. Thats my experience.
Looking at what there is again i feel: most of the needs may be implemented already. Some not. Some wants could also be satisfied. The the solution will enhanced by the dev (hopefully) and you will enhance the docs.
I’m running out of my time budget. So i’ll be not able to read/write much here next days. Hopefully some others will step in.
Wrong. Well, it’s wrong as long as those others do not read as carelessly as you obviously did.
It’s even explained in the same document, right above this paragraph.
Now - just for
you those others, not for you of course as you don’t need it - I’ve even added another explanation in that incriminated location.
Happy to answer some of them, as you mentioned there is a place in the Docs where the following is explained but if it helps to answer them here so that someone could use it to restructure the docs then.
Note: The following information is about the backup and restore scripts included with
openHAB and are equally valid for any operating system or install method.
How is data in openHAB configured
openHAB 2.x has two ways you can configure an item. I’ll talk about them as textual (e.g item files and rule files etc) or through the UI (e.g. Adding a thing in Paper UI). There are some things that you can’t do by sticking to one way alone, so usually we expect data to be in two different places.
Where is this data stored?
Either method is stored in a text file, textual configurations are stored in
$OPENHAB_CONF and UI configurations are stored in
$OPENHAB_USERDATA. The format of these files are completely different, for the most part, UI configurations are stored in a JSON format.
What does the backup script do?
The backup script is located in
$OPENHAB_RUNTIME/bin/ and can be called without any arguments.
The backup script takes the files from both configuration methods and places it into a specially formatted zip file. With its default settings, this should include:
- Databases that openHAB owns and controls (such as
- Any file or folder in
- A list of bindings that are be installed, and how they’re configured.
- Any thing, rule, item, link etc. that was created from the UI.
What doesn’t the backup script do?
Anything that is not fully managed by openHAB itself wont be backed up, this includes but is not limited to:
- Settings for other software installed on the same machine as openHAB (or the software themselves)
- Databases that openHAB controls, but aren’t part of openHAB directly (e.g. mySQL)
- Anything managed by openHABian, but is not part of openHAB (openHABian has additional backup strategies for this which also help backup some things the openHAB scripts do not.)
This means that if you restore on a different machine, you will need to change any IP settings, Serial Port settings etc. yourself to align it to your new system.
What does the restore script do?
It puts the files in the zip folder back to where they should be, regardless of operating system.
What does the
--full option do differently?
$OPENHAB_RUNTIME/bin/backup --full includes the
cache folders in
$OPENHAB_USERDATA, this can include binary data of specific versions of openHAB bindings and is generated when you launch openHAB. For that reason, its size can be very large and it normally isn’t recommended unless you want to guarantee that nothing else has changed.
You should expect that backups using the
--full option will not restore well on a different version of openHAB, or on a different machine.
Note: The following infomation is a little more specific to those who have installed using
apt (including openHABian) or
Why are the folder locations for openHAB in Linux different to the standalone zip file?
To follow the Linux Filesystem Hierarchy Standard (FHS). Any package that is installed through a package should adhere to them, it ensures that there’s no surprises for users that are used to navigating Linux systems. In our documentation, these paths are referred to by their variable names:
||Binaries are usually found in
|Additional add-on files||
||Configuration files for each Linux Package that a user is expected to directly edit are usually found in
|Userdata like rrd4j databases||
||Data that a process changes, but not typically a user should go in
You can use the variable name in a Linux terminal to direct to a particular folder, e.g. if you weren’t sure where the configuration files were but you wanted to go to them, you can use the command
cd $OPENHAB_CONF to go to
What does openhab-cli backup do differently to the openHAB scripts.
openhab-cli is simply shortcut to scripts included with openHAB for your benefit.
Thanks for the pointer to the docs.
Beyond all the infos I like the idea of Amazon Web Services or even just the storage space being a tape library.
Where do i find the config to backup to Amazon Web Services?
I believe this is a question of words.
Whatever you use to do backups, its part of the strategy. An example could be:
You´re at your local desktop manually copyíng/moving family photos to another storage to keep it save. Thats a backup strategy.
The solution is the actual tool you have chosen. In the above example, you maybe use File Explorer in Windows. Thats the actual tool and therefore the solution you have chosen to use for this particular strategy.
At least, thats how I see it.
My plan with the document is to have focus on the tool $OPENHAB_RUNTIME/bin/backup which infact is a script. But thats just one strategy of many. The strategy itself dont really care if you´re using a script, an application, a service or whatever. The strategy only care of how to archive your goal.
You need to know what the tool can do, (and specially what it CANT do). Then you have an option to choose wether it suits your needs or not (ie, if the tool can archive your goal).
Thats why it´s highly important to explain very clear, what a tool can not do for you.
To sum this in short:
The strategy is:
The choice of tools you decide to use, and how you decide to use it, to archive your goal (ie , save your work).
Since $OPENHAB_RUNTIME/bin/backup just isnt explained in details like that, an I believe lots of people dont really know if its worth anything. Thats what I´m trying to deal with here. From an end-user side of view. An end-user which infact dont understand much. He probably just managed to get openhab hasslefree up running, but he would like to save his work anyway, avoiding to start all over if the system crashes.
The document will provide answers to many of your questions, like:
Short introduction - Why a backup strategy is a very good idea.
What tools are available.
Short intro about Amanda and $OPENHAB_RUNTIME/bin/backup, and what they can provide and their requirements (in short).
From there this will go into details with $OPENHAB_RUNTIME/bin/backup in focus only.
In details: What will $OPENHAB_RUNTIME/bin/backup do for you
In details: What $OPENHAB_RUNTIME/bin/backup will NOT do for you.
In details and examples: Whats required to use $OPENHAB_RUNTIME/bin/backup
In details and examples: How to use $OPENHAB_RUNTIME/bin/backup & restoring
In details: Tips on how to minimize extra work done after restoring a backup.
Any other questions and suggestions and answers which might come in hand to an end-user knowing almost nothing…
That will probably be the end of $OPENHAB_RUNTIME/bin/backup documentation.
But I would personally like to take it even futher with a focus on whats usually happens in an end-users system, like providing suggestions, ideas and examples of how to backup influxDB and Grafana. The reason is that these two services are very common in use by alot of people. And those who use these probably wish they knew how to deal with it, if/when they have a need to backup their system, (ie using $OPENHAB_RUNTIME/bin/backup).
There may be other services as we go through this. But influxDB and Grafana seems to be most common.
Maybe how to backup Zwave… But that requires a very special procedure, which in my opinion is very hard.
Zigbee, as far as I understand, is software only, and will be part of the $OPENHAB_RUNTIME/bin/backup (I´m not sure though, I can tell from the files, that it will copy the xml files from the Zigbee devices. But I dont know if thats enough to “backup” Zigbee setup. I honestly dont think you can backup your Zigbee setup the same way, as it probably require each devices to be re-included manually).
That gives me some more insight because my brain didn’t put much of this in the context of backup/restore up to now, while reading it in the docs. I’ll get back to this after inspecting some zip files from backup.
It’s been there for years.
The answer is in the document
For me this is doing the second step before the fist one.
I want to implement a smart home. I go out and buy a VerySmartBoxForYourHome. After that I read the docs. Lights may be switched. But no chance to integrate temperatur sensors. I’m a bit disappointed, but i had no plan to implement one in the first step. So i will live with what i’ve got.
If i would have thought about a bit more, what i will need or want do implement to get my home smart before, i wouldn’t have run in such a situation.
The steps you plan to take for some docs - give it a try. Maybe starting with somethings named “User experience on backingup/restore”. This way, you don’t have to worry about the restraints on the “offical documentation”. In a next step, this could be integrated in the docs. But that is only a thought.
To concentrate on most used scenes is fine. For each one you may have to find someone with enough knowledge about these if it’s not baed on your experience.
zigbee seems to behave somehow like i’d expect z-wave to do. I resetted my controler to factory settings some days ago and had to reinclude the zigbee THINGS.
Got me ^^
Others: watch out for AWS