Un homelab se rompe de dos formas. La divertida es la explosiva: actualizas algo, el servicio cae, miras logs, maldices un poco y lo arreglas. La otra es peor porque no hace ruido. Un disco empieza a tener errores, un backup lleva tres semanas fallando, un certificado caduca, una base de datos crece sin límite, una VM que ya no usas sigue tragando RAM y nadie se entera hasta que toca restaurar algo.
Ese segundo tipo de fallo es el que intento cazar con un mantenimiento mensual. No hablo de pasar una tarde entera peinando cada paquete del sistema. Hablo de una revisión concreta, aburrida en el buen sentido, que me diga si el homelab sigue siendo mío o si se está convirtiendo en una criatura que vive en el rack y exige sacrificios.
La idea es simple: una vez al mes reviso lo que puede doler si falla. Backups, almacenamiento, actualizaciones pendientes, certificados, DNS, acceso remoto, servicios críticos y documentación mínima. Si algo no aporta nada, se apaga o se apunta para limpiar. Un homelab sano no es el que tiene más servicios, es el que puedes entender cuando estás cansado.
Empiezo por los backups, no por las lucecitas#
La tentación natural es abrir dashboards. CPU, RAM, temperaturas, gráficas bonitas. Yo intento resistirme. Lo primero son backups.
La pregunta no es si hay jobs configurados. La pregunta es si han terminado bien y si podría restaurar algo importante ahora mismo. Parece una diferencia pequeña, pero no lo es. Tener un sistema de backups que falla en silencio es peor que no tener nada, porque te da confianza falsa.
Mi revisión mensual empieza con tres cosas:
- Última copia correcta de cada servicio importante.
- Espacio disponible en el destino de backup.
- Prueba de restauración pequeña, aunque sea de un archivo, una base de datos de prueba o una configuración.
No hago una restauración completa todos los meses porque sería demasiado pesado. Sí intento tocar el sistema lo suficiente para no olvidar cómo funciona. Esto importa más de lo que parece. El día que algo se rompe, no quieres descubrir que el cliente de backup cambió el formato, que la contraseña no está donde pensabas o que el repositorio está corrupto desde hace semanas.
Para servicios con datos familiares, fotos, documentos o contraseñas, soy bastante más paranoico. Ahí quiero tener claro qué copia vive dentro de casa, qué copia sale fuera y qué datos dependen de un único servidor. En el artículo de Backup 3-2-1 para homelab ya conté la teoría, pero la parte mensual es menos elegante: mirar fechas, mirar errores y restaurar algo pequeño.
Si no puedes restaurar, no tienes backup. Tienes decoración técnica.
Discos y almacenamiento: el sitio donde no acepto fe#
Después miro almacenamiento. No me fío de un NAS o de un pool solo porque el panel esté verde. Quiero saber si hay discos con sectores reasignados, errores creciendo, scrub atrasado, snapshots descontrolados o datasets que aumentan sin explicación.
En casa es muy fácil llenar discos de forma tonta. Una carpeta de descargas que nadie limpia. Backups duplicados. Snapshots eternos. Logs de contenedores. Vídeos de cámaras. Imágenes de Docker antiguas. ISOs que ya no hacen falta. Todo suma. Y cuando el almacenamiento se llena, lo que cae no suele ser lo menos importante. Cae lo que justo estaba escribiendo en ese momento.
Mi revisión mensual de almacenamiento tiene cuatro preguntas:
- ¿Los discos están sanos o hay señales raras?
- ¿Los pools o volúmenes tienen margen suficiente?
- ¿Los snapshots tienen política de retención real?
- ¿Hay crecimiento inesperado en alguna carpeta o VM?
No necesito obsesionarme con cada métrica SMART, pero sí quiero ver tendencia. Un error aislado puede no ser nada. Un contador que sube cada mes es una invitación educada a comprar disco antes de que el disco decida por mí.
También reviso si hay almacenamiento montado por red que parece disponible pero no lo está. Este fallo es muy de homelab: el servicio cree que está escribiendo en un destino remoto, pero por un problema de montaje acaba escribiendo en el disco local. Cuando te das cuenta, el nodo está lleno y el backup no está donde debería. Por eso me gusta validar espacio y ruta real, no solo que el job haya arrancado.
Actualizaciones: menos épica y más criterio#
Actualizar todo porque sí me parece una forma muy eficiente de fabricar problemas. No actualizar nunca también. La gracia está en separar seguridad, estabilidad y capricho.
Una vez al mes reviso actualizaciones pendientes en los sistemas importantes. No necesariamente las aplico todas en ese momento. Primero miro qué cambia, si hay reinicios, si afecta a kernel, drivers, virtualización, base de datos o almacenamiento. Si es un servicio crítico de casa, prefiero planificarlo. Si es una VM de laboratorio, puedo ser más alegre.
Mi criterio actual es este:
- Seguridad expuesta a internet: prioridad alta.
- Servicios internos críticos: actualizar con snapshot o backup reciente.
- Herramientas de laboratorio: actualizar cuando tenga sentido.
- Contenedores secundarios: no perseguir versiones por deporte.
Con Docker y Compose, el problema suele ser la falsa comodidad. Cambias una imagen, levantas el stack y parece todo bien hasta que una migración rompe algo que solo ves al usar la app. Por eso intento leer notas de versión en servicios que guardan datos importantes. No todas, no cada línea, pero sí las advertencias grandes.
Watchtower y las actualizaciones automáticas tienen su sitio, pero no las quiero tocando servicios donde una migración mala me puede arruinar la tarde. Ya hablé de esto en actualizar contenedores sin jugar a la ruleta. Mi resumen mensual es más bruto: lo crítico se actualiza con cabeza, lo prescindible puede automatizarse, y lo que no se mantiene quizá sobra.
Certificados, DNS y acceso remoto#
Esta parte es poco sexy y por eso conviene revisarla. Si falla DNS interno, parece que se ha roto todo. Si caduca un certificado, pierdes media hora buscando un problema que no existe. Si Tailscale, WireGuard o el túnel que uses cambian de estado, igual descubres el fallo cuando estás fuera de casa.
Una vez al mes reviso:
- Certificados próximos a caducar.
- Resolución DNS interna de servicios importantes.
- Acceso remoto desde fuera de la LAN.
- Reverse proxy y rutas que todavía tienen sentido.
- Servicios publicados que ya no deberían estarlo.
Aquí soy partidario de tener menos magia. Nombres claros, dominios internos claros, pocas excepciones y una forma de entrar al homelab aunque el proxy principal esté roto. Si todo depende de una cadena de DNS, proxy, autenticación, túnel y contenedor, el día que falle te tocará desmontar una muñeca rusa.
También me gusta revisar qué servicios están expuestos. A veces publicas algo para probar, lo dejas funcionando y seis meses después sigue ahí. No pasa nada hasta que pasa. Si un servicio no necesita estar accesible desde fuera, fuera. Si solo lo uso yo, VPN o mesh VPN. Si lo usa la familia, entonces sí merece más mimo, pero también más restricciones.
Servicios críticos: pocos y vigilados#
Cada homelab tiene sus servicios sagrados. En mi caso, la lista realista no es larga: DNS, backups, acceso remoto, documentos, fotos, gestor de contraseñas si lo alojas tú, domótica si la casa depende de ella, y quizá alguna automatización importante.
Lo importante de esta lista es que sea corta. Si todo es crítico, nada lo es. Un panel de métricas bonito no debería tener la misma prioridad que el DNS de casa. Una app que probé un domingo no debería bloquear una actualización del nodo principal.
En la revisión mensual miro cada servicio crítico con una pregunta sencilla: si esto cae esta noche, ¿sé levantarlo mañana sin investigar desde cero?
Si la respuesta es no, faltan notas. O sobra complejidad.
Para cada servicio importante intento tener al menos:
- Dónde corre.
- Dónde guarda datos.
- Cómo se hace backup.
- Cómo se restaura.
- De qué depende.
- Qué usuario o dispositivo lo usa.
No hace falta escribir una tesis. Una nota corta vale más que una arquitectura perfecta que solo existe en mi cabeza. El homelab no falla cuando estás descansado y con café. Falla cuando tienes prisa, sueño o familia esperando que internet vuelva.
Limpieza de servicios: apagar también es mantener#
Esta es la parte que más cuesta porque a todos nos gusta montar cosas. Apagar parece perder. En realidad, apagar es recuperar cabeza.
Una vez al mes reviso contenedores, VMs y proyectos que llevan tiempo sin uso. Si no sé para qué sirven, mala señal. Si sé para qué servían pero ya no los uso, peor. Si los mantengo porque “igual algún día”, entonces probablemente deberían estar apagados, documentados o eliminados.
No borro a lo loco. Primero apago. Si durante unas semanas nadie se queja, archivo configuración o backup y luego limpio. Este proceso evita el drama de descubrir que una app olvidada hacía algo pequeño pero necesario.
La limpieza también incluye recursos. Una VM con 8 GB de RAM asignados porque un día hice pruebas puede estar robando margen al resto. Un contenedor con logs enormes puede estar comiendo disco. Una base de datos antigua puede seguir arrancando cada día sin motivo.
El mantenimiento mensual no solo busca fallos. Busca deuda técnica doméstica.
Documentación mínima, no burocracia#
Documentar un homelab puede convertirse en otra afición dentro de la afición. Wiki enorme, diagramas, inventarios, etiquetas, runbooks, todo precioso. Luego pasan dos meses y está desactualizado.
Mi enfoque ahora es más humilde. Prefiero pocas notas que sigan vivas:
- Inventario de servicios.
- Mapa básico de red.
- Lista de backups y restauración.
- Procedimientos para incidentes frecuentes.
- Decisiones raras con su motivo.
Lo último es importante. Muchas configuraciones parecen absurdas seis meses después, hasta que recuerdas que había una razón. Si tuve que hacer algo raro para que un servicio funcionase, lo apunto. No porque sea bonito, sino porque el futuro yo no tiene por qué pagar la factura de mi memoria optimista.
Para runbooks caseros, me gusta que sean casi tontos. “Si no resuelve DNS, mira esto”. “Si no entra por VPN, prueba esto otro”. Cuanto más cansado estás, menos quieres literatura. Quieres el siguiente paso.
Mi checklist mensual resumido#
El repaso completo suele quedar así:
- Ver backups terminados y restaurar una muestra pequeña.
- Revisar salud de discos, espacio libre y crecimiento raro.
- Comprobar snapshots y retenciones.
- Revisar actualizaciones pendientes con criterio.
- Ver certificados y DNS interno.
- Probar acceso remoto fuera de la red local.
- Mirar servicios expuestos y cerrar lo que no haga falta.
- Revisar servicios críticos y sus dependencias.
- Apagar o marcar para limpiar servicios abandonados.
- Actualizar notas mínimas si algo cambió.
No siempre hago todo con la misma profundidad. Si un mes voy justo, hago backups, discos, acceso remoto y servicios críticos. Lo demás puede esperar. Lo que no puede esperar es descubrir dentro de tres meses que la copia importante dejó de funcionar justo cuando nadie miraba.
Lo que aprendí a base de sustos pequeños#
El mantenimiento mensual no hace el homelab más emocionante. Lo hace más confiable. Y eso, cuando el homelab empieza a guardar cosas reales, vale más que montar otro servicio nuevo.
La lección que más me repito es esta: un sistema casero no necesita parecer profesional, necesita ser recuperable. Si algo se rompe, quiero saber qué se rompió, dónde están los datos y cuál es el camino más corto para volver a estar operativo.
También aprendí que muchas mejoras no son técnicas. Apagar lo que sobra. Escribir una nota. Poner nombres claros. No mezclar laboratorio con producción doméstica. Revisar una restauración. Comprar un disco antes de que el viejo empiece a gritar.
Son tareas pequeñas, casi aburridas. Precisamente por eso funcionan. El homelab que no se revisa acaba gobernándote. El que mantienes una vez al mes sigue siendo un laboratorio, no una hipoteca con LEDs.