RPI3B - Redundant and stable installation

What is the best I can do to make a stable install on a RPI 3B with a SD card.
From time to time I have seen problems that I think is related to the SD card on both my installations and for one of them I have now switched to a pure HAOS installation on an old laptop.

But for the RPI installation I still have, I would like to stick to the thin installation with RPI3B and a SD card. It’s placed ~100 km from home so I’m not that keen on doing the travel just to reinstall and/or replace a faulty SD card.

My thinking is if it’s possible to turn the SD card into a redundant storage. Maybe installing Proxmox on the PI and hosting HA on a ZFS miraged storage of an oversized SD card. Yes, the SD card bandwidth will probably be an issue but lets say we can live with that.

Any other more “thin” suggestion?

SD cards are indeed a compromise for storage; I think they were never intended for write loads such as a server OS (logfiles) creates.

In my RPi projects I always started out with power supplied through the USB connector and later always switched to a more stable supply (5V fed in through the GPIO-header, regulator on the HAT), as monitoring the 5V Power level (oscilloscope) over multiple time ranges showed lots of fluctuations.
SD cards are very susceptible to power fluctuations during write operations.
Learned that the hard way on an Arduino project, where I had somewhat wonky power supply: the ATMega was perfectly happy, the SD failed.
In the following way:
During a write, the SD draws more power than in any other state (this is how Flash memory works). So this is when the voltage will dip lowest and may dip below minimum-required for the SD to work.

After a write, the SD card verifies the written data.
If the verify fails, the block written is assumed to contain a defective Flash cell and is mapped out: a reserve block is used instead.
The typical SD controller does not monitor power supply voltage and does not make a distinction between different reasons why the write may have failed (bad Flash vs. low voltage).
They typically also do not retry a failed write for marketing purposes: this would show as “slow write speed” in your typical magazine/website “SD card comparison test”.

In my Arduino project that very quickly killed SD cards: writes failed frequently and I burned through the reserve blocks in a flash.
Some cards will switch to read-only mode when out of reserve, some will simply die.

That lesson learned, I did monitor the supply for the SD in my RPi projects very thoroughly and that led me to roll my own power supply circuit each time :slight_smile:

In later projects I only used RPi models capable of booting from USB storage; I think that is the RPi4? There I uses USB-SATA-adapters with SATA SSDs.

Ever since I discovered Syncthing for my uses, I use it everywhere: to sync the photo gallery between my phones and my computers, to sync the CNC CAM files between all computers in the workshop etc.
I am not using it on HAOS, because its not available there. Because the thing is so locked-down and the homeassistant-on-OS installation lacks features.

For my Homeassistant installation I am actually running on Proxmox, but AMD64 (USFF PC, the Pentium-dualcore-processor type that goes for around 100€ on Internet sites).
Not sure if proxmox would even work on ARM - or be any fun regarding performance.

hase

Thanks, I haven’t thought about that none stable power supply would classify cells as faulty. That might explain why my SD card seams to shrink.

This last time I had a crash I think it was due to that “someone” disconnected the power supply. The PI is placed at my fathers house (his 88 years old) and had worked fine for almost a year until for some days ago and when I visited him the power plug was disconnected. When I tried to restart, the home assistant application didn’t start.
I was able to read to at least read the SD card with dd but couldn’t create a working copy of it.

I have tried booting from USB on my RPI3 but didn’t succeed. As I understand all that’s needed is to set the boot bit in the OTP