Emotional!

Actually, when I started using the new card, I moved my log and database files back onto the card.
And this gave me quite the performance boost.

1 Like

None, look at it this way, if they’re fast enough to write 60fps HD video to in a dashcam, anything you do in HA will be fine.

They do still have a finite life though so not a replacement for regular backups etc.

1 Like

Hello, the SD card on a Raspberry Pi will always be a problem (further readings: https://hackaday.com/2016/08/03/single-board-revolution-preventing-flash-memory-corruption/ ) . The only solution is to have everything run in rams, and mount the root read-only. The “overlayfs” system will do that.
So I just installed this excellent script: https://github.com/janztec/empc-arpi-linux-readonly by running sudo bash install-experimental.sh first and making the other changes, swap, /var/log … etc later. It works very well on my: uname -a : Linux rpi3b_Hass 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux.
Hass is spamming /var/syslog and /var/daemon.log so I had to tell rsyslogd to stop logging with /etc/rsyslog.d/00-hass.conf with content: if $programname == "hass" then ~. It is also a good idea to moderate the /.homeassistant/homeassistant.log wih a: logger:
default: fatal
after you finalized your setup in in configuration.yalm.
A df will show you that the root is now mounted ro and any changes will now be written in /rw/upper which is a type tmpfs hence in ram… caveat: they won’t survive a reboot, so to make updates or permanent changes change overlay=yes to overlay=no in /boot/cmdline.txt … reboot… etc…
You can expect the SD card to last for a very long time if used that way, and this will really make your Raspberry Pi totally reliable.
jrb.

only problem is none of that is possible to do with hass.io

Hello, would you enlighten me… I indeed manually installed hass on a full raspbian, so I don’t know about hass.io

you’re posting in the hass.io section. This is a lot different to installing home assistant in raspbian. Hassio is like an appliance with no real access to the underlying operating system (which is a minimal version of linux)

Thank’s, I understand, I will have a look at hass.io, I think the SD issue is important enough in any platform !
bye

Hi, it seems HassOS already mounts the root folder as read-only, as I’ve been unable to edit files in the /etc/ folder.

My uname -a = Linux hassio 4.14.78-v7 #1 SMP Sat Oct 27 15:51:10 UTC 2018 armv7l Hassio/O

Also there already seems to be an overlay filesystem mounted in /mnt/overlay/ so you may not not need to install extra stuff.

Hello, I’m very happy to hear that, because if Hass.io already works that way, you get no more SD card corruptions, and the PI becomes a very reliable platform. I hadn’t realize Hass.io was this different from HA on Raspbian when I posted…
Could I ask how you can see the HassOS internals, I was reading that ssh has a somewhat limited commands set !
If Hass.io does not already work that way, the most reliable solution remains what I did, with overlayfs and HA on Raspbian. This could be an improvement request to Hass.io if not.

Well I’m not 100% on how the whole of Hass.io/HassOS works, It does need to write to the SD card to write to the Database files, but it seems 99% of the files that aren’t in /config/ are mounted read-only from what I’ve seen so far.

If you want to check it out for yourself you can login over SSH as the root user using the instructions here: https://developers.home-assistant.io/docs/en/hassio_debugging.html#hassos-based-hassio

Currently I have an addon that backs up my snapshots to dropbox every night, so if I do get SD card corruption I won’t lose my settings and config files.

Hello, I just installed hass.io and the ssh addon, and I was struck by the light !!!

If you do a mount command, you will see that the root (/) is indeed an overlay mount, with lowerdir, upperdir, etc… Hass.io definitely uses the overlayfs system, the vital parts are mounted ro, /dev/mmcblk0p8 receives some infrequent writings… a df command will show you that the rest is tmpfs, in other words in rams.

This is great works from the developers, and justify switching to hass.io .

If we convert this discussion to a constructive way of avoiding recurrences:

How would you extend the backup system to validate that the backup is functional?

I recently worked in a multi-exabyte (not a typo) backup system wherein a key issue was that users didn’t validate their backups. Consider this sort of surprise in a ridiculously huge backup. This is why I ask how the backup could be validated to assuage fears, and really, how the system could possibly validate it for the user.

1 Like

Excellent direction to consider.

I do sometimes open the backup file and see that it has files in it… it has multiple rar files and I also open the biggest of those which contains yaml files. Would be good if there was a validator.

I think sometimes the backups can take a long time to make and if the user bailes ‘thinking’ it is finished this is where some problems creep in. That’s why I do backups automatically at 3am and then use the dropbox add-on to copy at 4am.

As I’ve said before I have never seen a backup fail.

I have actually noticed issues with some of my older backups. I was running hassio on a pi 3 and I think the size of my installation caused issues with snapshots. For example if I opened the snapshot and looked at the RAR file containing the largest files I noticed that the backup seemed to halt at the .db file; any yaml files that should have existed alphabetically after the database file ended up not being included in the backup.

My database file at one point was getting over 1gb in size (even with two-day purges; lots of CPU, ping and other sensors). I think the process of bundling this database file into the snapshot was silently failing.

Since moving to a VMDK in Virtualbox on my main server the snapshots have been flawless.

what recurrences ?

I consider this remark rude. Forums are intended for everyone no matter their level of expertise. My intent was to point out the unreliability of the PI because of the SD card corruption problem, which is something not clearly explained in the Home Assistant community. If you have something to say about my questions and comments please say so directly instead of this convoluted way of implying my “recurrences” are not constructives, and your’s is…

1 Like

I’m sorry you interpreted my writing that way; that’s really the opposite of what I had intended to convey. I tried to suggest that discussing whether there was a human error was not constructive; rather, assuming tytusek some tech background, and assuming some skill on his/her part, let’s assume that this is a valid situation that may occur both to tytusek, and to people who know or don’t know it’s failing yet for them – so how can we make this situation less likely?

I’m not sure “how to avoid recurrences” indicates that tytusek’s experience is invalid; rather, it would suggest that I wanted to discuss avoid recurrences of this situation, which may suggest that I thought it likely to recur. Had I discounted your experience, I might be suggesting the opposite, but assuming skilled individuals such as yourself and others can experience this, how can we avoid that by validating the backup?

I can’t alter how you have interpreted what I wrote, I can only suggest that I meant no insult, and if you assumed that there was no insult intended, can you possibly see a positive intention behind my comment? I’m sorry you interpreted it exactly the opposite to how I intended.

Note: I don’t have a hidden or convoluted or indirect meaning in this comment either. I tend to try to write directly, with the concern that it may be misinterpreted, but I do my best to be straightforward. I’ve written as directly as I can. Please consider the possibility of good intentions herein as well.

FWIW I would like to continue discussing how to avoid recurrences.

1 Like

Sorry myself, my bad, I get your point now…