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.
Before I move over, I would like to check some more (cheaper) options.
(Thanks @mstormi, @rlkoshak for convincing me).
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)?
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
another option is a apu2c4. specs are 4 cores/1GHz, 4GByte RAM, 16GPIO, RS232, USB2.0… power consumption about 6 to 12W (depending on CPU load), that’s very nice.
Downside is, there is no graphical interface, so you have to install Linux via serial console (but this is quite easy) - after that, you can gain access to console via ssh.
The one issue I’ve had just recently with the chromebox is upgrading the
kernel. There appears to be a difference of opinion on where to store the
UEFI boot files between the firmware authors and the ubuntu folks. This
causes issues on kernel upgrades, and I’ve yet to sort out a step-by-step
to correct. I have had success using the ubuntu boot repair software to
fix it after updates, but it would be good to avoid that if possible. Any
boot experts out there?
Another chromebox approach I haven’t tried yet is using the google
seabios. It is supposed to be able to boot a kernel in bios mode. Maybe
that would avoid the uefi issues.
I’d be interested to hear of other experiences with using X86 boards. I
looked at the up-board, jaguar board, latte-panda, uudo x86, and minnow. I
am sure there are others. I picked the chromebox mainly on price, and that
I have one still running chrome os as a streaming media unit. Under chrome
os the box is maintenance free and never crashes. Still working out the
kinks with linux.
The fan is almost silent. You have to load the cpu and put your ear on it
to hear.
Using the legacy SeaBios firmware on chromebox works. I was able to update from lubuntu 16.04 all the way to 17.04 with no issues. Wifi, audio, etc. all seem to work fine in 17.04. I am interested to hear experiences from anyone else using x86 boards for openhab. Still trying to sort out startup issues with Mysensors though. I thought that the combo of x86 and usb arduino would have been the easiest example to work from, but it doesn’t seem as popular.
These days most of the maintainers seem to be recommending Zulu as the preferred JRE. It is the version that ships with the Docker Image and it seems to have a prominent position on the install docs. I have seen mention it performs much better on ARM than Oracle JRE.
hey guys, I want to ask about SDcard vs EMMC questions: does those are the same type?I know emmc gets much faster, but what I want to ask, is does emmc has the same issues like sdcard’s after running a few months? what if I need a really stable environment like running years without any issue, what kind of storage I should choose between sdcard and emmc?
I don’t want to install the system inside a ssd due to the size of a ssd is too large, I want a tiny sbc which can running OH2 like… years…can I trust EMMC?
I think the jury is still out. Some claim EMMC will last longer than SD but they are fundamentally the same technology and EEMC will wear out eventually. You will have to look at the cycle rating for the EEMC you choose and come up with an estimate of how many writes you will be doing to calculate how long you would expect it to last.
There is no small form memory that I know of that doesn’t have the wear out problem.
Your best bet will be to way overprovision the storage (more storage means more bytes to write before the card starts to suffer wear since the writes are wear leveled). At the same time you will need to minimize writes which means moving logs and persistence off of the SD/EEMC card. That will buy you some time.
Practically speaking what you are asking for is impossible. If you really want a system that will last years or nearly indefinitely you need an SDD or HDD. The suggestions above will only buy you more time before the cards wear out.
thanks man, really awesome detail explaination, looks like the ssd/hd drive is the only correct way to go if talking about years running
btw, I am currently running with 10+ items with influxdb and mapdb persist(cpuload1, storage left%, memory used%, humidity, temp, lux for every hour), and I also run docker glances to monitoring the system os health, it currently shows around 7k/s both write and read, does it looks normal in your perspective? (7k/s w/r, emmc) I did some googling but not sure why I always get 7k-14k/s(maybe it’s coming from ubuntu os log?)
and btw, I am using a x86 sbc with N2808+2G+32Gemmc, lubuntu desktop and running almost everything inside docker, so far I think this is the best hardware for OH2(low power=3w, low heat=33c tiny=100mm x 70mm)
I’ve no idea. Everyone’s system will be different and the amount of writes is driven by so many details specific to your setup that what is normal for me can and probably does not bear any resemblance to what is normal for you. I run everything on a desktop server in VMs so I’ve never bothered to measure.
I think the best will depend on each individual’s particular circumstances. For me the best is to run it on a powerful desktop server because I have so many other services I need to run (Claibre, Plex Media Server, Gogs, Alfresco, InfluxDB, Mosquitto, openHAB, a virtual desktop, OpenMediaVault, PFSense, ZoneMinder, etc). It is impossible to run all of that on a SBC, some won’t even run on SBC (e.g. Alfresco) by itself, and it is not cost effective to buy a bunch of SBCs to run it all. So for me that machine would be a poor choice.
As other have said, it is fairly straight forward from a typical system admin point of view. the basic flow would be:
Create a Linux install USB key from Ubuntu
Boot from USB install key and follow basic install (minimal install, no gui, etc.)
Install JRE, following instruction from Oracle JAVA Linux install doc (basically xtract tar to dir, add sym link to /usr/local/bin, etc.)
I do manual install of OH into /home/openhab2 (personal preference)
The hardware is functionally no different than a laptop/desktop, etc… It is just a small form factor PC that is very easy to wall mount with bracket, low power, etc. I have been more than pleasantly surprised with the performance/bios options, power utilization, etc… I use these for my pfSense firewall, Ubiquity/OH host, etc. (not that there aren’t more similar options as mentioned out there)
If you have any more specific questions, let me know!
Just in case anyone is interested: I have picked up a China box called Beelink M1 from Amazon and put a 120GB 2240 M.2 SSD inside the device. I wanted to replace my RPi3 with something slightly more powerful, with more RAM to do fun stuff and with more longevity concerning the storage after my micro-sds failed twice on me each after roughly one year. Unfortunately, the device is kind of picky what Linux it boots. I could only make Archlinux boot on it (tried Debian and Ubuntu in all kinds of flavors). But other than that, it works pretty well. The biggest downside is that it doesn’t auto-boot when it gets power. You always have to push the power-on button which really is a showstopper for server-based usage. I’m considering to replace it a Gemini Lake Intel NUC next year.
So just as a hint to consider when looking for a device: look for the auto-boot on power bios feature.
I’m using a board developed by us based on Raspberry PI CM3. On that I’ve applied all the design experience already done for other industrial grade boards, in particular for the SD card circuitry. We’ve done a lot of tests on switching off the power brutally without any damage of the SD card. This solves, at least, hardware problem on corruptions and still maintains the use of a so easy and spread system as Openhabian is.
Wouldn’t another viable approach be to develop a redundant controller capability within OpenHAB. You run two identical configured OH Pi’s (or whatever) with one taking the ‘master’ role and one ‘dormant’. If and when one of the Pi’s fail the other takes over immediately and alerts the user of the failure. Some form of SD backup is immediately done of the remaining ‘good’ OH SD to replace the failing one and then they are synched again.
This allows for affordable hardware with no downtime at time of failure, just requiring some timely attention in case a double failure should happen (or possibly it could support several redundant controllers).
