Consideraciones para una Raspberry Pi de larga duración

Artículo original ↗ Discusión en Hacker News ↗

Ingenieros y aficionados comparten experiencias sobre cómo mantener Raspberry Pis funcionando de forma fiable durante años, centrándose sobre todo en los fallos de almacenamiento por tarjetas microSD y en cómo evitarlos. Las sugerencias van desde arrancar desde SSD, usar sistemas de archivos de solo lectura o con overlay, tmpfs para registros, UPS y watchdogs, hasta opciones más radicales como el arranque por red, módulos de cómputo con eMMC o reemplazar las Pis por completo por mini PCs x86 o microcontroladores como ESP32. Aunque muchos informan de un funcionamiento sin problemas con buenas SD y alimentación estable, otros sostienen que hace falta ingeniería adicional cuando se escala más allá de unos pocos dispositivos o se ejecutan cargas con muchas escrituras.

Almacenamiento y fiabilidad de la tarjeta SD

  • Los problemas con las tarjetas SD dominan la discusión. Muchos informan de corrupción o fallo de la SD a lo largo de los años; otros dicen que unas buenas tarjetas + buenas fuentes de alimentación pueden durar una década.
  • Causas citadas: alimentación inestable (cargadores baratos, conectores defectuosos, caídas de tensión), tarjetas SD de baja calidad, valores predeterminados de sistemas operativos antiguos (p. ej., escrituras por tiempos de acceso), cargas de escritura elevadas (registros, bases de datos).
  • Mitigaciones: usar tarjetas SD de alta resistencia o industriales, sobredimensionar tarjetas más grandes, evitar modos SDR104/de alta velocidad (menos calor), o pasar a SSD/NVMe vía USB/PCIe.
  • Varios recomiendan arrancar desde un SSD USB o NVMe; algunos tratan el SSD como efectivamente “desechable”, pero señalan que en la práctica rara vez fallan.
  • Algunos argumentan que los módulos de cómputo con eMMC soldada evitan problemas de contacto y tienen una memoria flash mejor especificada.

Enfoques de sistema de archivos de solo lectura y bajo nivel de escritura

  • Estrategias populares: raíz de solo lectura con overlayfs, tmpfs para /tmp y a menudo /var, log2ram, registro remoto y modos sin disco o similares a sin disco (Alpine diskless, TinyCore, Buildroot, NetBSD embedded, gokrazy, esquemas overlay personalizados).
  • Algunos van más allá con particiones del sistema A/B y actualizaciones de imagen completa, o arrancando completamente por NFS sin almacenamiento local.
  • Otros consideran que estas medidas son excesivas para configuraciones domésticas y confían en copias de seguridad + reemplazo periódico de la SD.

Energía, red y watchdogs

  • La estabilidad de la alimentación se recalca repetidamente: fuentes oficiales o de marca de 5V, evitando cargadores USB poco fiables, y a veces además un UPS o batería.
  • El micro-USB y los conectores flojos se señalan como riesgos de fiabilidad; algunos los sustituyen por conectores barrel jack.
  • Se prefiere Ethernet para sistemas de larga duración; WiFi se considera inestable, con “watchdog scripts” comunes para reiniciar interfaces o reiniciar el sistema ante pérdida de conectividad.
  • Se recomiendan watchdogs de hardware (y la integración watchdog de systemd) para sistemas desatendidos.

Hardware alternativo

  • Muchos sugieren mini PCs/NUCs x86, thin clients o desktops corporativos usados/Chromeboxes como mejor valor que las Raspberry Pi modernas: más RAM/CPU, SSD, amplio soporte de Linux, y a menudo bajo consumo en reposo.
  • Otros destacan ARM/microcontroladores (ESP32, RP2040) como opciones más baratas, de menor consumo y más fiables para tareas simples o alimentadas por batería, aunque con mayor fricción de desarrollo.
  • El debate continúa: algunos dicen que la Pi “casi nunca” es la respuesta correcta; otros confían en las Pis para señalización, servidores domésticos, gateways y proyectos con mucho GPIO, y reportan varios años de uptime.

Prácticas operativas

  • Prácticas comunes: desactivar swap, minimizar registros, clonar regularmente las SD, usar gestión de configuración (Ansible) para reconstrucciones reproducibles y reiniciar tras las actualizaciones para detectar fallos temprano.