Hi Guys,
OH 3 is here and i want to update 
but before i want to create a bootable backup, just in case.
Whats the best way to do so ?
System:
Raspb. 3B with SSD
Latest openhabian / openhab 2.5.9.1
PC: Windows and Mac OS
Thank you!
Remove sd card and create an image with win32 disk imager. (Windows OS)
Writing Your Own Custom SD Card Setup To A File
Run Win32DiskImager.exe
Ensure the Device drop down box has the drive your card is inserted into.
Press the folder button and select the folder and filename you want to use to write your image file to.
Press the Read button.
1 Like
Mirror your SD card using openhabian
You might want to setup openHABian to automatically backup and mirror your internal SD card to an external unit. We suggest to use another SD card in an external card writer device so that in case your internal SD card fails, you can switch SD cards to get the system back up running fast. Note most “16GB” cards are not exactly 16 GB and your new one mustn’t have less bytes than the old one so openHABian enforces the second card to have at least twice the size of your internal card. We make use of that extra space as storage for the backup system.
To setup right at installation time: Define backupdrive=/dev/sdX (replace X with the proper character) to enable this functionality right during unattended installation. Eventually change storagedir=/storage to any other name. The first attached disk type device is usually called /dev/sda. openHABian will create partitions 1 and 2 to be mirrors of your internal card and will assign the remaining space to a storage partition. Full mirroring will take place semiannually and for the 2nd partition (Linux root), changes will be synced once a week. See systemctl list-timers, timers are defined in /etc/systemd/system/sd*.timer. The unattended install routine will also setup Amanda to take daily backups and store them to that third partition. Use storagecapacity=xxx to override how much space to consume at most for Amanda backup storage (in MB). If you choose to skip this during system installation, you can still setup both, mirroring and Amanda, at any later time using the 5X menu options.
Menu 5X provides interactive access to the aforementioned functions: 53 Setup SD monitoring prepares the partitions on an SD card and sets up timers to execute both, a full mirroring and complementary rsync ‘diff’ runs in a backup schedule. 54 Raw copy SD is a one-time raw copy (mirror) run. 55 Sync SD proagates (syncs) differences from your main SD card to your external card.
Should you need to switch over to your backup card, get a another new SD card to match the size of the broken card and use menu option 54 to copy your active backup card back to the new one and switch cards back as soon as possible
sounds good, thanks!
1 Like
While a good idea™, he said he’s on SSD so that won’t work.
1 Like
may be a bit off-topic but if you use an SSD, stay away from USB3.
In my place, the USB3 SSD or the adapter for that matter was causing massive interference with my 2.4G WIFI. That in return caused all my sensors to fail and the whole OH system went straight south.
Workaround: Use USB2 ports or shield your SSD and the cable with aluminum foil. Do connect the foil to the shield of the USB3 port.
1 Like
never had any problems with USB3 and SSD on rpi4
Stay on topic and do not create multiple posts please.
How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community
Hi all,
After a corrupted SD 
i moved to a PI4 + bootable SSD 
and did a complete new installation (OH3). To avoid a second disaster i want to backup it all (I know I should have done this much earlier).
As I’m booting from the SSD and have no SD-card at all in the PI4 I want to make the software backup easy. The idea is to clone the complete SSD-drive (buy a 2e SSD). An repeat this after every. PI upgrade / update and big changes in my OH3 configuration.
Question: is this enough for a good (software) backup?
No. Cloning is not backup.
You won’t have multiple generations, you won’t be able to restore single files.
Drop the SSD, get a SD mirror (openHABian option 53) and setup Amanda (option 52) as a real backup.
After some bad experience with corrupted SD-cards and the fact that I’m now using the system to control my house-heating in looking for a more “robust and reliable ” solution. Looking into the hardware, I have at home now 3 options:
1 - Pi4 with SD
2- Pi-4 with SSD
3 - Synology NAS with Docker
But for all of them the backup and restore of the hardware and software is critical.
For the Hardware:
Option 1 – hardware SD is not made for intensive read/write operations so not really reliable.
Option 2 – good alternative for SD as the SSD is more reliable
Option 3 – best option as a NAS it’s made for continues operation and special hard drive’s for 24x7 operation (I run already an old NAS for 8 years and bought recent a new one)
For the software backup / restore:
Option 1 and 2 – cumbersome process (setup and to maintain)
Option 3 – simple setup for a NAS as it run’s in a Docker and the NAS takes care of the data backup.
So I would prefer option 3 (on my new NAS DS720+) but there I face the issue that the USB is not accessible via Docker (my current Z-wave Stick).
Until I have found a solution for this issue I want to run OpenHab3 via Pi4 + SSD as this is in my opinion the most reliable solution at this time.
I carouse how other people approached the “robustness and reliability” of a home critical system with OpenHab3?
If you want reliability = long MTBF + short MTTR, the #1 recommendation is to use a dedicated system so drop the NAS idea. There’s also a long history of software issues of running on NAS.
Use openHABian on SD. openHABian is making use of professional data centre operations techniques to provide the robustness you’re looking for.
It has features to mitigate SD wearout, provides SD mirroring and the backup toolset.
Easy installation right via menu.
@Fox27 Run it however you like and how it works for you.
Because Markus is who he is I run mine using his recommendations.
My Pi 4 8gig mem Boots from SD Card and is Mirrored to SD card plugged into USB port. It has MSATA SDD attached for storage and Amanda Backup
You will have a better experience using a PI and OpenHABian than with the NAS.
The support you get from Markus and the whole openHAB team I consider expert professional advise. Please read the official documentation and follow it as many extremely talented people have written it and it is worth your time to read and understand what is in it.
1 Like
Maybe it is good for a general understanding to explain as to WHY it is recommended to operate a Pi with SD-Card and not with a more robust SSD.
To me it seems (and I might likely be wrong) it is a leftover from old days when Raspbian OS did not support booting from SSD. But that is history now I think for more than a year now.
I personally boot from SSD and have no problems at all. I do regular backups and when my ssd crashed I just create another fresh image and restore the zip file - should not take more than half an hour, I tend to do no over-managing of my system.
Frankly I don’t know you. I don’t know your capabilities and I did run my PI 3 off ssd for a long time. Which is why I say “Run it however you like”
openHABian is for beginners I assume you are probably a little more advanced than a middle aged mom wanting to tie all of the devices together.
The no one reason to use SD Card is that you need a bigger one to mirror too. Buy good quality cards and you will have less problems. Use Zram and it will greatly decrease the amount of writes on the card. Put your persistence storage on a different storage device like network or SSD
With my system I can talk an beginner through total replacement remotely. Its good if you are in a different country and your wife has some sort of failure.
With Zram you will not have to worry about failures and its much cheaper.
Mine are automated
If I have failure I could talk a 10 y old through replacement of hardware from a different timezone.
1 Like
Well to the point! Thanks James for your reply on behalf of mine.
There’s two areas I’d like to elaborate on.
For the first major reason to understand, you must escape your bubble first:
People tend to only think about their individual situation (e.g. in terms of physical accessibility), the hardware they own, their knowledge, their preferences and sometimes even their ideology.
openHABian is for people that cannot or don’t want to mess with Linux. That’s the majority of users.
Interactively modifying a specific Pi model to boot off some specific non-default device is hard to impossible for beginners but to the Linux experienced it is no challenge.
Then again, Linux guru or not, building a self-configuring system that automagically, NON-interactively and reliably does this for all sorts of servers, firmwares and USB devices is just not feasible.
Once we offer an option even when the assumptions and limits are documented that they should or must not, people will nonetheless start using it, start complaining when it does not work and post hoping for help thus wasting ressources, some even expect to get support. So we as maintainers have to - and we do - put lots of our spare time into validating to ensure it works for everyone, in as many use cases and under as many conditions as possible.
Apply this to the SSD use case to see that’s a very time consuming task we cannot provide for the huge range of software and parameters that are affected when you want to move your root filesystem somewhere else than the default.
The second major reason is a technical one:
What openHABian offers today, i.e. the combo of ZRAM and SD mirroring, provides results superior to what you obtain from moving to an SSD, it’s cheaper and requires less efforts.
Here’s some more stuff that SSD apologists usually don’t think of:
An SSD only gets you a longer MTBF (if at all because it also intros potential for new problems e.g. with space, cooling and power limitations). ZRAM gets you about the same MTBF improvement.
Then again MTTR is the more impacting part of the calculation and any hardware/driver/OS setup modification such as the SSD move will also inevitably worsen your MTTR a lot.
Here’s why: If you don’t have a spare SSD, you must order it the day your system dies → downtime at least some days (and you won’t know if a cold spare works when you need it if you haven’t been using it actively).
When there have been changes in the image or to the OS during operations compared to the one you installed with last time (and there always are many), the reinstalled system is not guaranteed to continue working flawlessly with your old SSD let alone any other model.
Chances are you don’t even get the replacement to work let alone in half an hour unless you keep thoroughly and constantly testing, verifying and updating your setup procedure every time any of the firmware/software components and settings you rely on changes. That’s what outsourcing companies do, they spend A LOT of resources on staying up to date and they wouldn’t be spending money on that if it wasn’t essential to their business.
The openHABian implementation is not “over-managing” but matches this approach.
Your one-shot model is a real no-go in the professional world.
Restoring the zip file might not work for example after the OH version has changed (image will always install the latest, some older OH versions are even not available any more, let alone non-default binding jars). And don’t forget all the remaining tools and modifications of your system beyond pure OH. Several OS packages will have changed meanwhile so will those keep working ?
The backup system implementation in openHABian will not properly work any more. The current documentation is hardly applicable to modified setups which will confuse people right in the worst moment when they are in need (of a restore).
And so on, I could continue that list with stuff I’ve seen fail in reality while your “I can get that back up running in an hour” is just another incarnation of the “hope principle”.
The openHABian implementation is experience and sense of responsibility shrink-wrapped put to use.
1 Like
Hey Markus,
many thanks for the time you took, to go into details and explain this sufficiently. I totally understand your point #1 (providing a system of maximum stability) where it is vital to define standards and build upon that standards. The effort to provide maximum stabilty with too many options/variables will be too high. Now I better understand your attitude related to ssd storage for openhabian.
At this point many thanks for your openhabian system, which I honestly apreciate and without openhabian my entry into the world of openhab would have been a lot more difficult.
Point #2 (technical perspective):
Please do not misunderstand, I do not want to argue against what you said, it is more of an interest to understand the topic better. And I totally understand if you do not want to spent time to response.
-
I thought that Raspberry OS officially supports SSD
-
As from a pure technical point of view I think it is common sense that SSD are more reliable than SD card.
-
I read your points what could happen during restoring a zip file. Do I miss anything with my approach: I think I am kind of “safe” to do a hazzle free restore because I keep my openhabian and openhab constantly up to date and do weekly config backups (menu 50 which creates zip files).
In case of a restore szenario my focus is not on short MTTR. On intention I set up a new system from a recent image you provide on the website’s download section and restore the zip file.
For all other changes outside openhab I have a “cook book”.
From my perspective there shouldn’t be any surprises, should there?
There’s no such thing as an official list of supported peripherals.
By ‘default’ I mean the Pi hardware i.e. the included SD reader, anything else is not default meaning it needs integration and testing.
See I don’t claim non-SSD is the best or only proper way. openHABian is just an bunch of experience I turned into code for everyone to benefit and it’s only an offer you don’t have to take. There’s SSD based and other installations that’ll also work, for sure.
You haven’t encountered a full desaster yet with dysfunctional lighting or heating and your partner pointing at you. I’m sure your focus would have shifted to short MTTR if you had been there before.
I myself run into issues about any time I upgrade a system and every time I do, cook books prove to not be comprehensive. They also get outdated quickly and don’t work any more when in need because Raspi OS, OH and 3rd party tools keep changing constantly.
Keeping them up to date and testing they work is also a lot of work that albeit good-willed, people don’t keep their motivation up for and stop or forget fulfilling within weeks or months at most.
That also applies to your backup when that isn’t fully automated.
On any restore, there WILL be surprises.
Sorry for my harsh judgement but hoping that there will not be any issues is naive.
3 Likes