Considerations for a long-running Raspberry Pi

Original Article ↗ Hacker News Discussion ↗

Engineers and hobbyists trade experiences on keeping Raspberry Pis running reliably for years, focusing heavily on storage failures from microSD cards and how to avoid them. Suggestions range from booting from SSDs, using read‑only or overlay filesystems, tmpfs for logs, UPSes and watchdogs, to more radical options like network booting, compute modules with eMMC, or replacing Pis entirely with x86 mini‑PCs or microcontrollers such as ESP32. While many report trouble‑free uptime with good SD cards and stable power, others argue that extra engineering is warranted once you scale beyond a few devices or run write‑heavy workloads.

Storage & SD Card Reliability

  • SD card issues dominate the discussion. Many report SD corruption or failure over years, others say good cards + good power supplies run for a decade.
  • Causes cited: unstable power (cheap chargers, bad connectors, brownouts), poor-quality SD cards, older OS defaults (e.g., access-time writes), high write workloads (logs, databases).
  • Mitigations: use high-endurance or industrial SD cards, overprovision larger cards, avoid SDR104/high-speed modes (less heat), or move to SSD/NVMe via USB/PCIe.
  • Several recommend booting from USB SSD or NVMe; some treat SSD as effectively “disposable” but note they rarely fail in practice.
  • Some argue compute modules with soldered eMMC avoid contact issues and have better-specified flash.

Read-Only & Low-Write Filesystem Approaches

  • Popular strategies: read-only root with overlayfs, tmpfs for /tmp and often /var, log2ram, remote logging, and diskless/diskless-like modes (Alpine diskless, TinyCore, Buildroot, NetBSD embedded, gokrazy, custom overlay schemes).
  • Some go further with A/B system partitions and full-image updates, or booting completely over NFS with no local storage.
  • Others consider these measures overkill for home setups and rely on backups + periodic SD replacement.

Power, Networking, and Watchdogs

  • Stable power is repeatedly stressed: official or branded 5V supplies, avoiding flaky USB chargers, sometimes plus a UPS or battery pack.
  • Micro-USB and loose connectors are noted as reliability risks; some retrofit barrel jacks.
  • Ethernet is preferred for long-running systems; WiFi is viewed as flaky, with common “watchdog scripts” to reset interfaces or reboot on connectivity loss.
  • Hardware watchdogs (and systemd watchdog integration) are recommended for unattended systems.

Alternative Hardware

  • Many suggest x86 mini PCs/NUCs, thin clients, or used corporate desktops/Chromeboxes as better value than modern Pis: more RAM/CPU, SSDs, broad Linux support, often low idle power.
  • Others highlight ARM/microcontrollers (ESP32, RP2040) as cheaper, lower-power, and more reliable for simple or battery-powered tasks, though with higher development friction.
  • Debate persists: some say Pi is “almost never” the right answer; others rely on Pis for signage, home servers, gateways, and GPIO-heavy projects and report multi-year uptimes.

Operational Practices

  • Common practices: disabling swap, minimizing logs, regularly cloning SDs, using config management (Ansible) for reproducible rebuilds, and rebooting after updates to catch breakages early.