Hay una diferencia enorme entre tocar un homelab un martes por la noche porque te apetece y tocarlo sabiendo que hay cosas que usa la casa. La primera versión es hobby puro. La segunda ya tiene un punto de responsabilidad, aunque nadie haya firmado un SLA ni exista una hoja de cambio con membrete.
Yo he aprendido esto a base de golpes pequeños. Un cambio de DNS que parecía inocente. Una actualización de contenedores que arranca bien en el panel pero deja una app medio muerta. Una migración de almacenamiento que se alarga porque justo aparece el error que no habías visto en tres años. Nada dramático por separado, pero suficiente para entender que un homelab doméstico necesita ventanas de mantenimiento si sostiene servicios reales.
No hablo de montar una burocracia absurda. En casa no tiene sentido replicar los rituales de una empresa grande. Pero tampoco tiene sentido hacer cambios importantes a ciegas cuando tienes fotos familiares, documentos, domótica, contraseñas, DNS o acceso remoto dependiendo de tus máquinas.
Mi regla es bastante simple: cuanto más invisible es un servicio para la casa, más cuidado merece. Si algo falla y nadie entiende qué has tocado, el problema no es solo técnico. Es que has convertido una comodidad en una dependencia rara.
Qué considero mantenimiento de verdad#
No llamo ventana de mantenimiento a reiniciar un contenedor de pruebas ni a cambiar una variable en una app que solo uso yo. Eso sigue siendo cacharreo.
Para mí una ventana empieza cuando voy a tocar algo que puede afectar a una de estas capas:
- Red base: router, DNS, DHCP, WiFi, firewall, túneles o VPN.
- Datos importantes: fotos, documentos, backups, bases de datos con información real.
- Servicios compartidos: domótica, gestor de contraseñas, apps familiares, multimedia que se usa a diario.
- Infraestructura común: Proxmox, Unraid, NAS, storage compartido, reverse proxy, certificados.
- Monitorización y alertas: lo que me avisa cuando algo va mal.
Si el cambio toca una de esas capas, dejo de improvisar. No porque sea peligroso por definición, sino porque las consecuencias ya no son solo mías.
Esto es especialmente importante en casa porque el contexto suele ser peor que en el trabajo. Muchas veces haces cambios de noche, cansado, después de todo el día. No tienes a otro compañero mirando. No hay turno de guardia. Y si algo se rompe, al día siguiente tienes vida normal, familia, trabajo y cero ganas de convertir una actualización mal pensada en una excavación arqueológica por logs.
La pregunta que hago antes de tocar nada#
Antes de abrir el panel, me hago una pregunta muy poco técnica: si esto sale mal, ¿qué deja de funcionar para otra persona?
Esa pregunta limpia bastante la cabeza.
Si la respuesta es “solo pierdo un dashboard bonito”, puedo ir más rápido. Si la respuesta es “la casa se queda sin DNS”, paro. Si la respuesta es “puedo dejar temporalmente inaccesibles fotos o documentos”, paro todavía más.
La segunda pregunta es igual de importante: ¿cómo vuelvo atrás?
No me vale un “ya lo miraré”. Tampoco me vale confiar en que la aplicación arrancará porque normalmente arranca. Quiero saber cuál es el punto de retorno antes de empezar. Snapshot, backup verificado, export de configuración, copia del compose, nota con los cambios, posibilidad de arrancar el servicio anterior o plan B manual.
Cuando no hay marcha atrás clara, el cambio puede seguir teniendo sentido, pero deja de ser mantenimiento rutinario. Se convierte en migración. Y una migración necesita más margen.
Mi checklist corto#
Intenté durante un tiempo tener checklists demasiado completas. No funcionó. En un homelab, si el proceso pesa demasiado, acabas saltándotelo. Ahora uso una lista corta que sí hago de verdad.
Primero miro impacto. Qué servicios toca el cambio, quién los usa y qué pasa si fallan. No necesito un diagrama perfecto, pero sí una idea honesta.
Después miro estado actual. Si ya hay algo raro antes de empezar, no actualizo. Un nodo con almacenamiento tocado, un backup atrasado o una VM que lleva días reiniciándose no son buen punto de partida. Arreglar eso va antes.
Luego confirmo backup. No basta con que exista un job programado. Quiero saber cuándo fue el último backup válido y, si el cambio afecta a datos importantes, si puedo restaurar algo de forma razonable.
Después preparo rollback. A veces es un snapshot. A veces es guardar la configuración actual. A veces es dejar el contenedor antiguo parado pero no borrado. A veces es tener claro cómo volver a usar DNS externo si mi DNS interno se pone tonto.
Por último, aviso mentalmente del horario. En casa no mando un correo de cambio, claro. Pero sí evito tocar servicios compartidos justo antes de dormir, antes de salir o cuando alguien está usando algo importante.
Esta lista no es glamurosa. Precisamente por eso funciona.
Horarios que evito#
Hay horarios que parecen buenos porque tienes tiempo libre, pero son una trampa.
El peor para mí es tarde por la noche cuando ya estoy cansado. Es el clásico momento en el que piensas “solo actualizo esto rápido”. Mentira piadosa. Diez minutos después estás leyendo un issue de GitHub de 2023, con una base de datos que no migra y una sensación bastante clara de que has sido idiota.
También evito tocar cosas antes de una comida, antes de salir de casa o antes de una reunión. El homelab tiene una habilidad especial para convertir “esto está hecho en cinco minutos” en “ahora mismo no puedo apagar esto porque está reconstruyendo algo”.
Mi horario favorito para cambios con impacto doméstico es una franja con margen real. Si puedo, por la mañana o primera tarde, con una hora libre después. No porque el cambio vaya a durar una hora, sino porque quiero tener aire si algo se desvía.
Para cambios pequeños, diez o veinte minutos bastan. Para cambios de base de datos, storage, DNS o plataforma, quiero más. Si no tengo ese margen, lo apunto y lo dejo. Esto me ha ahorrado más problemas que cualquier herramienta.
Separar mantenimiento de exploración#
Una de las mejores decisiones que he tomado en el homelab es separar el mantenimiento de la exploración. Son estados mentales distintos.
Mantenimiento es actualizar algo que ya uso, corregir un problema, mejorar estabilidad o hacer una migración necesaria. Tiene objetivo concreto y final claro.
Exploración es probar una herramienta nueva, cambiar arquitectura porque me pica la curiosidad o ver si puedo montar algo mejor. Eso es lo divertido, pero también lo peligroso si lo mezclas con producción doméstica.
Cuando empiezo una ventana de mantenimiento, intento no meter “ya que estoy”. Esa frase es veneno. “Ya que estoy, cambio el reverse proxy”. “Ya que estoy, muevo también esta base de datos”. “Ya que estoy, pruebo esta versión beta”.
No.
Si el objetivo era actualizar Immich, actualizo Immich. Si el objetivo era revisar DNS, reviso DNS. Si aparece una mejora interesante, la apunto para otro día. El homelab se rompe muchas veces no por el cambio principal, sino por el tercer cambio lateral que metiste porque total, ya estabas dentro.
El estado previo importa más de lo que parece#
Antes de tocar nada, miro si el sistema está tranquilo.
No necesito una sala de control. Me basta con comprobar que los servicios importantes están levantados, que no hay alertas obvias, que los backups recientes existen y que el almacenamiento no está al límite. También miro si hay tareas largas en curso, como scrubs, backups pesados, replicaciones o actualizaciones pendientes.
Si algo huele raro, no empiezo. Esto parece obvio, pero cuesta. A veces tienes el rato justo y quieres aprovecharlo. Pero meter un cambio encima de un estado ya degradado hace que luego no sepas qué has roto tú y qué venía mal de antes.
En casa, además, hay otro estado previo que cuenta: el humano. Si estoy cansado, con prisa o de mal humor, bajo el alcance. Puedo revisar, documentar o preparar. Pero no hago cambios delicados. El cansancio es una dependencia no documentada y falla más que un disco viejo.
Backups: creer no cuenta#
Un backup que nunca has restaurado es una promesa, no una garantía. Y las promesas del homelab a las dos de la mañana tienen un historial regulero.
No pruebo restauraciones completas antes de cada cambio, sería demasiado. Pero sí quiero tener confianza razonable en tres cosas.
La primera es que el backup existe y no tiene semanas de antigüedad. La segunda es que sé dónde está. La tercera es que sé qué tendría que restaurar para volver a un estado útil.
Esto último se suele olvidar. No todos los servicios se restauran igual. Algunos viven en un volumen y una base de datos. Otros dependen de ficheros de configuración, certificados, secretos y rutas de almacenamiento. Otros tienen una base SQLite escondida en un directorio que nadie recuerda hasta que es demasiado tarde.
Para servicios críticos me gusta tener una nota pequeña con “qué hace falta para levantar esto de cero”. No una novela. Solo lo bastante para no depender de memoria cuando algo falla.
Ejemplo mental:
- Configuración del servicio.
- Datos persistentes.
- Base de datos, si existe.
- Variables o secretos.
- Puertos y nombres internos.
- Dependencias externas, como DNS, storage o proxy.
Si no puedo explicar eso en cinco líneas, probablemente no entiendo bien cómo está montado.
Rollback realista#
El rollback tiene que ser realista. No perfecto. Realista.
Si actualizo una aplicación en Docker, puedo guardar el compose actual, fijar la versión anterior de la imagen y saber qué volumen toca. Si actualizo una VM, un snapshot puede tener sentido, siempre que no lo deje acumulado durante meses. Si cambio DNS, el rollback puede ser volver temporalmente a DNS del router o de un proveedor externo.
Lo que intento evitar es el rollback imaginario: “si falla, ya volveré atrás”. Eso no es un plan. Es una frase para sentirse mejor.
También tengo cuidado con los cambios irreversibles. Migraciones de base de datos, cambios de formato, actualizaciones mayores y movimientos de storage no siempre vuelven atrás con un simple botón. Si la aplicación migra datos al arrancar, el snapshot de la máquina puede no bastar si la base de datos está fuera. Si el storage está compartido, el snapshot del contenedor tampoco protege tanto como parece.
La pregunta buena es esta: ¿qué pieza queda modificada aunque vuelva atrás la app?
Ahí suelen estar las trampas.
Servicios que trato con más respeto#
En mi casa hay servicios que no toco con la misma alegría que otros.
DNS es uno. Parece pequeño, pero cuando falla, todo parece roto. Internet va “mal”, las apps no cargan, la domótica se queda rara y pierdes tiempo buscando en sitios equivocados. Cualquier cambio de DNS lo hago con plan B claro.
Fotos familiares es otro. Immich, almacenamiento, backups y actualizaciones de base de datos merecen calma. Una galería puede parecer una app más, pero contiene recuerdos. Eso cambia el peso del mantenimiento.
Documentos también. Paperless-ngx o cualquier sistema parecido no debería depender de una cadena frágil que solo entiendes tú un día bueno.
Contraseñas, si se autoalojan, van en la categoría de máximo respeto. Aquí la pregunta no es solo si el servicio arranca. Es si puedes acceder cuando lo necesitas, si hay copia fuera, si 2FA está bien planteado y si la clave de administración no está tratada como una nota cualquiera.
Domótica depende. Una luz que no cambia de color no me preocupa. Calefacción, seguridad, sensores o automatizaciones que afectan a rutinas familiares ya son otra historia. Home Assistant puede ser maravilloso, pero también puede convertirse en una pieza crítica sin que te des cuenta.
Qué hago durante la ventana#
Durante la ventana intento tocar una cosa cada vez. Esto suena lento, pero acelera el diagnóstico.
Hago el cambio principal, espero a que el servicio arranque, compruebo lo que usa una persona normal y luego miro logs o métricas. No al revés. A veces nos quedamos mirando paneles verdes mientras la app falla en el flujo que importa.
Para mí una validación doméstica buena es muy concreta:
- Abre la app desde fuera si se usa desde fuera.
- Entra con un usuario normal, no solo admin.
- Crea o lee un dato realista.
- Comprueba que el backup siguiente no va a fallar por rutas cambiadas.
- Mira si el móvil, la tele o el dispositivo que realmente usa la casa sigue funcionando.
La última parte es importante. Muchos servicios se validan desde el navegador del ordenador donde estás trabajando, pero el problema aparece en el móvil, en la tablet, en la tele o en el dispositivo IoT que usa otro DNS.
Qué documento después#
No documento todo. Si intento documentarlo todo, no documento nada.
Pero después de un cambio con impacto, dejo una nota mínima:
- Qué cambié.
- Por qué lo cambié.
- Qué versión o arquitectura queda.
- Qué comprobé.
- Qué queda pendiente.
- Qué haría si falla.
Esto vale oro cuando vuelves tres meses después y no recuerdas por qué algo está así. La memoria humana es una mierda elegante: parece fiable hasta que necesitas un detalle concreto.
También intento borrar deuda visual. Si dejé un snapshot temporal, lo elimino cuando ya no hace falta. Si dejé un contenedor antiguo apagado, le pongo fecha o lo borro. Si creé una regla temporal, la quito. El homelab se llena de “por si acaso” y luego nadie sabe qué es seguro tocar.
Cuando parar#
Saber parar es parte del mantenimiento.
Si el cambio se desvía mucho, paro y vuelvo atrás. Si el rollback falla, dejo de optimizar y me centro en recuperar servicio. Si aparece un problema nuevo que no estaba en el alcance, lo apunto. No todo tiene que resolverse esa noche.
Hay una tentación muy fuerte de seguir porque ya estás metido. Mala señal. Cuando empiezas a encadenar soluciones improvisadas, cada paso añade incertidumbre. En un laboratorio da igual. En servicios familiares, no.
Mi señal de parada suele ser una de estas:
- El cambio lleva el doble de tiempo previsto.
- Ya no entiendo con claridad el estado actual.
- Estoy probando cosas por probar.
- He tocado dos capas distintas y estoy a punto de tocar una tercera.
- Empiezo a pensar “solo una cosa más”.
Cuando aparece eso, cierro. Dejo el sistema en el estado más estable posible y documento el punto exacto. Mañana con la cabeza limpia se trabaja mejor.
Mi conclusión#
Una ventana de mantenimiento doméstica no tiene que ser pesada. Tiene que ser honesta.
Honesta sobre el impacto, sobre el estado previo, sobre los backups, sobre el rollback y sobre tu propio cansancio. El homelab puede seguir siendo divertido, pero cuando sostiene cosas de casa necesita un poco de disciplina. No mucha. La justa para que el hobby no se convierta en una fuente de fricción.
La mejor ventana de mantenimiento es la que acaba sin épica. Cambias lo que querías cambiar, compruebas que funciona, dejas una nota y sigues con tu vida.
Si necesitas una historia heroica para actualizar un servicio doméstico, probablemente el diseño anterior ya te estaba avisando.