What’s the symptoms of sd card corruption, I’ve been running fine on the same over sized card for around 2 years so far without any issues I know of
On that one … now since a Pi only has 1GB of RAM, half of which is usually in use for OH, do you and how do you actually ensure too much logging etc. will not result in RAM shortage and swapping to follow ?
Logrotate and minimising excessive logging mainly. I don’t for example run access logs unless I’m troubleshooting. The events.log will be turned off when I work out how to do it.
I don’t understand. A filesystem is either intact or it is not. You should ensure it is (fsck, journal verification) before you clone.
But then you restore to a different HW with a completely different (much lower) level of ‘worn-out-ness’, i.e. in comparison it’s a setback in terms of corruption level, thus increase in remaining TTL.
My question was aiming at if there’s something like a recommendation for the ‘size’ tmpfs parameter to restrict RAM usage…
I’d have to look tomorrow - it’s night time here.
I basically use a version of the Open Energy Monitor configuration with the bits I don’t need taken out. The build card is on GitHub, look for the EMONPI image build guide. It runs mainly read only with an extra partition for data with access times turned off. Also many things are sent to tmpfs. I run their 4GB image expanded to 8GB on a 32GB Sandisk Extreme card with the remaining space free. It’s worked very well so far with zero corruption despite several unplanned power outages
From what I’ve seen and seen reported here:
- system freezes and remains unresponsive, particularly after a reboot
- system randomly crashes and reboots
- writes don’t actually get saved on disk permanently (e.g. you change a file and the next day your changes are gone)
- random services restarts
I currently have a failing SD card in one of my Pis (I don’t run OH on a Pi but some things are controlled by remote Pis and the one that is failing is the only one I haven’t configured to be read only yet) and I see that it is failing through Tripwire. I get a report showing a bunch of changes. I update the Tripwire DB to accept those changes. Run it again and the changes are still showing up. So either something is constantly changing my config or my writes are not being saved. I’ve also seen a few manual config file edits disappearing after awhile.
I just haven’t gotten around to rebuilding it, it has been a very busy month.
Personally, just to point to an alternative approach to backup/restore, I use git to store my configs and Ansible playbooks to build up the machine. When I need to restore one of my Pis I just need to put the stock Raspbian image on it with the wifi config file added so it joins the network and then run my ansible playbooks. It probably takes a little longer than a restore of an SD card image but I get the added benefit of having my Pi’s config fully documented and configuration controlled and I don’t have to do any maintenance to make sure I have recent backups.
But, unlike most, I have no permanent state on these Pis and therefore lose nothing in a crash. I even offload the logs using rsyslog. And I only have to recover the config to be back up and running. And of course I backup my git server where my configs and ansible scripts are stored.
This wouldn’t work for everyone and probably wouldn’t be a great choice for openHAB, but I post it to get some users thinking about potential other approaches.
Maybe a development for a general applicable backup script for openhabian would find some interest with @ThomDietrich. I can help also!
Thanks for that, as my cards age I’ll keep an eye out. Judging by the comments of others on this thread my “avoid any disk writes where possible” and use a fast SD Card with most of it unallocated approach has paid off.
Moving forward I’ll keep doing image backups after major system changes, and before my weekly scheduled reboots I’ll stop the openhab2 service and then copy the contents of /var/lib/openhab2 and /etc/openhab2/ onto a memory stick.
I use Open Energy Monitor for my graphing on my secondary Pi, so I’ll add the Openhab backup on that one to the OEM backup routine and automate it.
@mstormi my tmpfs settings from fstab are:
tmpfs /tmp tmpfs nodev,nosuid,size=30M,mode=1777 0 0 tmpfs /var/log tmpfs nodev,nosuid,size=50M,mode=1777 0 0 tmpfs /var/lib/dhcp tmpfs nodev,nosuid,size=1M,mode=1777 0 0 tmpfs /var/cache/samba tmpfs nodev,nosuid,size=40M,mode=1777 0 0 tmpfs /var/lib/logrotate tmpfs nodev,nosuid,size=1M,mode=1777 0 0
I run a read only root, with /etc/openhab2 and /var/lib/openhab2 redirected to an ext2 partition with file and directory access time turned off.
I’ve also just turned the events.log off until I need it by changing line 6 of /var/lib/openhab2/org.ops4j.pax.logging.cfg to
log4j.logger.smarthome.event = ERROR, event, osgi:*
This doesn’t effect the card writes as /var/log is in RAM on my system but it does waste clock cycles. This file gets a lot of writing for anyone who hasn’t redirected their /var/log folder to tmpfs, on my system it got 2.8MB in around 8 hours, most of which I was asleep for. Not the end of the world in terms of card writes, but every thing adds up.
Whilst we are a bit off topic how have you found the Razberry card? I’m awaiting some Z Wave blind controllers from Indiegogo and need to add a Z Wave interface to my Pi3 for when they arrive, I was thinking of a Aeon Labs Gen 5 Stick, but the Razberry is about half the price. Does it do all the frequencies and is it capable of just working without endless tweaking and bugs?
Well, the USB stick has one big advantage, in my opinion: you can use it with a RPi or with a regular PC. Heck, you can even use it with a NAS and an openHAB docker container or a virtual machine. With the RaZberry you have to stick to the Pi, of course. Also, as far as I know, the Aeon stick has a small battery so you can move it and perform inclusion and exclusion near the device. With the RaZberry, you’ll have to bring the device to the Pi
As for you last question… never needed to tweak anything. I just plugged the daughter board and go
thanks, thinking about it the portability when plugged into a windows tablet could be useful
The USB stick from zwave.me is essentially the same as the RaZberry board. Just unlike the Aeon, it has no battery power+inclusion mode button.
PS: on portability: if required, you can power your Pi (w/ RaZberry) from a smartphone battery pack and move around.
My migration of persistence to the NAS (mariaDB went well - see also How to transfer MySQL (JDBC) persistence to your NAS)
Unfortunately I did not succeed with the transfer of the logs.
This is what I did:
Created a user on my NAS (openhab)
Created a shared NFS folder – e.g. openhab
Created a folder (mount point): sudo mkdir -p /mnt/nfs/var
I created within openhab on the NAS: log/openhab2
Mounted the share: sudo mount -t nfs -o soft 192.168.178.39:/volume1/openhab/var /mnt/nfs/var/
Checked whether it works with write access: touch /mnt/nfs/var/test
Enabled rpcbind during boot: sudo update-rc.d rpcbind enable
Added to fstab: 192.168.178.39:/volume1/openhab/var /mnt/nfs/var nfs rw 0 0
Moved the logs to the mounted folder: sudo mv /var/log /mnt/nfs/var/
Created a symbolic link: sudo ln -s /mnt/nfs/var/log /var/log
Unfortunately my RPi was not accessible anymore after reboot through ssh.
I know that it might cause problems moving the logs during runtime, but I guess the files will only be messed up!?
I just discovered here a lot of posts about the problem of wear for SDcards.
I have bought a RPI4 with the plan to use it later with openhab for my home automation .
I am a bit surprised because I have my heating, solar panels and blinds Are managed for 14 year On a winCE platform logging data with
on flash memory every minutes and never experiment such problem.
Ok the system was changed 4 times in 14 years. The last version is using SD cards already for 4 years now… Iis WinCE… managing SD cards differently to avoid wear problem? Or is the hardware of RPi that cause this?
I was planning to replace this system in next year because the company selling it as stopped supporting it.
My plan for now is to use another RPi3 running Codesys for the heating system but the recording of archives would be also on SD , USB stick or SSD connected to the RPI
I prefer codesys to openhabian because I am working in industrial PLC world but openhab will be part of the solution to interconnect existing system like Domintell system, Hue Bulbs, Gardena Water management , Gardena robot mower…
You just revived a 3 yr old thread. And I didn’t get what your question was ?
Thanks for your reply
Sorry for refreshing a old subject.
I read first the long conversation you had with some new user about ZRAM and persistence trouble on RPI4 but I thought that it was not the right place to post this. I came here by searching to understand how the wearing problem occur .
Perhaps a new topic should be created but I am quite new on this forum, so I preferred to to it here.
You are right, I finished my witness without a clear question.
So is the wearing problem of SD card specific to the event driven philosophy of openhab, is it specific to RPi hardware or Rasbian ? Or due to a combination of the three factors?
Feel free to move conversation this to another place if more appropriate .
Neither of these, it applies to any flash hardware when you just write enough.
Full story here.
Thank you, Markus, very much for the link of the complete story that show clearly that some people have trouble very often and some other are lucky to have none.
As I am a total newbie in this Raspi and Linux Word, I will try the solution proposed in your nice post before beginning any serious openhab configuration .
Use the openHABian image for RPi. It has ZRAM activated by default.