Cómo armar un NAS con ZimaBlade y refrigeración con Tuya

En el artículo anterior comentaba un poco sobre la arquitectura de mi homelab y adelantaba cómo estaba integrando un ZimaBlade. Me decidí por este Single Board Computer (SBC) principalmente por dos razones de peso:

1. Memoria RAM DDR3L: Aunque es un formato que ya cuenta con sus años en el mercado, mantiene un rendimiento excelente para servidores tipo homelab. Al operar con memorias DDR3L (SODIMM a 1.35V) me permitió equipar este nuevo equipo con 16 GB de RAM a un costo bastante razonable, huyendo de la crisis de precios en memorias más recientes y de los altos costos de otros mini PCs.
2. Ranura PCIe nativa: A diferencia de la típica Raspberry Pi, contar con conectividad PCIe directa te abre la puerta a conectar tarjetas controladoras de discos o adaptadores de red de forma nativa sin cuellos de botella por USB. Y bueno, si algún día me animaba también podría instalarle alguna versión de Windows, aunque la meta siempre fue mantenernos en Linux.

El objetivo con este nuevo nodo era claro: reducir un poco la carga de la Raspberry Pi principal y tener un ambiente de pruebas para cualquier experimento que se me fuera ocurriendo.

Unboxing, Memoria y el Ecosistema CasaOS

Cuando recibes el ZimaBlade la memoria RAM no viene puesta, así que toca abrirlo para insertarla. Dependiendo de cómo lo compres, puedes pedirlo sin RAM y montarle algún módulo compatible que ya tengas por ahí guardado.

Otro detalle curioso es que ya viene con sistema operativo instalado de fábrica. Yo pensé que me tocaría pelearme con una instalación desde cero, pero ya viene con Debian y una interfaz web llamada CasaOS. Ojo aquí: pese a llevar “OS” en el nombre, no es una distribución de Linux. Es simplemente una capa visual muy cómoda sobre Docker para gestionar contenedores fácilmente, con una especie de “tienda de aplicaciones” donde encuentras servicios populares de la comunidad self-hosted como Immich o AdGuard Home, entre muchos otros.

RAID 5 con HDDs de 2.5” 💽

En este nodo quería montar un arreglo RAID 5, pero esta vez un poco más grande: 5 discos de 1 TB (lo que me deja unos ~4 TB útiles y la tranquilidad de paridad distribuida: si un disco muere, la información no se pierde).

Esta vez me fui por discos mecánicos (HDD) en lugar de discos de estado sólido (SSD), porque los SSD siguen estando carísimos. Eso sí, tenía claro que debían ser discos de 2.5” (los típicos de laptop) por dos razones clave:

• Tamaño compacto: Para que el montaje físico no terminara ocupando medio escritorio.
• Consumo eléctrico: Quería mantener la factura de la luz a raya. Los discos de 2.5” operan a 5V y consumen entre 0.8A y 1A en arranque (~2.5W a 4.5W en carga), notablemente menos que los discos de 3.5” que necesitan líneas de 12V adicionales para mover sus motores.

Los discos los conseguí de segunda mano: 4 de ellos me salieron entre $20 y $25 cada uno, y el quinto lo rescaté de una laptop vieja que tenía guardada.

Diagnóstico de Discos Usados y el Fix de Firmware con Claude Code

Al ser discos de segunda mano, lo primero que hice fue someterlos a distintas pruebas y revisar a fondo sus reportes S.M.A.R.T. (smartctl). Uno de ellos era claramente el que más horas de uso acumulaba y, al analizar su registro histórico, vimos que tenía acumulado un montón de errores de desconexión y eventos de pérdida de enlace; de entrada, la cosa no pintaba nada bien y parecía un disco candidato al descarte.

Sin embargo, interpretando los registros con la ayuda de Claude Code, descubrimos que se trataba de un Seagate ST1000LM035-1RK172, un modelo con un problema de firmware reconocido por el propio fabricante que generaba precisamente ese comportamiento anómalo en los registros de comunicación. La solución consistía en actualizar el firmware a la versión oficial más reciente y listo, con eso aumentaba su vida útil ampliamente. Siendo 100% honesto: por mi propia cuenta jamás habría dado con que ese historial se debía a un bug de fábrica con solución disponible; gracias a contrastar la telemetría con Claude Code pude rescatar el disco y dejarlo completamente operativo para el RAID.

Si te arriesgas con discos de segunda mano como en mi caso, definitivamente hazles una auditoría. No hace falta que conozcas todos los comandos de pies a cabeza: hazlo con un agente de IA, pero hazlo. No vale la pena poner en peligro toda la información que almacenes en esos discos cuando podrías haberlo evitado fácilmente.

Expansión PCIe SATA y Alimentación Eléctrica ⚡

Ya tenía los discos listos, pero el ZimaBlade viene por defecto con un cable propietario que únicamente permite conectar 2 unidades. Como mi meta era llegar a 5 discos, me pedí una tarjeta de expansión PCIe SATA de 4 puertos, exactamente esta.

Con los datos resueltos, faltaba alimentar esos 5 discos: 1 disco estaría conectado directamente al ZimaBlade usando su cable SATA en Y propietario (que le suministra tanto datos como energía desde su puerto integrado), mientras que los otros 4 requerían alimentación separada.

