Un SAI es una de esas compras poco emocionantes que empiezas a valorar cuando ya te ha hecho falta. Nadie monta un homelab porque sueñe con baterías de plomo, pitidos y cables USB raros. Montas un homelab porque quieres servicios, datos, máquinas, automatizaciones y cierto control sobre tu casa digital. Luego llega un corte de luz de dos segundos y descubres que todo ese montaje tan elegante depende de una regleta bastante humilde.
Mi forma de verlo ha cambiado con el tiempo. Antes pensaba en el SAI como una batería para aguantar encendido. Ahora lo veo como una pieza de operación: me da unos minutos para que el NAS termine escrituras, las bases de datos cierren bien, las VMs se apaguen en orden y el router no desaparezca justo cuando necesito entrar a mirar qué ha pasado.
Este artículo encaja en la ruta de datos y copias de seguridad y también en operación y monitorización. Si ya has pensado en el coste real de tener un homelab encendido todo el día o en qué monitorizar antes de mirar CPU y RAM, el SAI es una pieza natural del mismo asunto: menos brillo, más supervivencia.
Qué espero de un SAI en casa#
La expectativa sana es bastante modesta: aguantar cortes cortos y permitir apagado limpio en cortes largos.
No espero mantener todo el homelab funcionando una hora. No espero que un clúster Proxmox siga feliz mientras media calle está sin luz. No espero salvar una sesión de juego, una transcodificación pesada o una prueba de IA local. Para eso harían falta baterías más grandes, más dinero, más calor y más mantenimiento.
Lo que sí espero:
- Que el router, el switch principal y el DNS aguanten microcortes.
- Que el NAS no pierda escrituras a medias.
- Que las VMs o contenedores importantes se apaguen con orden.
- Que haya una señal clara de batería baja.
- Que el sistema vuelva de forma razonable cuando regrese la corriente.
Ese último punto se olvida mucho. Un apagado limpio vale menos si luego todo vuelve en un orden absurdo y el servicio crítico depende de una base de datos que todavía no ha arrancado. El SAI compra tiempo. La arquitectura sigue teniendo que estar pensada.
Qué conectaría y qué dejaría fuera#
El error típico es enchufar al SAI todo lo que hay cerca. Total, tiene tomas libres. Mala idea. Cada aparato reduce autonomía y algunos consumen justo cuando menos conviene.
Yo priorizaría así:
- Router o firewall.
- Switch principal.
- NAS o servidor de almacenamiento.
- Nodo principal de servicios.
- Equipo que coordina apagado, si no coincide con el NAS.
Después miraría con mucha más frialdad el resto.
No pondría monitores, impresoras, altavoces, cargadores, lámparas, equipos de pruebas ni mini PCs de laboratorio que no guarden nada importante. Tampoco pondría una impresora láser en un SAI pequeño. El pico de consumo de una láser puede ser bastante antipático para una batería doméstica.
Si tengo varios nodos, no todos merecen batería. A veces es mejor proteger almacenamiento, red y control, y dejar que el laboratorio caiga. Un nodo de pruebas apagado de golpe molesta. Un NAS escribiendo fotos familiares o una base de datos de documentos cortada a mitad de operación me preocupa más.
Aquí ayuda el enfoque del mapa de dependencias del homelab. Antes de decidir qué entra en el SAI, pregunto qué se cae si apago cada cosa. La respuesta suele ser más útil que mirar vatios sin contexto.
VA, vatios y la trampa del número grande#
Los SAI se venden muchas veces por VA, pero a mí me importa mucho el límite en vatios. No son lo mismo. Fuji Electric explica en su guía de dimensionamiento que la potencia en vatios se obtiene multiplicando los voltamperios por el factor de potencia. En cristiano: un SAI de 900 VA no significa necesariamente 900 W útiles.
Esto importa porque un homelab real tiene cargas pequeñas, pero sostenidas. Un NAS con discos, un mini PC, un router y un switch quizá consumen menos de lo que parece. Pero si compras sin mirar vatios, puedes acabar con un SAI que en papel parece grande y en la práctica va más justo de lo esperado.
Mi cálculo inicial sería:
- Medir consumo real si puedo, no estimarlo a ojo.
- Sumar router, switch, NAS y servidores protegidos.
- Añadir margen para picos.
- Mirar la autonomía a esa carga, no la autonomía de catálogo con una carga ideal.
Ejemplo sencillo:
| |
Con esa carga no busco una hora. Busco que, si se va la luz durante cinco minutos, no pase nada. Y si se va más tiempo, que el apagado empiece pronto y termine antes de que la batería esté al límite.
Eaton tiene una herramienta de selección por carga que sirve como orientación, y muchos fabricantes publican curvas de autonomía por modelo. Para comprar, confiaría más en esas curvas que en una regla mental demasiado optimista.
La autonomía que quiero#
Para casa, mi objetivo razonable serían entre 10 y 20 minutos a la carga real. Menos puede quedarse corto para apagados con varias máquinas. Más está bien si el presupuesto y el espacio lo permiten, pero no lo convertiría en obsesión.
La autonomía útil depende de tres cosas:
- Cuánto tarda el sistema en detectar el corte.
- Cuánto tiempo quieres esperar por si vuelve la corriente.
- Cuánto tarda el apagado ordenado.
Si configuras el apagado cuando queda un 5% de batería, vas tarde. La batería vieja no se comporta como nueva. La estimación de runtime puede equivocarse. Y algunas máquinas tardan más en apagar cuando justo están haciendo trabajos de disco.
Yo prefiero una política conservadora:
- Cortes de pocos segundos: aguantar.
- Cortes de varios minutos: empezar a preparar apagado.
- Batería baja: apagar ya.
Para servicios familiares, documentos o fotos, no quiero exprimir la batería. Quiero terminar bien.
NAS como centro de apagado#
Si tienes un NAS tipo Synology o un servidor siempre encendido, puede ser el candidato natural para hablar con el SAI por USB. Synology documenta el soporte UPS en DSM y permite que un NAS actúe como servidor UPS para otros equipos de la red. Es una forma cómoda de evitar que cada máquina necesite conexión directa al SAI.
El patrón sería:
| |
El NAS detecta batería, comunica estado y ordena apagado cuando toca. Otros equipos escuchan esa señal y ejecutan su propia parada.
Esto me gusta porque el NAS suele ser el equipo con datos más sensibles. Si él sabe que la batería cae, puede entrar en modo seguro o apagarse antes de agotar el margen. Pero no lo dejaría sin probar. Que el panel tenga una casilla marcada no significa que toda la cadena funcione.
También hay un matiz importante: si el NAS se apaga muy pronto y era quien avisaba al resto, los demás pueden quedarse sin coordinador. Por eso el diseño tiene que probarse entero. Primero quién avisa. Luego quién apaga. Luego qué queda encendido hasta el final.
NUT para varios equipos#
Network UPS Tools, conocido como NUT, es la opción clásica cuando quieres que varios sistemas Linux, BSD, NAS o servidores hablen con un SAI. La documentación oficial lo describe como un conjunto de programas que da una interfaz común para monitorizar y administrar dispositivos de energía, incluidos UPS y PDU.
La arquitectura típica tiene tres piezas:
- Driver que habla con el SAI.
- Servicio que expone el estado.
- Clientes que reaccionan a eventos como batería baja.
Para un homelab con varias máquinas, NUT me parece muy útil porque separa la lectura del SAI de la decisión local. Un servidor puede apagar sus VMs. Otro puede parar contenedores. El NAS puede entrar en modo seguro. Cada uno hace lo que necesita, pero todos miran la misma fuente.
La parte importante no es instalar NUT. La parte importante es probar el flujo de apagado. La documentación de NUT insiste en probar la secuencia antes de dejar los sistemas desatendidos. Tiene toda la razón. Un apagado que nunca has probado es otro backup sin restaurar, pero con pitidos.
Mi prueba mínima:
- Ver que el sistema lee estado del SAI.
- Simular o provocar un evento controlado.
- Confirmar que los clientes reciben estado.
- Ver que cada equipo inicia apagado cuando toca.
- Confirmar que el SAI no corta antes de que el sistema termine.
- Comprobar arranque cuando vuelve la corriente.
No hace falta hacer esto cada semana. Sí lo haría al montar, al cambiar el SAI, al cambiar el NAS o al añadir un servidor importante.
Proxmox, VMs y contenedores#
Proxmox merece cuidado porque no estás apagando solo una máquina. Estás apagando un host con cargas dentro.
Si el host recibe aviso de batería baja, quiero que pare VMs y contenedores con orden. Eso implica revisar tiempos de apagado, orden de arranque, servicios críticos y qué máquinas pueden morir antes.
No trataría igual todas las VMs:
- DNS, reverse proxy interno o Home Assistant: apagado con más cuidado.
- Bases de datos y documentos: parada limpia.
- Laboratorio: apagado rápido o caída aceptable.
- Jobs pesados: se cancelan si hace falta.
En Proxmox también miraría si las VMs tienen guest agent cuando aporta valor. Un host puede pedir apagado ordenado, pero la VM tiene que responder. Si una VM ignora la señal, el host acabará forzando. Para una VM sin datos puede valer. Para una base de datos, no me gusta.
Esto conecta con la guía de diagnóstico seguro de VMs y LXC. Apagar bien importa más justo cuando hay presión.
Cuando vuelve la corriente#
El regreso de la corriente puede ser más caótico que el corte.
Si todo arranca a la vez, el NAS despierta, los discos giran, el router negocia, el switch levanta enlaces, Proxmox arranca VMs, contenedores buscan bases de datos, DNS todavía no resuelve y media casa intenta volver al mismo tiempo. En sistemas pequeños suele salir bien. Hasta que no.
Yo intentaría que el arranque tenga un orden razonable:
- Red base.
- Almacenamiento.
- DNS y servicios de infraestructura.
- Bases de datos.
- Aplicaciones.
- Servicios secundarios.
No hace falta automatizarlo con precisión militar. Pero sí conviene evitar que todo dependa de una carrera. Si una app falla porque su base de datos tardó 40 segundos más, quiero que tenga restart policy o una comprobación posterior.
También revisaría qué equipos tienen activado el arranque automático tras volver la luz. En servidores suele ser útil. En equipos de laboratorio quizá no. Un corte de luz no debería encender media colección de pruebas si no aportan nada.
Monitorizar el SAI sin convertirlo en ruido#
El SAI debería avisar de pocas cosas, pero importantes.
Alertas que sí quiero:
- Funcionando en batería.
- Batería baja.
- Batería necesita reemplazo.
- Comunicación perdida con el SAI.
- Carga demasiado alta.
Alertas que no quiero: cada microvariación, cada evento irrelevante o cada cambio de estado que no exige acción. Un sistema de alertas pesado acaba ignorado.
También apuntaría el SAI en el inventario del homelab: modelo, fecha de compra, batería, equipos conectados, carga aproximada y qué máquina lo gestiona. Las baterías envejecen. Si dentro de tres años no sabes cuándo compraste el SAI, vas a tratar una batería cansada como si fuera nueva.
En la ruta de operación y monitorización esta pieza tiene mucho sentido. No mide CPU. Mide cuánto margen tienes antes de que los datos empiecen a depender de la suerte.
Pruebas que haría una vez al año#
Una vez al año haría una prueba controlada. No una gran producción, solo verificar que el sistema sigue sabiendo apagarse.
Mi prueba sería:
- Avisar en casa si afecta a algo usado por más gente.
- Confirmar backups recientes.
- Ver carga actual del SAI.
- Desconectar corriente del SAI durante unos minutos.
- Confirmar alerta.
- Dejar que empiece el procedimiento si toca o simularlo si no quiero apagar.
- Volver a corriente.
- Revisar logs y estado.
Si nunca quieres probarlo porque te da miedo romper algo, ya tienes una señal. Significa que el procedimiento de apagado no inspira confianza. Mejor descubrirlo en una prueba tranquila que durante un corte real.
También comprobaría baterías. Un SAI viejo puede enseñar autonomía optimista y desplomarse cuando recibe carga. Las baterías no avisan con elegancia eterna. En cuanto el SAI empiece a comportarse raro, lo trato como mantenimiento pendiente.
Errores que evitaría#
El primero: comprar solo por VA. Hay que mirar vatios, autonomía a carga real y tipo de batería.
El segundo: conectar demasiadas cosas. El SAI debe proteger lo importante, no alimentar el escritorio entero.
El tercero: esperar demasiado para apagar. Una política conservadora protege mejor que apurar batería.
El cuarto: no probar el apagado. Marcar una casilla en DSM, Proxmox o NUT no es una prueba.
El quinto: olvidar el arranque. Volver de un apagón también es parte del diseño.
El sexto: tratar el SAI como sustituto de backups. Un SAI no protege de borrados, corrupción lógica, ransomware, fallos de disco ni errores humanos. Solo ayuda con energía.
El séptimo: no cambiar baterías. Un SAI con batería muerta es una regleta cara con autoestima.
Mi configuración razonable#
Para una casa con homelab pequeño o medio, dejaría algo así:
- SAI dimensionado para router, switch, NAS y servidor principal.
- Carga normal por debajo del 50 o 60% del límite en vatios.
- USB al NAS o al servidor que actúe como coordinador.
- NUT o servidor UPS del NAS para avisar a otros equipos.
- Apagado automático conservador.
- Prueba anual de funcionamiento.
- Alerta de batería baja y comunicación perdida.
- Nota de operación con orden de apagado y arranque.
Si el homelab crece, quizá añadiría un segundo SAI para separar red y servidores. La red base puede merecer más autonomía que un nodo de cómputo. Mantener router, switch y DNS vivos durante un corte corto puede evitar muchas molestias aunque el laboratorio se apague.
La idea final es simple: el SAI no está para que el homelab presuma. Está para que el homelab se comporte como un adulto cuando la electricidad deja de colaborar.
Fuentes y lecturas útiles#
- Network UPS Tools: descripción general
- Network UPS Tools: notas de configuración y pruebas de apagado
- Synology DSM: soporte UPS
- Eaton UPS Selector
- Fuji Electric: cálculo de dimensionamiento UPS
Un buen SAI no convierte una casa en un centro de datos. Mejor así. Lo que hace es mucho más práctico: da margen para que los datos importantes no dependan de un corte de luz tonto y para que tú no tengas que reconstruir el estado del homelab a base de rezos, logs y café frío.