El verano cambia bastante la forma en la que miro el homelab. En invierno un servidor que consume 40 o 60 W parece casi inocente. Hace algo de calor, sí, pero hasta se perdona. En julio, con la habitación ya caliente, cada vatio deja de ser una cifra simpática en un enchufe inteligente y empieza a convertirse en ruido, temperatura y aire acondicionado trabajando de más.
Ahí es donde aparece la tentación de apagar cosas. Nodos Proxmox, mini PCs de laboratorio, discos que no se usan, máquinas de pruebas, servicios duplicados. La idea suena bien. Menos consumo, menos calor, menos ruido. Pero en un homelab real no todo lo que está encendido es igual de prescindible. Y apagar sin pensar puede ahorrar dos euros mientras te deja sin DNS, sin copias, sin domótica o sin el servicio que alguien en casa sí usa.
Yo lo separo en dos preguntas muy simples:
- ¿Cuánto consumo estoy quitando de verdad?
- ¿Qué riesgo o molestia compro a cambio?
Si la primera respuesta es pequeña y la segunda es grande, no merece la pena. Si apago un nodo que gasta bastante, no tiene dependencias críticas y encima calienta una habitación, entonces sí. Ahí hay ahorro real.
La trampa de mirar solo los vatios#
Medir consumo es fácil. Interpretarlo ya cuesta más.
Un mini PC moderno con Proxmox puede estar entre 8 y 25 W en reposo si va limpio, con pocos discos y sin cargas raras. Un NAS con varios discos de 3,5 pulgadas puede moverse bastante más arriba. Un servidor grande, aunque esté “sin hacer nada”, puede consumir lo suficiente como para que se note en la factura y en la temperatura de la habitación.
Pero el dato suelto engaña. No es lo mismo apagar un nodo de 18 W que no hace nada que apagar un NAS de 55 W donde viven backups, fotos, documentos y media familiar. El primero es un candidato claro. El segundo igual consume más, pero también sostiene más cosas.
La cuenta básica es esta:
| |
Un equipo que consume 20 W constantes gasta unos 14,4 kWh al mes. Con un precio de 0,20 euros por kWh, hablamos de 2,88 euros al mes. No es cero, pero tampoco es una ruina.
Un equipo de 80 W constantes ya son 57,6 kWh al mes. A 0,20 euros, son 11,52 euros. Y en verano hay que sumar el calor que luego quizá paga el aire acondicionado. Ese segundo caso sí empieza a pedirme una decisión.
La diferencia importante no es solo electricidad. Es calor acumulado. Cuatro equipos pequeños pueden parecer eficientes por separado, pero juntos convierten un despacho en un armario de comunicaciones con aspiraciones tropicales.
Mi primera clasificación: núcleo, soporte y laboratorio#
Antes de apagar nada, separaría el homelab en tres grupos.
Núcleo#
Aquí meto lo que no quiero romper en una casa normal:
- DNS o resolución básica de red.
- Internet y firewall.
- Domótica que afecta a luces, enchufes o rutinas familiares.
- Backups importantes.
- Almacenamiento de fotos y documentos.
- Monitorización mínima.
- Algún servicio que otra persona usa sin saber que depende del homelab.
Este grupo no lo optimizo a lo loco. Si algo del núcleo consume demasiado, la respuesta no suele ser apagarlo cada noche. La respuesta es rediseñarlo, moverlo a hardware más eficiente o reducir dependencias.
Soporte#
Aquí pongo servicios útiles pero no dramáticos:
- Dashboards.
- Automatizaciones no críticas.
- Servidores de desarrollo.
- Réplicas cómodas.
- Herramientas internas.
- Reverse proxies secundarios.
- Servicios que uso yo, pero no la familia.
Este grupo admite horarios, apagados y simplificación. Si un servicio de soporte se cae y nadie se entera hasta mañana, probablemente puede vivir en una máquina que no esté 24/7.
Laboratorio#
Aquí vive el cacharreo:
- Nodos de pruebas.
- Kubernetes experimental.
- VMs para probar software.
- Benchmarks.
- Servicios candidatos.
- Máquinas que existen porque un domingo me pareció buena idea.
Este grupo debería apagarse sin culpa. Si no puedes apagar tu laboratorio sin romper la casa, no tienes laboratorio. Tienes producción disfrazada con una pegatina de “test”.
El verano castiga más a los discos que a los mini PCs#
En mi experiencia, los mini PCs modernos suelen ser bastante agradecidos. Consumen poco, hacen poco ruido y se pueden colocar mejor. Los discos son otra historia.
Un disco mecánico no solo consume. También vibra, calienta, tarda en arrancar, sufre con ciclos de encendido si abusas y suele vivir en cajas menos silenciosas. Un NAS con varios discos puede ser el punto caliente del homelab aunque la CPU esté aburrida.
Por eso no me obsesionaría con apagar y encender discos cada dos horas. Prefiero decidir qué almacenamiento tiene que estar siempre disponible y cuál puede ser frío o semi frío.
Ejemplo práctico:
- Fotos familiares recientes: disponibilidad alta y backup claro.
- Media que se puede volver a conseguir: disponibilidad media.
- Backups históricos cifrados: disponibilidad baja, protección alta.
- ISOs, dumps temporales y descargas: disponibilidad baja y poca pena.
El error típico es meterlo todo en el mismo volumen siempre encendido. Así acabas pagando calor por datos que no necesitas calientes.
Una mejora más sensata puede ser mover datos fríos a discos que no estén 24/7, o a un NAS que se despierte bajo demanda, antes que apagar el servidor principal sin mirar dependencias.
Cuándo sí apagaría nodos#
Hay casos donde apagar nodos me parece claramente correcto.
Nodos de cluster que no aportan quorum necesario#
Si tienes un cluster Proxmox o Kubernetes con nodos de más para laboratorio, no todos tienen que estar encendidos en verano. La condición es no romper quorum, almacenamiento, HA ni servicios que dependan de afinidad rara.
En un cluster pequeño, apagar un nodo puede ser trivial o puede ser una mala idea. Depende de cómo estén repartidos los votos, dónde viva el almacenamiento y si has colocado servicios críticos como si nunca fuese a fallar nada.
Aquí enlaza con algo que ya conté en mapa de dependencias en un homelab. No basta con saber qué máquina apagas. Tienes que saber qué se cae con ella.
Máquinas de pruebas que no tienen datos importantes#
Esto debería ser lo más fácil. Si una VM de laboratorio no tiene datos relevantes y no presta servicio a nadie, apagada. Si hace falta mañana, se arranca. Si tarda tres minutos, no pasa nada. Peor es tenerla tres meses consumiendo por pura inercia.
Hardware grande usado como si fuera pequeño#
Este es el caso que más duele. Un servidor potente puede ser maravilloso para IA local, transcodificación, laboratorios pesados o almacenamiento serio. Pero si está encendido 24/7 para correr dos contenedores ligeros, algo chirría.
No digo que haya que apagar siempre el hierro grande. Digo que hay que ser consciente. Si un equipo de alto consumo está siempre encendido, tiene que justificarlo con cargas que realmente lo necesiten.
Servicios que pueden agruparse en menos nodos#
En verano me gusta compactar. No por obsesión minimalista, sino porque muchos homelabs crecen por sedimentación. Un servicio aquí, otro allí, una VM que nació para una prueba y ahora tiene un contenedor útil dentro.
Compactar servicios pequeños en uno o dos nodos eficientes puede permitir apagar máquinas enteras. Ese ahorro sí se nota más que pelear por tres vatios en una BIOS.
Cuándo no merece la pena apagar#
También hay apagados que parecen listos y no lo son.
Si el ahorro mensual es ridículo#
Apagar un mini PC de 10 W durante 8 horas al día ahorra unos 2,4 kWh al mes. A 0,20 euros, son 48 céntimos. Si ese apagado complica backups, monitorización o arranques, no me interesa.
Hay optimizaciones que solo sirven para sentir que has hecho algo. El homelab ya consume bastante energía mental. No necesito añadir rituales por céntimos.
Si el arranque no es fiable#
Un equipo que no siempre vuelve solo, no se apaga automáticamente. Punto.
Puede ser una BIOS caprichosa, un disco viejo, una dependencia de red, un servicio que necesita orden concreto o una VM que a veces se queda tonta. Si requiere intervención manual, no lo metería en una política de apagado programado.
Antes de automatizar apagados, probaría varias veces:
- Apagar.
- Encender.
- Esperar.
- Validar servicios.
- Confirmar alertas limpias.
Si falla una de cada diez, fallará el día que estés fuera.
Si rompe backups nocturnos#
Muchos backups se ejecutan de noche por comodidad. Si apagas nodos justo cuando deberían copiar, verificar o replicar, estás ahorrando electricidad a costa de seguridad.
La solución no es mantener todo encendido siempre. La solución es ordenar horarios. Primero backup, luego verificación, luego apagado si procede.
Si dependes de ese nodo para DNS o red#
Parece obvio hasta que pasa. Si un nodo lleva DNS, DHCP, firewall, controlador WiFi o algo que afecta a la conectividad, no se apaga como si fuera una VM de pruebas.
Para eso prefiero tener un plan B si cae el DNS de casa y mantener las piezas básicas en hardware muy eficiente.
Lo que haría en una casa normal#
Si tuviese que diseñar una política de verano sin complicarme, sería esta.
1. Medir una semana, no una tarde#
Un enchufe inteligente con medición ya vale para empezar. No necesito precisión de laboratorio. Necesito saber consumos medios, picos y qué equipos están claramente fuera de escala.
Mediría:
- Router, firewall y switches.
- NAS.
- Nodo principal de virtualización.
- Nodos secundarios.
- Servidor grande si existe.
- UPS si muestra carga.
Una tarde no basta porque hay backups, scrubs, transcodificación, indexaciones y tareas nocturnas. Una semana da una foto más honesta.
2. Identificar candidatos por impacto#
No empezaría por el equipo más fácil de apagar. Empezaría por el que combine:
- Consumo alto.
- Calor perceptible.
- Baja criticidad.
- Arranque fiable.
- Pocas dependencias.
Ese es el candidato bueno.
3. Compactar antes de automatizar#
Antes de montar automatizaciones, movería servicios pequeños a un nodo eficiente. Si puedo apagar dos máquinas porque he ordenado diez contenedores, mejor que crear un sistema de apagado nocturno lleno de excepciones.
La automatización buena simplifica. La mala convierte tu casa en una sala de máquinas con horario laboral.
4. Dejar un núcleo mínimo siempre encendido#
Mi núcleo mínimo sería:
- Red básica.
- DNS con fallback.
- Almacenamiento crítico o al menos acceso a datos importantes.
- Backups según horario.
- Monitorización simple.
- Domótica que afecte a convivencia.
Ese núcleo debería consumir poco. Si no consume poco, miraría hardware, no solo horarios.
5. Apagar laboratorio por defecto#
El laboratorio debería estar apagado salvo que lo esté usando. Esto cambia mucho la mentalidad. En vez de “todo encendido por si acaso”, paso a “enciende cuando haga falta”.
Wake-on-LAN, IPMI, enchufes inteligentes o acceso por VPN pueden ayudar, pero no hace falta hacerlo perfecto desde el primer día. Con apagar manualmente lo que no usas ya ganas bastante.
El aire acondicionado también cuenta#
Hay un detalle que se suele olvidar: el calor del homelab no desaparece. Si está dentro de casa, acaba calentando una habitación. En invierno puede importar poco. En verano puede hacer que el aire acondicionado trabaje más.
No hago una cuenta exacta porque depende de la casa, orientación, aislamiento y hábitos. Pero sí uso una regla práctica: si un equipo calienta una habitación de forma perceptible, su coste real no es solo el enchufe. También es comodidad.
Ahí los servidores grandes pierden puntos. No porque sean malos, sino porque en verano se notan. Un mini PC de bajo consumo puede pasar desapercibido. Un servidor con varios discos, ventiladores y fuente grande no.
También importa dónde está. Un equipo en un trastero ventilado molesta menos que uno bajo la mesa del despacho. El mismo consumo puede ser aceptable o absurdo según ubicación.
Mi política personal#
La política que más me gusta es aburrida:
- Núcleo eficiente siempre encendido.
- NAS encendido si guarda datos activos o backups frecuentes.
- Servidor grande solo cuando la carga lo justifica.
- Nodos de laboratorio apagados por defecto.
- Backups y verificaciones antes que ahorro agresivo.
- Medición mensual para detectar deriva.
No intento llevar el homelab a consumo cero. Sería absurdo. Si quiero servicios locales, independencia y cacharreo, pago una parte en electricidad. Lo que no quiero es pagar por máquinas encendidas por pereza.
La pereza en homelab tiene una factura curiosa. Primero pagas vatios. Luego pagas calor. Luego pagas complejidad porque ya no sabes qué hace cada cosa.
Señales de que toca actuar#
Hay varias señales claras:
- La habitación del homelab está siempre más caliente que el resto.
- No sabes por qué un equipo está encendido.
- Hay VMs sin uso desde hace semanas.
- Un servidor grande hace trabajo de mini PC.
- Los backups dependen de máquinas repartidas sin sentido.
- El ruido te molesta más en verano.
- El consumo base de casa es alto incluso de noche.
Con dos o tres de esas señales, no hace falta una auditoría perfecta. Hace falta ordenar.
Lo que no haría#
No apagaría discos críticos cada pocas horas para arañar céntimos. No pondría DNS, DHCP o domótica en una máquina que se duerme sola. No automatizaría apagados sin validar arranques. No confiaría en que “ya me acordaré” de encender algo antes del backup.
Tampoco montaría una arquitectura HA carísima para ahorrar electricidad. Alta disponibilidad y ahorro agresivo tiran en direcciones distintas. Se puede encontrar equilibrio, pero no conviene mentirse.
Si algo tiene que estar siempre disponible, debe estar en hardware eficiente y simple. Si algo es laboratorio, debe poder apagarse. El problema aparece cuando mezclas ambos mundos.
Conclusión#
Apagar nodos en verano puede tener mucho sentido, pero no como reflejo automático. Primero hay que medir, separar servicios y entender dependencias. Después sí, apagar lo que sobra.
Mi regla final sería esta: si apagar un equipo ahorra calor y dinero sin afectar a la casa, adelante. Si el ahorro es pequeño y la complejidad sube, déjalo encendido o rediseña mejor.
Un homelab sano no es el que menos consume a cualquier precio. Es el que consume de forma consciente. Y en verano, esa conciencia se agradece bastante cuando entras en el despacho y no parece que haya un NAS intentando incubar huevos.