Durante años he tenido una relación bastante absurda con el inventario del homelab. Cuando montas dos servicios, lo llevas en la cabeza. Cuando montas diez, crees que lo sigues llevando en la cabeza. Cuando tienes varias máquinas, contenedores, VMs, un NAS, DNS interno, copias, automatizaciones y algún servicio que usa la familia, la cabeza deja de ser documentación y pasa a ser una trampa.
El problema no aparece un sábado tranquilo mientras estás mirando dashboards. Aparece cuando algo se rompe, estás cansado y necesitas saber rápido qué depende de qué. ¿Dónde corre este servicio? ¿Qué volumen usa? ¿Tiene backup? ¿Quién lo usa? ¿Puedo apagar esta máquina sin liarla? ¿Este contenedor es laboratorio o producción doméstica? ¿Por qué hay dos bases de datos parecidas?
Ahí descubrí que tener muchos datos no es tener inventario.
También descubrí que intentar montar una CMDB casera suele ser la antesala del abandono. Puedes instalar una herramienta enorme, definir campos perfectos, clasificar activos, dibujar relaciones y sentir que has hecho consultoría de la buena. Luego pasan tres semanas, cambias dos contenedores, migras una VM, te olvidas de actualizarlo y ya tienes otra base de datos desactualizada mirándote con cara de reproche.
Para casa prefiero otra cosa: un inventario pequeño, parcialmente automático y lo bastante útil como para mirarlo cuando hay problemas. Si no ayuda en una avería real, es decoración.
Qué tiene que responder el inventario#
Yo no empezaría por la herramienta. Empezaría por las preguntas.
En mi caso, un inventario de homelab tiene que responder cinco cosas sin obligarme a pensar demasiado:
- qué existe
- dónde corre
- qué dato guarda
- qué backup tiene
- qué se rompe si lo paro
Con eso ya tienes muchísimo más que la mayoría de inventarios domésticos. No necesito un sistema perfecto de gestión de activos. Necesito saber que Paperless guarda documentos familiares en tal volumen, que depende de PostgreSQL, que se copia cada noche y que si apago ese nodo no puedo consultar facturas escaneadas. Necesito saber que Home Assistant es crítico para algunas rutinas de casa, pero que un dashboard de laboratorio puede esperar. Necesito separar un servicio que usa la familia de una prueba que solo me entretiene a mí.
La diferencia entre esos dos mundos importa. Un contenedor de pruebas puede morir sin ceremonia. Un gestor de contraseñas, fotos familiares, DNS o automatización doméstica merecen otro trato.
Mi inventario ideal no intenta describir toda la infraestructura con precisión militar. Describe lo suficiente para tomar decisiones. Ese matiz me parece vital, porque cuanto más perfecto quieres hacerlo, menos lo mantienes.
El formato que sí mantendría#
He probado hojas, wikis, notas sueltas y paneles. Al final vuelvo siempre a algo sencillo: un fichero versionado o una pequeña base de datos exportable a texto.
Para un homelab pequeño, un YAML por servicio funciona muy bien. También vale JSON, Markdown con front matter o una tabla en CSV si eres persona de tablas. Lo importante es que sea fácil de editar, fácil de revisar en Git y fácil de generar parcialmente desde scripts.
Un registro de servicio podría tener campos como estos:
| |
No hace falta que todos los campos estén perfectos desde el primer día. De hecho, si intentas rellenarlo todo de golpe, probablemente no lo termines. Yo empezaría por los servicios críticos y después iría bajando.
La gracia del texto plano es que no te ata a una aplicación. Puedes generar una web estática, un panel simple, un resumen diario o una tabla para imprimir. Si mañana cambias de herramienta, los datos siguen siendo tuyos.
Qué automatizar y qué dejar manual#
Hay una tentación muy normal: querer descubrir todo automáticamente. Escanear hosts, consultar APIs, listar contenedores, leer etiquetas, sacar volúmenes, detectar puertos, generar diagramas y que la máquina lo entienda todo. Suena precioso. También suele terminar en ruido.
Yo separaría el inventario en dos capas.
La primera capa es automática y factual. Cosas que una máquina puede decir sin inventarse contexto:
- VMs y contenedores existentes
- estado encendido o apagado
- host donde corren
- recursos asignados
- imágenes Docker usadas
- puertos publicados
- volúmenes montados
- jobs de backup recientes
- certificados próximos a caducar
La segunda capa es humana. Cosas que el sistema no sabe por sí solo:
- criticidad
- quién usa el servicio
- si guarda datos importantes
- si se puede apagar
- dependencia funcional entre servicios
- nivel de molestia si falla
- si merece migrarse o retirarse
Esta separación evita una mentira bastante común: creer que porque algo aparece en una API ya está documentado. La API puede decir que existe un contenedor. No sabe si ese contenedor guarda las fotos de tu hija o si es una prueba que olvidaste hace seis meses.
Mi enfoque sería generar un inventario bruto cada noche y cruzarlo con metadatos manuales. Si aparece algo nuevo sin metadatos, lo marco como pendiente. Si desaparece algo que estaba documentado, lo marco como huérfano. Ese simple contraste ya detecta bastante mierda.
Etiquetas antes que memoria#
Si usas Docker, Proxmox, Kubernetes o cualquier sistema con etiquetas o comentarios, merece la pena usarlos. No para meter una novela, sino para dejar pistas mínimas.
En Docker Compose, por ejemplo, puedes etiquetar servicios con criticidad, propietario y política de backup. En Proxmox puedes usar nombres claros, notas y tags. En Kubernetes puedes usar labels y annotations. No hace falta convertirlo en una tesis. Basta con que el inventario automático pueda recoger señales útiles.
Yo usaría etiquetas como:
criticality=altascope=casabackup=diariodata=fotosexposure=interno
No lo haría para todo. Lo haría para lo que duele perder o romper. Si etiquetas hasta el contenedor de prueba que levantaste para mirar una UI, acabas manteniendo basura.
Los nombres también importan. Mucho. postgres-1 no dice nada. postgres-paperless ya te orienta. vm-108 no ayuda. paperless-prod ayuda. No hace falta ser poético. Hace falta que el nombre tenga sentido cuando estás mirando una consola con sueño.
Inventario de dependencias: el mapa que agradeces tarde#
La parte que más valor me da no es saber cuántas VMs tengo. Es saber qué se cae si apago algo.
Un ejemplo sencillo: si apago el servidor donde corre DNS interno, quizá no solo pierdo resolución de nombres. También pierdo acceso cómodo a Vaultwarden, Paperless, Home Assistant, dashboards y cualquier servicio que dependa de esos nombres. Si apago el NAS, tal vez algunos contenedores siguen vivos, pero sin datos. Si apago el reverse proxy, los servicios siguen corriendo, pero nadie entra por nombres bonitos.
Ese mapa no tiene que ser perfecto. Con tres niveles basta:
- dependencia dura: si falla, el servicio no funciona
- dependencia cómoda: si falla, el servicio funciona peor o cuesta acceder
- dependencia operativa: si falla, pierdo mantenimiento, alertas o backups
Esto cambia mucho las ventanas de mantenimiento. Antes de apagar una máquina, miro el inventario y veo el radio de impacto. Si una VM depende de un volumen en el NAS y de un proxy en otra máquina, apagar cualquiera de las tres piezas tiene consecuencias distintas.
También ayuda a detectar diseños tontos. Si todo depende de un único DNS y no hay plan B, el inventario te lo enseña. Si el backup depende de la misma máquina que quieres recuperar, también. Si tienes un servicio crítico con base de datos local y sin copia reciente, queda en evidencia. Bien. Para eso está.
Backups dentro del inventario#
Un inventario sin backups es medio inventario.
No me basta con saber que existe una tarea de copia. Quiero ver la política junto al servicio. Cada servicio debería decir qué se copia, dónde, cada cuánto y cuándo fue la última prueba de restauración. La parte de restauración es incómoda, pero es la que importa.
Yo pondría tres estados muy simples:
- protegido
- copia pendiente de validar
- sin protección suficiente
La tercera etiqueta escuece, pero ayuda. Hay servicios que puedes aceptar sin backup porque son recreables. Un dashboard, una prueba, un contenedor efímero. Otros no. Fotos, documentos, contraseñas, configuraciones de casa y bases de datos familiares no deberían vivir en el mismo cajón mental que una demo.
Si el inventario se genera cada noche, puede comprobar antigüedad de backups y marcar alertas suaves. No hace falta que te despierte por todo. Pero sí puede dejar claro que un servicio crítico lleva varios días sin copia válida.
Esto conecta muy bien con la rutina mensual. Reviso el inventario, miro servicios críticos sin restore reciente y hago una restauración de muestra. No es emocionante. Tampoco lo es explicar que las fotos se han perdido.
Servicios huérfanos y basura elegante#
Una de las mejores cosas de automatizar inventario es descubrir basura. Contenedores parados desde hace meses. VMs que nadie usa. Volúmenes sin servicio asociado. DNS apuntando a cosas que ya no existen. Reglas de proxy para aplicaciones retiradas. Backups de servicios muertos ocupando disco.
No todo lo viejo sobra, pero todo lo viejo sin explicación merece sospecha.
Yo tendría una sección de huérfanos generada automáticamente:
- volumen sin contenedor activo
- entrada DNS sin respuesta
- proxy host sin backend
- VM apagada más de noventa días
- backup de servicio que ya no existe
- puerto publicado sin documentación
Esto no va de limpiar por limpiar. Va de reducir superficie mental. Cada cosa olvidada aumenta el ruido. Y el ruido en un homelab termina afectando a decisiones reales: no sabes si puedes borrar, no sabes si puedes apagar, no sabes si puedes migrar.
El inventario debería ayudarte a retirar cosas. Para mí, una buena entrada no solo dice “existe”. También puede decir “candidato a borrar”. Eso es salud operativa.
Cómo lo publicaría para consultarlo rápido#
El formato fuente puede ser texto, pero la consulta tiene que ser cómoda. No quiero abrir diez ficheros si algo falla. Quiero una página simple con filtros.
Una web estática interna me parece suficiente:
- tabla de servicios
- filtro por criticidad
- filtro por host
- filtro por backup
- lista de dependencias
- enlaces internos
- fecha de última actualización
No la expondría a internet. Esto es información sensible. Aunque uses nombres genéricos, un inventario revela arquitectura. Mejor detrás de VPN o solo en LAN.
También generaría un resumen corto. Algo tipo:
- servicios críticos: 12
- sin backup validado: 2
- certificados próximos a caducar: 1
- huérfanos detectados: 5
- cambios desde ayer: 3
Ese resumen vale más que un dashboard precioso si te permite actuar.
Frecuencia y rutina#
No hace falta inventariar cada minuto. Para casa, una ejecución diaria suele bastar. Si estás haciendo cambios grandes, puedes ejecutarlo manualmente antes y después.
Mi rutina ideal sería:
- generación automática cada noche
- comparación contra el día anterior
- resumen de cambios
- revisión mensual de pendientes
- prueba de restauración para servicios críticos
El punto fuerte no es la frecuencia. Es el hábito. Si cada cambio deja rastro, el inventario se mantiene vivo. Si dependes de acordarte un domingo, no va a pasar. Y si pasa, será el domingo equivocado.
También me gusta guardar históricos. No todos para siempre, pero sí snapshots semanales o mensuales. Ayudan a responder preguntas raras: cuándo apareció esta VM, cuándo dejó de existir este servicio, cuándo cambió de host, cuándo empezó a faltar backup.
Lo que no metería#
Hay cosas que parecen buena idea y yo evitaría.
No metería contraseñas, tokens ni rutas sensibles. El inventario debe indicar que existe un secreto, no contenerlo. Tampoco pondría IPs reales si la web puede acabar copiada en algún sitio. Mejor nombres internos y referencias genéricas.
No intentaría documentar cada puerto efímero ni cada detalle de red si no ayuda a operar. No convertiría el inventario en un duplicado de la configuración. Para eso ya están los ficheros de Compose, Terraform, Ansible o lo que uses.
Tampoco obligaría a que todo pase por una herramienta. Si algo se mantiene mejor en una nota concreta, enlázalo. El inventario es un índice operativo, no una cárcel.
Y no lo haría perfecto. Esto cuesta aceptarlo, pero en casa gana el sistema que se mantiene. Un inventario al 70 por ciento actualizado, con servicios críticos bien cubiertos, es infinitamente mejor que una CMDB preciosa abandonada desde mayo.
Mi criterio final#
Un buen inventario de homelab tiene que sobrevivir a una pregunta concreta: “¿puedo tocar esto ahora?”.
Si la respuesta sale rápido, sirve. Si te obliga a buscar en mensajes antiguos, abrir paneles, recordar migraciones y hacer arqueología de contenedores, no sirve.
Yo empezaría pequeño. Diez servicios críticos. Metadatos mínimos. Generación diaria. Detección de cambios. Backups al lado de cada servicio. Dependencias aproximadas. Huérfanos visibles.
Luego ya habrá tiempo de hacerlo más bonito.
El homelab no necesita una CMDB de empresa disfrazada de proyecto personal. Necesita una libreta que no mienta, que se actualice sola en lo obvio y que te ayude cuando tienes que decidir con poco tiempo. Lo demás suele ser trabajo gratis con interfaz bonita.