Mucho cuidado con el cable propietario de ZimaSpace Si vas a armar este setup: este bendito cable es totalmente propietario; no existe (o al menos tras buscar bastante no encontré) ninguna versión genérica compatible en el mercado.

Pero lo más delicado es que el conector se desconecta con demasiada facilidad ante cualquier movimiento involuntario. Me pasó infinidad de veces que el RAID iniciaba degradado o fallaba directamente porque al acomodarlo se había soltado ese disco. Y como en este setup el puerto no admite conexión en caliente (hot-plug ni plug & play), toca apagar el NAS por completo, encajarlo de nuevo con sumo cuidado y volver a encender.

Para alimentar los otros 4 discos me compré este cable divisor de alimentación SATA.

Aquí vino el tropiezo en el que no pensé al comprar el cable: ese conector viene preparado para recibir 12V y cuenta con una cajita interna que hace una conversión reductora (buck converter) de 12V a 5V. El problema es que yo compré una fuente de poder que ya entregaba directamente 5V regulados, por lo que no funcionaba. ¿La solución? Me tocó abrir la cajita negra que se ve en la foto y hacerle un puente directo (bypass) a la línea de 5V hacia los conectores SATA de los discos.

Dimensionamiento de la Fuente de Poder

Con la fuente de poder había que ser muy cuidadoso con el amperaje. Con el voltaje es sencillo: los discos de 2.5” solo piden 5V. Sin embargo, investigando para calcular el amperaje adecuado encontré que cada disco consume entre 0.8A y 1A en el instante de mayor exigencia.

Haciendo números:

• 4 discos arrancando al mismo tiempo pueden demandar: 4 × 1.0 A = 4.0 A.
• Para no tener la fuente trabajando al 100% de su capacidad y evitar sobrecalentamientos prematuros, la recomendación es dejar al menos 1A extra de margen.

Por eso me decidí por este adaptador de corriente AC a DC de 5V a 5A, garantizando estabilidad total sin caídas de tensión.

Consideraciones Térmicas en el ZimaBlade 🌡️

Si bien el ZimaBlade aguanta operaciones de cómputo razonablemente exigentes y puedes reproducir tu biblioteca multimedia sin problemas en Jellyfin, que se encarga de la transcodificación de vídeo por hardware, una operación que consume mucha CPU, al depender de refrigeración pasiva se calienta un montón y bastante rápido.

A esto hay que sumarle que, a diferencia de mi NAS anterior donde usaba SSDs, los discos mecánicos generan calor constante. Tener 5 discos mecánicos juntos irradiando calor cerca de un procesador pasivo hacía que ponerle refrigeración activa fuera una necesidad indispensable para no acortar la vida útil del hardware.

Refrigerando el NAS con Tuya y un poco de código ❄️

Para enfriarlo no quería tener un ventilador soplando al 100% todo el día consumiendo más energía eléctrica de lo necesario. Lo que hice fue comprarme un enchufe inteligente compatible con el ecosistema Tuya, reciclar un fan cooler de PC de 12V que tenía guardado (que suelen consumir apenas unos 0.2A / 2.5W) y conectarlo a un pequeño transformador de 12V enchufado a la toma inteligente.

Para automatizarlo programé este servicio que se ejecuta dentro de un contenedor de Docker: cooler-tuya-monitor.

¿Cómo funciona?

El servicio monitorea continuamente tanto la temperatura del procesador como la de cada uno de los 5 discos duros:

1. Disparo por umbral: Estableces una temperatura máxima segura. Cuando cualquier componente la alcanza, el servicio manda la orden a la API de Tuya y enciende el ventilador.
2. Margen de tolerancia (para evitar encendidos y apagados constantes): Para que el ventilador no esté prendiéndose y apagándose a cada minuto por un cambio de un solo grado, el script lo mantiene encendido por un mínimo de 5 minutos continuos o hasta que la temperatura baje al umbral mínimo establecido.
3. Control manual: También le integré endpoints para poder forzar el encendido o apagado del ventilador vía peticiones HTTP si quiero activarlo manualmente.

Registro de temperatura en mi sistema: puedes observar con claridad los picos (cuando los sensores alcanzan el umbral y se dispara la automatización) y los valles (el descenso de la temperatura donde el ventilador se apaga tras cumplirse el margen de tolerancia).

Si quieres probarlo en tu montaje vas a necesitar las API keys de la plataforma de desarrolladores de Tuya, todo el proceso está bien explicadito en el README del repositorio para que puedas checarlo.

Conclusiones y Próximos Pasos 🚀

Así termina esta pequeña aventura agregando el ZimaBlade a mi homelab existente. Resolver los dolores de cabeza de los cables, puentear el reductor de voltaje y sincronizar la temperatura con un script casero es exactamente lo que hace entretenido el mundo del self-hosting.

Como pendiente a futuro, la idea definitiva sería diseñarle e imprimirle un case en 3D para tener todo el conjunto bien protegido y no tan expuesto al aire libre. Pero siendo honesto, todavía no cuento con las habilidades de modelado 3D necesarias para diseñarlo a medida, así que queda como un reto de aprendizaje para una próxima etapa del proyecto.

¿Te animarías a armar un NAS así de artesanal para tu homelab o prefieres irte por lo seguro con un equipo comercial cerrado tipo Synology?