The death and rebirth of my home server

Original Article ↗ Hacker News Discussion ↗

Raspberry Pi–based home servers are praised for low power and cost but widely reported to suffer from SD card corruption, especially under constant writes and unreliable power. Commenters compare strategies to improve reliability—booting from SSDs or NVMe, using read‑only filesystems, thin clients or mini‑PCs instead of Pis, and relying on declarative setups or automated backups so rebuilds are trivial rather than catastrophic. The exchange broadens into how long consumer hardware actually lasts, what SMART and other tools can (and can’t) predict about failures, and why ease of maintenance often matters more than making any single component bulletproof.

Raspberry Pi SD Card Reliability

  • Many reports of SD and micro‑SD cards degrading or corrupting on Pis, especially under 24/7 use.
  • Some users see years of trouble‑free operation; others report multiple dead cards and even overheated boards.
  • Disagreement on root cause: bad/cheap cards and poor power vs. Raspberry Pi defaults and usage patterns.
  • Some argue the issue is mostly software/owner behavior; others say the defaults make failure likely, so it’s effectively a Pi problem.

Causes and Mitigations for Flash Corruption

  • Flash wear from frequent writes (logs, swap, atime updates) is a recurring theme.
  • Early Pi images lacked sane defaults (e.g., noatime), increasing write volume.
  • Suggested mitigations:
    • Use tmpfs/ramdisks for logs and temp data.
    • Disable swap on SD or move swap to SSD/zram.
    • Make root filesystem read‑only; some report this helps, others say corruption still occurs.
    • Use higher‑quality or industrial SD cards, or avoid SD entirely.

Alternatives to SD and to Raspberry Pi

  • Popular workaround: boot Pis from USB SSDs or NVMe (Pi 4/5, HATs, Compute Modules with onboard flash).
  • Some repurpose cheap enterprise SATA SSDs or Optane for “overkill” durability.
  • Growing sentiment that used mini PCs (OptiPlex/ThinkCentre/EliteDesk, old thin clients, NUC‑style boxes) offer better price/performance and reliability than full‑size Pis for server tasks.
  • A few negative experiences with specific mini‑PC brands (hard‑to‑reboot hardware faults).

Home Server Lifespan, Failures, and Monitoring

  • Many anecdotes of decade‑plus continuous operation from desktops and servers.
  • Common failures in larger fleets: power supplies, RAM, spinning disks; SSD wear is more predictable.
  • SMART exists but often fails to predict sudden disk death; redundancy and backups are emphasized over prediction.
  • Hardware failure rates follow a “bathtub curve”: early defects, long stable period, then age‑related failures.

Swap, zram, and Memory Use

  • Debate over using zram on low‑end systems:
    • One view: swap is only for out‑of‑RAM emergencies, so using RAM for swap makes no sense.
    • Counterpoint: swap (and zram/zswap) is about efficient memory reclamation, not emergency overflow, and can be beneficial if tuned.

Self‑Hosting Experience and Tooling

  • Self‑hosting is described as rewarding but fragile; boot media failures are more disruptive than data disk failures.
  • Declarative systems (Nix/Guix) and LLM‑based “clankers” are praised for making rebuilds, debugging, and reconstructing old setups less painful.
  • Some see a gap for services that are hosted but easily portable back to self‑hosted hardware.