Part of the Raspberry Pi Reliability series.
Keeping a Raspberry Pi online and working with zero intervention for weeks, months, or years is somewhat of an art form. Several classes of things can go wrong, and you need to consider how your Pi will recover from each of them — and weigh the risks of each solution against its benefits.
This new set of posts in my Raspberry Pi Reliability series covers each class of issues I’ve run into, and what I’ve done to solve them. As a bonus, these posts also include some tips on monitoring, mainly using Uptime Kuma.
This aims to be a more comprehensive guide than my previous post on reducing SD card wear, and the posts linked here should be considered an updated replacement for that post.
Without further ado:
- The WiFi connection can fail
- Your software service can stop working
- Hardware/firmware/driver instability can cause a crash
- Your SD card can wear out or completely fill up
- Start by choosing the right microSD card
- Don’t use the SD card for swap!
- Choose one of…
- Aggressively manage things that write to the SD card (especially logs)
- Make the Pi’s root filesystem read-only
- In the interest of getting this series of posts finished in fewer than 2 months, for now I’ll point you to my 2021 post on reducing SD card wear, particularly the read-only root filesystem section or the non-read-only root filesystem section. I plan to produce two updated, easier-to-read guides here in the near future, for my own reference as much as yours; watch this space!
- Check the filesystem often if you’re not using a read-only root filesystem
- Disabling unneeded services helps with both software stability and SD card wear
Also, do these:
- Consider risks and benefits before applying any invasive intervention
- Remote logging can help you figure out what went wrong, when something does go wrong
This Stack Exchange post suggests disabling journaling for the Pi’s filesystem. Don’t do this. While this change might reduce SD card wear, it makes your Pi more likely to face filesystem corruption in the event of a crash or power outage. My goal is to make my Pis more reliable, and disabling journaling works against that goal.
Inevitably I’ll come back to the posts linked above with corrections and additions. For the foreseeable future, when this happens, I will:
- Edit the post
- Add a callout in the post noting the date the change was made
- Write a brief post in the Pi Reliability blog series announcing the change, with a link to the edited post
To keep up with these updates without subscribing to my blog's full feed, you may subscribe to the Atom feed for my Raspberry Pi Reliability series.