My Home Assistant server runs on a Raspberry Pi 5, and for the first stretch of its life it booted from a microSD card. NVMe had always been the plan; I just assumed I’d get to it on my own schedule. The Pi decided to move that schedule up.
This is the story of how that failure played out, what finally pointed at the real culprit, and what restoring a real backup taught me.
At a glance
| Hardware | Raspberry Pi 5 (8 GB), wired Ethernet |
| Symptom | SD timeouts and read errors, with Home Assistant failing |
| Real cause | The Pi’s onboard SD reader, not the card |
| Fix | New Home Assistant OS install on an NVMe SSD, then restore from a recent backup |
| Result | Core back in service; the failed Pi became my backup appliance |
Blaming the card (the obvious theory)
It started the way a failing card does: SD timeouts and read errors. I’d already lost one microSD card during the first day of setting this system up, so “another dead card” was the obvious theory, and I treated it that way.
The clue that changed my mind
Then I put a separate test card in the same Pi, and it failed the same way.
Two different cards failing identically in one machine is a strong hint that the card isn’t the problem. Other things kept working: the Pi’s bootloader ran and its HDMI output was fine. And when I presented its storage through a USB reader instead of the onboard slot, the Pi behaved correctly. The common factor was the Pi’s own SD reader.
The original card later checked out fine outside that boot path. I can’t prove it was completely innocent, but everything pointed at the reader, not the card.
Moving to NVMe, which was always the plan
The failure forced the move right then instead of on my schedule. I installed a fresh Home Assistant OS on an NVMe SSD of about 256 GB, restored a recent Home Assistant backup onto it, and Core came back.
The major integrations reconnected. Tuya needed a fresh login. Afterward I didn’t just trust that it was up. I walked the whole touchscreen to check that it was telling the truth: garage control, the cameras, lighting, the thermostat, the printer, the robot vacuum, weather and the Bathroom Health display all came back and checked out. The one holdout was commute traffic, which stayed down until a Home Assistant update fixed it.
What happened to the Pi that failed
It didn’t go in the bin. The Pi with the faulty reader, once I’d stopped trusting it for production, became the hardware for my backup appliance, the JRHome Vault. The Raspberry Pi 5 running Core today is a different board.
The old microSD card was retired from production and later reformatted for reuse, once I’d confirmed it held nothing I’d still need.
Two lessons
1. Don’t boot a production head end from microSD when NVMe is available and already planned. A single onboard SD interface was a single point of failure, and here it was the reader, not even the card. I should have moved before it failed.
2. A backup gets a lot more convincing after it has actually restored the running house. A while earlier I’d written in my own recovery notes that a backup that has never been restored is a hope, not a backup. This was the one that stopped being a hope. It worked because a recent backup existed. My off-device backup copy still wasn’t finished when it happened, so everything depended on that backup being somewhere I could reach.
That second lesson is why I built the Vault: so the next recovery starts from independent, integrity-checked copies kept apart from the house itself.
If your Pi starts throwing SD errors
- Don’t assume the card. Try a second card in the same Pi. If both fail the same way, suspect the reader.
- Check what still works. A Pi that reaches its bootloader and drives HDMI isn’t completely dead.
- Try USB storage. If the Pi runs fine from a USB device, the problem is the onboard interface.
- Take backups before you need them, and keep one somewhere else. Check that you can restore one.
Leave a Reply