Hay una pregunta que parece tonta hasta que te vas de vacaciones: ¿qué puedo apagar del homelab sin dejar la casa coja?
Cuando estás en casa, todo parece fácil. Si un nodo se queda raro, lo miras. Si un contenedor no arranca, entras por SSH. Si Home Assistant decide ponerse dramático, tienes el rack a unos metros y puedes tocar botones físicos con cara de resignación. En vacaciones la cosa cambia. Estás lejos, quizá con mala conexión, quizá con familia esperando, y lo último que quieres es pelearte con un servicio interno porque intentaste ahorrar diez euros de luz apagando justo la pieza equivocada.
Yo no creo que haya que dejar todo encendido por miedo. Tampoco creo que haya que apagarlo todo por postureo eficiente. La estrategia buena está en medio: dejar vivo lo que permite recuperar, apagar lo que solo consume y llegar a casa sin una lista de servicios enfadados.
En mi caso separo el homelab en tres grupos antes de irme:
- lo que debe seguir funcionando
- lo que puede quedar congelado
- lo que se apaga sin remordimiento
La gracia no está en la lista. Está en aceptar que algunos servicios que parecen importantes solo lo son cuando estoy en casa trasteando.
Lo primero: qué usa la casa cuando no estoy#
Antes de apagar nada, pienso en uso real. No en arquitectura. No en lo bonito que queda el diagrama. Uso real.
Si nadie va a estar en casa, muchos servicios pierden importancia. Un panel de domótica muy bonito no sirve de mucho si no hay nadie usando luces, sensores o climatización. Un servidor multimedia tampoco importa si no voy a verlo desde fuera. Un entorno de pruebas, menos todavía.
Pero hay cosas que sí pueden importar aunque la casa esté vacía:
- cámaras o sensores si los usas para seguridad
- acceso remoto privado para entrar si algo falla
- DNS o red si hay dispositivos que siguen conectados
- copias pendientes antes de salir
- automatizaciones de presencia, luces o riego si existen
- monitorización básica para saber si se ha ido la luz
Esta lista cambia según la casa. En una vivienda sin cámaras ni automatizaciones, apagar más cosas es fácil. En una casa donde Home Assistant controla rutinas, enchufes o alertas, hay que ir con más cuidado. La domótica deja de ser juguete cuando alguien espera que funcione.
Mi regla es sencilla: si un servicio puede evitar un problema real mientras estoy fuera, se queda. Si solo alimenta mi curiosidad, se apaga.
El acceso remoto no se toca a ciegas#
El acceso remoto es la pieza que más respeto merece. Si te equivocas con esto, el resto del plan se convierte en fe.
Yo quiero poder entrar desde fuera por una ruta que no dependa de medio laboratorio. Puede ser Tailscale, WireGuard, una VPN en el router o una combinación razonable. Lo importante es que el camino de entrada viva en una máquina estable y de bajo consumo, no en el nodo más experimental de la casa.
La tentación es dejarlo todo precioso: DNS interno, reverse proxy, certificados, SSO, paneles, monitorización y nombres cómodos. Perfecto cuando estás en casa. En vacaciones prefiero una ruta más básica, incluso un poco fea, pero que aguante.
Mi acceso mínimo tendría:
- una VPN privada funcionando antes de salir
- autenticación fuerte
- una segunda forma de comprobar si la red vive
- documentación breve de cómo entrar
- nada crítico dependiendo de un contenedor que actualizo cada dos semanas
No abriría puertos nuevos antes de un viaje. Tampoco tocaría reglas de firewall el día anterior. Si algo no está probado, no entra en el plan de vacaciones. Las vacaciones no son una ventana de mantenimiento encubierta, aunque todos hayamos sentido esa tentación absurda alguna vez.
DNS: el asesino silencioso del plan#
El DNS interno parece pequeño hasta que cae. Luego descubres que no abre nada, que las apps no encuentran servicios, que el móvil se queda pensando y que tú estás en una cafetería intentando recordar si el resolver principal vivía en el nodo que acabas de apagar.
Para irme tranquilo, el DNS debe tener una degradación aceptable. Si uso Pi-hole o AdGuard Home, quiero dos opciones:
- dos resolvers internos en máquinas distintas
- o un fallback externo entregado por el router si el homelab no responde
No hace falta que todo siga resolviendo nombres internos perfectos mientras estoy fuera. Pero internet básico debería sobrevivir. Si hay dispositivos en casa que necesitan salir, no quiero que dependan de un contenedor apagado.
También reviso DHCP. Muchas redes domésticas tienen el router dando DHCP, lo cual simplifica mucho. Si el DHCP vive en un servicio self-hosted, el plan de apagado tiene que tratarlo como crítico. No lo pondría en una máquina que voy a apagar, por obvio que suene. Hay obviedades que solo duelen cuando las incumples.
El DNS sano en vacaciones es aburrido: poco elegante, pocas dependencias y un camino de salida aunque el homelab esté medio dormido.
Backups antes de salir, no durante el viaje#
Antes de apagar nodos, hago una foto mental de los datos. No me refiero a snapshots solamente. Me refiero a si las copias importantes han terminado y si puedo restaurar lo esencial sin depender del equipo que voy a apagar.
Los backups que me importan antes de vacaciones son:
- fotos y vídeos familiares
- documentos
- configuraciones de servicios críticos
- bases de datos pequeñas pero importantes
- exportaciones de Home Assistant si lo uso como servicio serio
- inventario de VMs y contenedores
Lo que no quiero es salir de casa justo después de una migración, con backups a medias y un montón de cambios pendientes. Eso es pedirle emoción al destino, y el destino suele tener mal gusto.
Mi criterio es que el último backup bueno debe existir antes de apagar. Si un servicio se queda congelado durante unos días, perfecto. Si algo importante genera datos nuevos mientras estoy fuera, entonces ese servicio no debería quedar sin copia. En muchos casos la respuesta fácil es no generar datos nuevos. Parar ingestión, pausar tareas, cerrar automatizaciones no esenciales y dejar el sistema quieto.
Hay un tipo de tranquilidad que solo aparece cuando sabes que, si todo se quema metafóricamente, puedes volver a montar lo importante. No es poesía. Es una restauración probada.
Qué apagaría sin remordimiento#
La lista de cosas apagables suele ser más larga de lo que nos gusta admitir.
Yo apagaría sin sufrir:
- nodos de laboratorio
- clusters de pruebas
- GPUs que no estén haciendo nada útil
- servicios de IA locales para experimentos
- entornos de CI caseros si no voy a desplegar
- servidores multimedia si no voy a usarlos
- réplicas no críticas que puedo resincronizar al volver
- dashboards pesados que solo miro por vicio
El homelab tiende a acumular servicios con pinta de importantes. Luego miras logs de acceso y ves que llevan dos semanas sin una visita humana. Si un servicio no lo usa nadie y no protege nada, probablemente puede apagarse.
Aquí el consumo manda bastante. Un mini PC moderno quizá consume poco, pero varios nodos, discos, switches, ventiladores, fuentes y GPUs suman. En verano además está el calor. Todo lo que dejas encendido se convierte en electricidad y temperatura. Si nadie va a aprovecharlo, apagarlo tiene sentido.
Lo que no haría es apagar cosas que luego obligan a una coreografía delicada para volver. Si un nodo tarda diez pasos en entrar limpio porque depende de almacenamiento remoto, DNS interno y un script olvidado, quizá lo dejo encendido hasta que tenga una rutina mejor. Apagar también debe ser operable.
Qué dejaría encendido#
Mi conjunto mínimo para vacaciones sería pequeño.
Dejaría encendido:
- router y switch principal
- WiFi si hay dispositivos que deben seguir conectados
- una máquina de acceso remoto
- DNS básico o fallback fiable
- almacenamiento si recibe datos importantes
- monitorización ligera
- domótica crítica, si la casa depende de ella
No tiene por qué ser una torre enorme. De hecho, mejor si no lo es. Idealmente el núcleo de vacaciones vive en un equipo de bajo consumo y pocas piezas móviles. Un mini PC sobrio, una Raspberry Pi decente o el propio router si tiene VPN fiable pueden ser mejores que un servidor grande haciendo de navaja suiza.
La monitorización ligera me vale con algo simple. Quiero saber si la casa tiene internet, si la VPN responde y si la máquina mínima está viva. No necesito un stack entero de observabilidad para mirar tres señales. Si la monitorización consume más atención que el problema que vigila, algo se ha ido de madre.
También me gusta tener un enchufe inteligente o PDU para reiniciar alguna pieza concreta, pero con cuidado. Si el enchufe inteligente depende del WiFi que depende del router que quieres reiniciar, acabas creando una broma circular. Para reinicios remotos, la cadena de dependencias importa muchísimo.
El orden de apagado#
No apago al azar. Apago desde fuera hacia dentro.
Primero paro servicios de laboratorio. Luego contenedores o VMs no críticas. Después nodos secundarios. Lo último que tocaría sería acceso remoto, DNS, almacenamiento y red.
Antes de apagar un nodo, miro qué corre ahí. No por CPU ni RAM, sino por dependencia. A veces una VM pequeña sostiene más de lo que parece: un resolver DNS, un reverse proxy interno, una base de datos compartida, una tarea cron que actualiza algo importante.
Me gusta hacer una comprobación simple:
- ¿qué servicios dejarán de responder?
- ¿hay otra ruta para entrar?
- ¿queda internet funcionando?
- ¿los backups ya terminaron?
- ¿alguien en casa depende de esto?
Si no puedo responder rápido, no apago todavía. Esa duda es información. Significa que el inventario no está claro.
El apagado bueno no debería sentirse como una apuesta. Debería sentirse como cerrar habitaciones que no vas a usar.
El plan de vuelta#
La vuelta también cuenta. Encender todo de golpe puede funcionar, pero no es mi opción favorita. Prefiero levantar por capas:
- red y almacenamiento
- nodo principal
- servicios críticos
- laboratorio
- tareas pesadas
Después reviso backups, actualizaciones pendientes y alertas acumuladas. Si hubo cortes de luz, miro discos. Si hubo calor fuerte, miro temperaturas. Si algún servicio quedó desactualizado, no lo actualizo todo el primer día de vuelta con la maleta aún en medio del pasillo. Esa impaciencia rompe cosas.
También anoto qué sobró. Si apagué un nodo dos semanas y nadie lo echó de menos, quizá ese nodo no era tan necesario. Vacaciones sirven como auditoría brutal del homelab. Lo que sobrevive apagado sin consecuencias quizá debería estar apagado más a menudo.
Me parece una prueba sana: si un servicio puede estar fuera quince días y no pasa nada, igual no necesita estar 24/7.
Mi plantilla rápida antes de irme#
La checklist que usaría sería esta:
- confirmar último backup bueno
- probar VPN desde fuera de la WiFi de casa
- comprobar que DNS tiene fallback
- revisar qué corre en cada nodo que voy a apagar
- pausar automatizaciones no esenciales
- dejar documentación mínima de acceso
- apagar laboratorio y cargas pesadas
- verificar desde móvil que puedo entrar al núcleo
- dejar una alerta simple de caída de internet o nodo mínimo
No es sofisticada. Precisamente por eso funciona.
El homelab en vacaciones tiene que ser más pequeño, más quieto y más predecible. La mejor arquitectura para esos días no es la más impresionante. Es la que me permite olvidarme de ella sin tener la sensación de haber dejado una bomba técnica encendida en casa.
Apagar parte del homelab no va solo de ahorrar luz. Va de saber qué has construido. Si no sabes qué puedes apagar, no tienes un homelab. Tienes una caja de dependencias con ventiladores.