Un homelab se vuelve serio el día que deja de ser solo un sitio donde probar cosas y empieza a cargar servicios que alguien usa de verdad. Puede ser algo pequeño. El DNS de casa. Las fotos familiares. Home Assistant. Un gestor de contraseñas. El servidor de medios. Un panel de estado. Da igual. En cuanto alguien de casa depende de eso, aunque sea de forma indirecta, ya no basta con tener backups “por ahí”.
Yo tardé demasiado en aceptar esto. Durante una temporada tenía una mezcla bastante típica: backups de algunas cosas, snapshots de otras, datos repartidos entre varios servidores, notas sueltas y demasiada confianza en que llegado el caso ya me acordaría de cómo estaba todo montado. Eso funciona mientras no pasa nada. El problema es que un desastre no suele llegar a las 11:30 de un martes con café recién hecho y dos horas libres. Llega de noche, con prisa, con el NAS haciendo ruidos raros o con la casa preguntando por qué no funciona Internet.
Por eso ahora pienso el plan de recuperación al revés. No empiezo por la herramienta. Empiezo por una pregunta incómoda: si mañana pierdo el nodo principal, ¿qué necesito levantar primero para que la vida siga razonablemente normal?
No para dejar el homelab bonito. Para que funcione lo importante.
el error típico: tratar todos los servicios igual#
El fallo más común es meter todo en el mismo saco. Como si Jellyfin, DNS, Vaultwarden, Home Assistant, Grafana, un blog estático y una instancia de pruebas tuviesen la misma prioridad. No la tienen.
En mi cabeza separo el homelab en cuatro niveles.
Nivel 0: red mínima y acceso. Router, DHCP, DNS básico, VPN o acceso remoto si lo necesito para reparar desde fuera.
Nivel 1: servicios domésticos críticos. Contraseñas, domótica si controla cosas reales, backups, documentos importantes y fotos.
Nivel 2: servicios útiles pero no urgentes. Media server, automatizaciones, lectores RSS, dashboards, repositorios, monitorización.
Nivel 3: laboratorio y juguetes. Clusters de prueba, modelos locales, entornos temporales, cosas que molan pero no justifican romperse la tarde.
Esta clasificación parece obvia hasta que toca restaurar. Ahí se nota si lo tienes pensado o si vas abriendo carpetas como un arqueólogo triste.
Si todo cae, no quiero perder media hora levantando un dashboard precioso para ver que el dashboard dice que todo está caído. Quiero DNS, acceso, contraseñas y los datos importantes. Después ya vendrá el resto.
mi orden de restauración#
El orden que más sentido me tiene en casa es este.
Primero, red y resolución de nombres. Si el DNS local era demasiado listo y ahora nada resuelve, me da igual que los containers estén perfectos. Necesito una ruta simple. Puede ser el DNS del router, un Pi-hole restaurado o un AdGuard mínimo. Pero tiene que haber un modo tonto de volver a navegar y resolver nombres internos básicos.
Segundo, acceso administrativo. SSH, VPN, panel de Proxmox o lo que toque. No quiero depender de una cadena de servicios que todavía no he restaurado. Si para entrar al servidor necesito que funcionen tres piezas más, tengo un diseño demasiado elegante para un día malo.
Tercero, gestor de contraseñas. Esto es fácil de infravalorar. Sin contraseñas, tokens, claves y notas de recuperación, arreglar todo lo demás se convierte en un escape room absurdo. Si usas Vaultwarden, Bitwarden, 1Password o similar, asegúrate de que puedes acceder aunque el homelab principal esté muerto.
Cuarto, backups y almacenamiento. Antes de levantar veinte servicios, necesito saber dónde están los datos buenos, cuál es la última copia válida y si puedo restaurar sin pisar lo que queda vivo.
Quinto, servicios familiares. Fotos, documentos, domótica, sincronización de archivos. Lo que alguien de casa echa de menos antes de que tú termines de mirar logs.
Sexto, servicios personales y de ocio. Media, RSS, dashboards, automatizaciones no críticas.
Séptimo, laboratorio. Aquí entra casi todo lo que a mí me apetece tocar primero, precisamente por eso lo dejo para el final. El homelab tiene una capacidad peligrosa para disfrazar procrastinación de mantenimiento.
RTO y RPO sin ponerse traje#
Hay dos conceptos empresariales que en casa siguen siendo útiles si les quitamos la corbata.
RTO es cuánto tiempo puedo tardar en recuperar algo. RPO es cuántos datos puedo perder.
No hace falta montar una consultora alrededor de esto. Basta con escribir números honestos.
Para DNS local, mi RTO ideal es bajo. Si se rompe, quiero tener algo funcional en 15 o 30 minutos. Pero el RPO casi no importa, porque la configuración cambia poco.
Para fotos familiares, el RTO puede ser de horas o incluso un día. Nadie necesita ver una foto concreta en diez minutos. Pero el RPO tiene que ser bajo. Perder las fotos de la última semana me parece mucho más grave que tener Immich caído una tarde.
Para media server, el RTO puede ser de días y el RPO depende de si la biblioteca se puede reconstruir. Si es contenido descargable, duele menos. Si son vídeos propios, cambia completamente.
Para Home Assistant depende de qué controles. Si solo enciende luces decorativas, tranquilidad. Si gestiona calefacción, cámaras, alarmas o rutinas importantes, sube de nivel.
La gracia está en no mentirse. Todos decimos que algo no es crítico hasta que deja de funcionar y alguien en casa pregunta por ello cada diez minutos.
backups: tener copia no significa poder volver#
Esta frase debería estar pegada en todos los racks caseros: un backup que no has restaurado es una promesa, no una garantía.
Yo prefiero tener menos sistemas de backup, pero entenderlos bien. Un esquema razonable para casa puede ser:
- Snapshots locales para errores rápidos.
- Copia en otro equipo de la red para fallo de nodo o disco.
- Copia externa para incendio, robo, ransomware o desastre serio.
- Exportación periódica de configuraciones críticas en formato legible.
Los snapshots son comodísimos, pero no son backups completos. Si el pool muere, el snapshot muere con él. Si borras mal y replica el borrado, puedes perder la copia buena. Si el ransomware cifra datos y luego haces snapshot de datos cifrados, enhorabuena, tienes una foto preciosa del desastre.
Para VMs y contenedores, Proxmox Backup Server tiene mucho sentido si usas Proxmox. Deduplicación, backups incrementales, verificación, restauraciones limpias. Pero tampoco me gusta que sea la única pieza. Si el PBS vive en el mismo hardware, misma red eléctrica y mismo armario que todo lo demás, ayuda mucho ante algunos fallos y poco ante otros.
Para datos de aplicaciones, miro cada caso. Algunas bases de datos prefieren dumps consistentes. Algunos servicios tienen carpetas simples. Otros mezclan base de datos, archivos subidos y configuración. Ahí no vale copiar a lo bruto y rezar.
Con las fotos soy especialmente conservador. Si una plataforma tipo Immich se rompe, me importa menos reconstruir la app que conservar los originales. La aplicación puede volver. Las fotos no.
documentación mínima que sí merece la pena#
No hace falta escribir una novela técnica de cada servicio. De hecho, si la documentación es enorme, probablemente no la leerás cuando estés cansado. Lo que me funciona es una ficha breve por servicio importante.
Qué es. Dónde vive. Qué datos necesita. Dónde está el backup. Cómo se restaura. Qué depende de él. Qué rompe si no está.
Para Vaultwarden, por ejemplo, quiero saber si tengo copia de la base de datos, adjuntos, configuración, token de admin si aplica, método de 2FA y una forma externa de acceder a credenciales maestras.
Para Home Assistant, quiero saber dónde está la copia completa, qué integraciones son críticas, qué dispositivos dependen de nombres locales y qué puedo dejar apagado sin drama.
Para DNS, quiero una lista de registros internos importantes. Pocos. Los que de verdad desbloquean la casa.
Para almacenamiento, quiero un mapa de datasets, shares y qué servicio usa cada uno. No necesito cada detalle del sistema. Necesito no tener que adivinar.
La documentación buena para recuperación no es la que impresiona. Es la que puedes usar con sueño.
reducir dependencias raras#
Aquí es donde el homelab se pone incómodo. Cuanto más bonito es el diseño, más fácil es crear una cadena de dependencias ridícula.
Ejemplo típico: el DNS vive en una VM dentro de Proxmox. Proxmox depende de almacenamiento compartido. El almacenamiento compartido depende de DNS para montar algo. La VPN depende del DNS. El panel de backups depende de la VPN. Y tú dependes de todo eso para reparar.
Eso es arquitectura circular con luces RGB.
Intento que los servicios de recuperación tengan rutas simples. El router debe poder funcionar sin el homelab completo. Debe existir un DNS alternativo. Debe haber una forma de entrar a los nodos sin depender del SSO que justo está caído. Las contraseñas críticas deben estar accesibles aunque el gestor self-hosted esté muerto.
No significa renunciar a SSO, DNS interno o automatización. Significa tener una puerta lateral honesta.
prueba de restauración: la parte que nadie quiere hacer#
Restaurar de verdad da pereza. También da miedo, porque igual descubres que tu backup no sirve. Precisamente por eso hay que hacerlo.
Mi prueba mínima ideal no es destruir producción. Es levantar una restauración aislada.
Cojo un servicio importante, restauro en una VM o entorno aparte, cambio nombres y rutas para no pisar nada, compruebo que arranca y verifico que los datos están. Si es una base de datos, abro la app. Si son documentos, busco archivos concretos. Si son fotos, reviso originales y miniaturas. Si es una VM completa, confirmo que arranca sin depender de la red de producción.
La primera vez suele salir algo mal. Permisos. Rutas. Variables de entorno. Versiones de imagen. Dumps incompletos. Backups que existían, pero de la carpeta equivocada. Mejor descubrirlo un domingo tranquilo que una noche con cara de funeral.
También conviene medir cuánto tardas. No para competir, sino para ajustar expectativas. Igual creías que restaurar todo eran 30 minutos y son tres horas. Bien. Ahora lo sabes.
qué no metería en el plan crítico#
Hay servicios que me encantan y no pondría en la primera línea de recuperación.
Grafana puede esperar. Si todo está caído, no necesito una serie temporal perfecta para confirmar que todo está caído.
Los LLMs locales pueden esperar. Nadie en casa debería depender de que un modelo conteste mientras estás recuperando infraestructura.
El media server puede esperar. Sí, escuece. Pero si tienes DNS, contraseñas, documentos y fotos vivos, ya has ganado.
La automatización avanzada puede esperar. Especialmente si es frágil. En desastre prefiero pasos manuales claros a un workflow precioso que falla porque una API no responde.
El laboratorio puede esperar siempre. Si no genera dinero, no sostiene la casa y no guarda datos únicos, va detrás.
Esto no es una lista moral. Es priorización. En el momento malo, priorizar es una forma elegante de no perder la cabeza.
una matriz sencilla#
Mi matriz de recuperación casera tendría este aspecto.
| Servicio | Prioridad | RTO razonable | RPO razonable | Comentario |
|---|---|---|---|---|
| Router y red básica | 0 | 15 min | bajo | Debe sobrevivir sin el homelab completo |
| DNS local | 0 | 30 min | bajo | Tener fallback externo o del router |
| Gestor de contraseñas | 1 | 30 min | muy bajo | Export o acceso alternativo imprescindible |
| Fotos familiares | 1 | 24 h | muy bajo | La app importa menos que los originales |
| Documentos | 1 | 4 h | bajo | Restauración verificable, no solo copia |
| Home Assistant | 1 o 2 | 1 a 4 h | medio | Depende de qué controle en casa |
| Backups | 1 | 1 h | bajo | Sin backups no hay recuperación ordenada |
| Media server | 2 | 1 a 3 días | variable | Si se puede reconstruir, baja prioridad |
| Monitorización | 2 | 1 día | medio | Útil después de recuperar lo básico |
| Laboratorio | 3 | cuando toque | variable | No debe bloquear nada crítico |
No es perfecta. Es útil. Y en recuperación, útil gana a perfecto por goleada.
lo que cambiaría si empezase hoy#
Si montase el homelab desde cero pensando en recuperación, haría varias cosas antes.
Separaría mejor lo crítico de lo divertido. Un mini PC sencillo para servicios básicos puede valer más que un cluster precioso si ese cluster se convierte en una maraña de dependencias.
Documentaría desde el primer despliegue. No mucho, pero sí lo necesario. Esperar a documentar cuando ya tienes treinta servicios es una condena autoimpuesta.
Probaría restauraciones antes de confiar. Especialmente fotos, documentos, gestor de contraseñas y Home Assistant.
Tendría una copia externa de verdad. No una idea vaga de que “esto se sincroniza”. Una copia que pueda recuperar sin depender de la casa.
Usaría menos magia. Menos automatización crítica que solo entiendo cuando estoy fresco. Más rutas manuales y aburridas.
Y aceptaría que algunos servicios no merecen plan de recuperación. Si algo tarda más en documentarse que en reconstruirse, quizá el plan sea reconstruirlo.
mi conclusión#
Un plan de recuperación ante desastre no tiene que ser enterprise. Tiene que ser sincero.
Sincero con lo que usas. Sincero con lo que puedes perder. Sincero con el tiempo que tardas en restaurar. Sincero con las dependencias que has creado. Sincero con esa parte de ti que quiere levantar primero el dashboard porque queda bonito.
Yo no quiero un homelab perfecto. Quiero un homelab que pueda romperse sin convertir la casa en un comité de crisis. Para eso hace falta menos épica y más orden: saber qué importa, dónde están los datos, cómo se recuperan y qué puede esperar.
El día que algo falle, no quiero improvisar arquitectura. Quiero seguir una lista corta, levantar lo importante y dejar el cacharreo para cuando vuelva la calma.