Thanks, I will as soon as I have chosen a new HW platform
I am facing the same issue and considering a NUC as well.
Have you succeeded and did you possibly use openhabian?
Which NUC did you choose?
Thanks in advance
That sounds like a good (not too powerful) solution.
It’s actual hard to find a mini pc with a small (and cheap) ssd like the chromebox.
Unfortunately it has a fan inside and i would prefer a fanless solution.
Did you succeed with your chromebox?
No, I am looking for reliability (referring to the original post).
I don’t care for more power - I am happy with the (CPU) performance of my Raspberry.
I heard of successful installs on a NUC before.
My 2c. As my friends and family tech fixer, I’m always being given old dead or retired laptops.
These make excellent home servers - built in UPS, server GUI if you’re that way inclined, etc.
I just whack a headless Ubuntu (xenial last time from memory) on it, openhab mosquito etc and bam.
Take care and remember that most SBC alternatives (incl. NUCs) use the same memory tech that is the reason for Pi’s well-known SD card problems. But USB sticks aren’t any better. And eMMC isn’t either.
Yes there’s variances, and you can be lucky to get hold of a good product, but that’s pure luck, and the average MTBF will still be far from anything accepted in the professional world.
The bottom line simply is that all these technologies and products perform poorly in terms of reliability in this write-a-lot-scenario we will have. Check out this thread.
Whenever there’s an alternative that’s more reliable it’s just because it’s using a more reliable storage medium such as a HDD or SSD. Now you could choose to also equip your Pi with one of those.
But even such a NUC or pimped Pi still can and will fail at times (less often than SD card based one, but it will).
So either way, you have to go for a backup solution such as the Amanda part of openHABian.
And once you have that one working, you can also stick with your Pi.
Good idea… the (I think only) drawback from a professional perspective (me being a data center designer) is how to handle the need for HW replacement. A Pi is 100% compatible and $35, so just buy two or three. Any next laptop model, though not unlikely, isn’t guaranteed to work with your current HW and OS. But if you prepare it BEFORE the crash, check and keep cross-checking with your evolving ‘production’ laptop’s OH installation at times, why not.
But remember that’s extra work, and people are lazy.
The RPi Compute Module used in the Telegea Smart Hub is designed for industrial use and mounts an eMMC flash storage which replaces the SD card. The flash chip is a Samsung KLM4G1FEPD. Here is some information from its datasheet.
We don’t have specific data for running OpenHAB on this device for an extended time but we’ve been using many of these devices for other projects for more than a year and never had any issue with the flash memory.
Raspbian with OpenHAB is running fine on the Telegea Smart Hub (see details here). We haven’t tried openHABian yet but if this is of interest we can certainly do this.
Developing an openHAB server hardware
You’re absolutely right that ALL systems will fail and I was pretty happy with the raspi in the past.
The recent weeks have been a little annoying.
Assuming that I have a working image of my runtime system and would move it to a brand new SD-card. Does this mean the image would work for all the upcoming failures (exchangeing the cards each time) or is it possible that the image will migrate issues (corruptions) to the new card.
(Maybe a stupid question!?)
My new option would be a NUC (Intel NUC Kit NUC5CPYH) with 4 GB RAM and a 32 to SSD.
I assume that this will be much more stable will cost just about 180€.
I did not check out Amanda in openhabiann, but will do before migrating to the NUC.
If you copy a working image (non-corrupted ! You eventually just didn’t spot that yet, so better install from scratch) image to a spare card and lock that one up in your vault, yes, then you should be able to recover your home if your active card dies of corruption (but don’t run off that copy… that would corrupt it !).
Now you didn’t fully read my posts, did you ?
- there’s risks and drawbacks if you change architecture
- cost (think of spare HW, too)
- you still need backup.
If you have backup, you don’t need to change HW
You could as well attach just that SSD to your Pi. Or attach a simple USB stick instead and move all logging there as described in the thread I referenced.
But the point remains: You need to get your backup right. Amanda can create SD card copies for you, too.
Sorry to give you the impression that I did not red your post (I did
I just wanted to emphasize that a change to a NUC and RAM with SSD would eliminate the corruption caused by the SD-card.
Actually I tried to overcome this by an USB Stick already (moved root to USB using openhabian), but the issue stays the same (I will start from scratch to verify though).
I do backupsevery now and then, but it does not help, if I am not at home, when the systems crashs.
So I just would minimize the risks by considering HW not using SD-cards at all.
May or not be as easy using paper ui, but for backups I tend to just do tar zcf backup.tar.gz /etc/openhab/ and then scp it somewhere with a cron script. If fact just all of /etc/ (for mosquito, zone minder, etc)
If a hdd is borked I just reinstall Linux again.
Best life I’ve ever gotten out of a memory disk was 4yrs uptime off a laptop running of a 4 gb USB stick, though from memory I had /var/log mapped to /dev/shm on boot and no swap
To move root to USB does not make a difference.
I’m referring to this post. No, I don’t think you read it …
SD and USB might have been bad right away, but that would have been a big coincidence.
Most likely your data was already corrupted when you moved it to USB.
Yes, start from scratch. And check the Pi HW before that.
To use different HW minimizes , but does not mitigate the risk the way a backup concept does.
No, I still don’t think you read it
You could create a SD clone and instruct all of your family members how to install it in a Pi just in case.
That’s what I did …
That might be a challenge because my youngest son just turned 3
Maybe you’re right and I will read the other post more thoroughly
Now I have read your post (again
What I don’t get though:
If I make a backup of the sd-card every day and the system crashes due to a corrupt sd-card, how do I know which one is not corrupt?
I did several sd-card images of my system, so before starting from scratch, can I somehow check which image is still not corrupted?
Should I perform a format process or is this done by windiskimager anyway?
Nope and nope. At least I don’t know of any safe method.
Fair questions, but I don’t have any answer other than to do ‘trial and error’.
Keep enough generations to be able to go back far in time if required.
From time to time, switch cards to boot from that SD you’ve just written your image to. Keep those that have proven to work.
In case of need, it is better to run off an older but verified image. To avoid confusion: this applies to RAW (SD card level) device backups. Plus, you should have daily filesystem-level backups so if in need , put in an old image that you know to work, and copy over the files that have changed since (or simply copy all config files).
Amanda can do both for you, raw AND file level backups in one dumpcycle.
- Start from Scratch with brand new SD-card and virgin openhabian 1.3 including moving root to a USB Stick to reduce wear of the SD-card (logs and persistence).
- Try the same (Move logs and persistence) to my NAS (Wouldn’t it be a good feature to do so from within openhabian (look for a mounted share and move them)?
- NUC as the final option
Just an option to consider…
I run a 4 NIC port version of this for pfSense firewall and these for instances of dedicated “PRODUCTION” uses where typically use RPis for test/dev. (ex. share one system for OH2 and Ubiquiti network controller software)
Couple of quick notes:
- Uses x86 so easy to setup with ubuntu, etc.
- mSATA drive module so the SD-CARD issues aren’t really an issue.
- 2+ GB and JavaVM for OH2; very responsive.
- Fanless / no moving parts
- with 2+GB mem, plenty of resources for multi-purpose (like mentioned above)
- the BIOS options are fairly impressive. When getting the 1st one, I was expecting the basics for BIOS options, but was pleasantly surprised with the many features.
looks interesting indeed.
Looks like a quad core Celeron J1900 - should be enough for a dedicated OH server :slight_smile
I will put it onto my list of potential approaches.
After some discussions in this thread and the others about sd-card corruption I consider as a first try to move mySQL and logs to my NAS and see if the sd-card issue improves as expected.
Thanks for the hint to the firewall barbone