La muerte y el renacimiento de mi servidor doméstico

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

Los servidores domésticos basados en Raspberry Pi son valorados por su bajo consumo y coste, pero se informa ampliamente de corrupción de tarjetas SD, especialmente bajo escrituras constantes y alimentación poco fiable. Los comentaristas comparan estrategias para mejorar la fiabilidad: arrancar desde SSD o NVMe, usar sistemas de archivos de solo lectura, usar thin clients o mini PCs en lugar de Pis, y apoyarse en configuraciones declarativas o copias de seguridad automáticas para que reconstruir el sistema sea trivial en vez de catastrófico. El intercambio se amplía a cuánto dura realmente el hardware de consumo, qué pueden prever y qué no SMART y otras herramientas sobre los fallos, y por qué la facilidad de mantenimiento a menudo importa más que hacer a prueba de balas cualquier componente concreto.

Fiabilidad de las tarjetas SD en Raspberry Pi

  • Muchos informes de tarjetas SD y micro‑SD que se degradan o se corrompen en las Pis, especialmente con uso 24/7.
  • Algunos usuarios ven años de funcionamiento sin problemas; otros informan de múltiples tarjetas muertas e incluso placas sobrecalentadas.
  • Hay desacuerdo sobre la causa raíz: tarjetas malas/baratas y mala alimentación frente a los valores predeterminados de Raspberry Pi y los patrones de uso.
  • Algunos sostienen que el problema es sobre todo de software o de comportamiento del propietario; otros dicen que los valores predeterminados hacen que el fallo sea probable, así que en la práctica es un problema de la Pi.

Causas y mitigaciones de la corrupción de la memoria flash

  • El desgaste de la flash por escrituras frecuentes (registros, swap, actualizaciones de atime) es un tema recurrente.
  • Las primeras imágenes de Pi carecían de valores predeterminados sensatos (por ejemplo, noatime), lo que aumentaba el volumen de escritura.
  • Mitigaciones sugeridas:
    • Usar tmpfs/ramdisks para los registros y los datos temporales.
    • Desactivar swap en la SD o moverla a SSD/zram.
    • Hacer el sistema de archivos raíz de solo lectura; algunos informan que ayuda, otros dicen que la corrupción sigue ocurriendo.
    • Usar tarjetas SD de mayor calidad o industriales, o evitar la SD por completo.

Alternativas a la SD y a Raspberry Pi

  • Solución popular: arrancar las Pis desde SSDs USB o NVMe (Pi 4/5, HATs, Compute Modules con flash integrada).
  • Algunos reutilizan SSD SATA empresariales baratos o Optane por una durabilidad “excesiva”.
  • Crece la sensación de que los mini PCs usados (OptiPlex/ThinkCentre/EliteDesk, antiguos thin clients, cajas tipo NUC) ofrecen mejor precio/rendimiento y fiabilidad que las Pis de tamaño completo para tareas de servidor.
  • Unas pocas experiencias negativas con marcas concretas de mini PCs (fallos de hardware difíciles de reiniciar).

Vida útil de servidores domésticos, fallos y monitorización

  • Muchas anécdotas de más de una década de funcionamiento continuo en escritorios y servidores.
  • Fallos comunes en flotas más grandes: fuentes de alimentación, RAM, discos giratorios; el desgaste de SSD es más predecible.
  • SMART existe, pero a menudo no predice la muerte súbita de un disco; se enfatizan la redundancia y las copias de seguridad más que la predicción.
  • Las tasas de fallo de hardware siguen una “curva de bañera”: defectos tempranos, largo período estable y luego fallos relacionados con la edad.

Swap, zram y uso de memoria

  • Debate sobre el uso de zram en sistemas de gama baja:
    • Una visión: swap solo sirve para emergencias por falta de RAM, así que usar RAM para swap no tiene sentido.
    • Contrapunto: swap (y zram/zswap) trata de la recuperación eficiente de memoria, no del desbordamiento de emergencia, y puede ser beneficioso si se ajusta bien.

Experiencia y herramientas de autoalojamiento

  • El autoalojamiento se describe como gratificante pero frágil; los fallos del medio de arranque son más disruptivos que los fallos del disco de datos.
  • Los sistemas declarativos (Nix/Guix) y los “clankers” basados en LLM son elogiados por hacer menos dolorosas las reconstrucciones, la depuración y la reconstrucción de configuraciones antiguas.
  • Algunos ven un vacío para servicios que están alojados, pero que son fácilmente portables de vuelta a hardware autoalojado.