Una microSD muerta empujó la reconstrucción de este servidor Pi

Una microSD defectuosa convirtió un servidor doméstico Raspberry Pi 4B que llevaba tiempo en funcionamiento en un proyecto de recuperación —y en una oportunidad para rediseñarlo correctamente. El problema empezó cuando el servidor dejó de responder: las listas de torrents no se cargaban, un montaje SMB falló y no se podía acceder por SSH. Al reiniciar, tanto la generación actual como la anterior de NixOS se quedaban colgadas después de cargar el kernel.

Una comprobación del sistema de archivos pareció prometedora al principio, pero fsck.ext4 seguía encontrando nuevos errores cada vez que se volvía a insertar la tarjeta. La conclusión fue simple: la tarjeta estaba probablemente muerta, y un reciente corte de energía en todo el edificio le dio el golpe final.

La pérdida fue limitada. Los datos más importantes residían en discos duros externos, mientras que la configuración del sistema se conservó en gran medida en NixOS. Lo que desapareció de la tarjeta fueron archivos .torrent y cachés de Navidrome, Jellyfin y slskd, todos recuperables. Los datos de Immich ya estaban respaldados en un disco externo.

Cómo la nueva configuración reduce el desgaste de la microSD

La reconstrucción se centró en tres objetivos: reducir las escrituras en la microSD, añadir redundancia al almacenamiento externo y hacer copias de seguridad de todo lo importante.

Para evitar desgastar la tarjeta nueva, la configuración ahora usa:

Recomendado

PsiQuantum apuesta por la luz para un ordenador cuántico de 100 gabinetes

• zram para swap en vez de swap en disco
• tmpfs para /tmp
• registro de journald volátil en memoria
• noatime en el sistema de archivos raíz para evitar escrituras por acceso

El sistema de archivos raíz sigue en la microSD, pero se escribe mucho menos en ella. La tarjeta de repuesto es un modelo de 64 GB comercializado como de alta resistencia, en sustitución de la anterior de 128 GB.

Un pool btrfs construido con discos antiguos

Para el almacenamiento masivo, el servidor ahora usa dos HDDs antiguos de 2,5 pulgadas —un disco de 500 GB y otro de 320 GB— combinados en un pool btrfs con raid1 tanto para datos como para metadatos. El pool se llama ポンコツ, aproximadamente «pieza de chatarra».

El autor eligió btrfs por sus pools de almacenamiento flexibles y los subvolúmenes. Cada servicio obtiene su propio subvolumen, gestionado de forma declarativa mediante un módulo autosubvol personalizado que crea unidades de montaje y asegura que los subvolúmenes existan antes de que arranquen los servicios dependientes. También se creó un subvolumen separado para /var/cache.

También se limpiaron los permisos. Un grupo de medios compartido da a servicios como Transmission y Jellyfin acceso a los mismos archivos, y Transmission está configurado para que las nuevas descargas hereden la pertenencia de grupo adecuada.

Las copias de seguridad se basan en restic, integrado a través de un pequeño módulo Nix que enlaza sops-nix y el módulo restic de nixpkgs. Por ahora, el almacenamiento remoto vía S3 y la replicación suplen a un sistema de instantáneas local más elaborado.

El pool de almacenamiento ya ha crecido. Ahora incluye un disco de 1 TB junto con los discos de 500 GB y 320 GB, manteniendo raid1 para datos y metadatos, con planes de añadir otro disco viejo de 500 GB más adelante. Un disco ext4 separado de 10 TB lleno de ISOs de Linux permanece fuera del pool.

La pieza final fue el despliegue. En lugar de instalar NixOS manualmente en la Pi, el autor construye una sdImage arrancable directamente desde la configuración del sistema y la escribe en la tarjeta con dd. Tras conectar la nueva configuración a una UPS recién comprada, el servidor volvió a estar en línea a tiempo para reproducir música desde Navidrome durante el viaje de vacaciones.