Hay una pregunta incómoda que aparece cuando el homelab deja de ser un juguete personal: ¿qué pasa si yo no estoy?
No hablo de una catástrofe dramática. Puede ser algo tan normal como estar de viaje, enfermo, sin batería, durmiendo después de una noche mala o simplemente fuera de casa cuando internet decide ponerse tonto. Si el homelab solo sirve para probar cosas, da igual. Si guarda fotos, documentos, contraseñas, domótica, DNS o acceso remoto para la familia, la respuesta ya no puede ser “me llamas y lo miro”.
Durante mucho tiempo fui bastante malo en esto. Tenía backups, sí. Tenía notas, también. Tenía servicios separados, monitorización y alguna automatización útil. Pero gran parte del sistema seguía viviendo en mi cabeza. Y la cabeza del que monta el homelab es el peor sitio para guardar el plan de emergencia de la casa.
La solución no es escribir una biblia técnica. Nadie de casa va a leer veinte páginas sobre Docker, VLANs y snapshots cuando solo quiere que vuelva internet o encontrar una factura. Lo útil es una hoja corta, comprensible y mantenida. Un manual de emergencia doméstico.
Qué problema intenta resolver#
El manual de emergencia no sustituye al inventario, a los runbooks ni a los backups. Es una capa por encima, pensada para una persona que no quiere administrar el homelab.
Tiene que responder rápido a preguntas muy concretas:
- Qué servicios importan realmente.
- Qué hacer si falla internet o DNS.
- Cómo acceder al gestor de contraseñas.
- Dónde están las fotos y documentos.
- Qué backups existen y cuáles son recuperables sin mí.
- A quién pedir ayuda si el problema supera lo doméstico.
- Qué cosas no se deben tocar.
La última parte importa bastante. Un buen manual no solo dice qué hacer. También marca límites. Si alguien no sabe qué es una base de datos, no debería tener como paso “restaurar PostgreSQL”. Si una acción puede borrar datos, mejor que el manual diga “no tocar, pedir ayuda” antes que convertir una avería pequeña en una pérdida real.
Esto encaja con la ruta de servicios para la familia y con la de datos y copias de seguridad. Cuando los servicios son familiares, la documentación también tiene que ser familiar.
Primera página: lo que sí importa#
Yo empezaría con una lista muy corta de servicios críticos. Cinco o seis como máximo.
En una casa normal, para mí suelen ser estos:
- Internet y WiFi.
- DNS o bloqueo de anuncios si afecta a toda la red.
- Gestor de contraseñas.
- Fotos familiares.
- Documentos familiares.
- Domótica si controla cosas importantes.
- Acceso remoto si alguien depende de él.
Todo lo demás puede esperar. Un dashboard bonito, un lector RSS, un laboratorio Kubernetes, una app de pruebas o un panel de métricas no pertenecen a la primera página. Si se caen, que se caigan. Ya los arreglarás cuando vuelvas.
Esta separación reduce ruido. En una emergencia, el problema no es falta de información. Es exceso de caminos posibles. Si el manual empieza con veinte servicios, ya falla.
Mi formato favorito sería una tabla sencilla:
| Servicio | Para qué sirve | Qué hacer si falla | Puede esperar |
|---|---|---|---|
| Internet/WiFi | Conexión de casa | Reiniciar router una vez, esperar 5 minutos, llamar al operador si sigue igual | No |
| DNS interno | Resolución y bloqueo | Cambiar DNS del router a automático o DNS público temporal | No |
| Contraseñas | Accesos familiares | Usar dispositivos ya autenticados o contacto de emergencia | No |
| Fotos | Recuerdos familiares | No tocar discos, no borrar nada, pedir ayuda | Sí |
| Documentos | Facturas, contratos, papeles | Usar copia exportada o Paperless si funciona | Sí |
| Domótica | Luces, sensores, rutinas | Usar interruptores físicos, no tocar automatizaciones | Depende |
No es elegante. Mejor. Tiene que funcionar cuando nadie tiene paciencia.
Acceso a contraseñas sin crear otro riesgo#
El gestor de contraseñas merece su propia sección porque puede bloquear todo lo demás. Si la familia no puede entrar al gestor, quizá tampoco puede entrar al correo, al proveedor de internet, al panel del router o a la cuenta donde están las copias.
Si usas Bitwarden oficial, la función de Emergency Access permite designar contactos de confianza. Bitwarden documenta el flujo con invitación, confirmación y una solicitud posterior de acceso. No es algo que se improvisa el día que hace falta. Hay que configurarlo antes y probar que la otra persona entiende qué recibirá.
Si usas Vaultwarden, yo sería todavía más conservador. Vaultwarden es fantástico, pero en un entorno familiar conviene tener una salida de emergencia que no dependa de que el propio homelab esté perfecto. Puede ser una exportación cifrada guardada en un sitio seguro, un dispositivo de confianza ya autenticado o una cuenta externa con los accesos mínimos para pedir ayuda.
Lo que no haría es escribir contraseñas maestras en una hoja pegada al router. Parece práctico hasta que recuerdas que esa hoja protege media vida digital. Tampoco metería tokens, claves privadas o passwords en el manual. El manual debe decir dónde está el acceso de emergencia y quién puede usarlo, no convertirse en una caja fuerte de papel cutre.
Aquí hay que aceptar una tensión real. Cuanta más seguridad, más difícil es rescatar el sistema sin ti. Cuanta más comodidad, más riesgo. Mi punto medio sería:
- Un contacto de emergencia configurado en el gestor, si la herramienta lo permite.
- Códigos de recuperación guardados fuera del servidor principal.
- Una nota física mínima con instrucciones, no con secretos completos.
- Al menos un dispositivo familiar que ya tenga sesión iniciada.
- Un recordatorio anual para revisar que todo sigue funcionando.
La revisión anual suena aburrida, pero es donde se descubren los fallos. La cuenta cambió de correo. El móvil de confianza ya no existe. La persona no recuerda el flujo. El código de recuperación está en un cajón que nadie encuentra. Mejor descubrirlo una tarde tranquila que en mitad del lío.
Internet y DNS: el plan B tiene que ser tonto#
El fallo más visible para la familia casi siempre será “no va internet”. Da igual que técnicamente el problema sea DNS, WiFi, fibra, router, firewall o un contenedor. Para quien lo sufre, internet no va.
Por eso el manual no debería empezar explicando la arquitectura. Debería empezar por pasos seguros.
Mi plan simple:
- Comprobar si el problema afecta a todos los dispositivos.
- Reiniciar router una vez.
- Esperar unos minutos.
- Si la WiFi funciona pero no cargan webs, cambiar DNS a automático o a un DNS público temporal.
- Si nada funciona, llamar al operador.
- No tocar switches, firewall ni servidores salvo que haya una instrucción muy clara.
El punto del DNS temporal es importante. Mucha gente monta Pi-hole, AdGuard Home o Unbound y deja toda la casa dependiendo de ello. Funciona muy bien hasta que ese servicio cae y parece que internet ha muerto. Ya escribí sobre esto en red doméstica sin anuncios: Pi-hole o AdGuard, Unbound y DNS de respaldo y en plan B de DNS en casa.
Para una persona no técnica, el botón útil no es “reparar AdGuard”. Es “volver a DNS automático hasta que Luis lo mire”. Esa frase puede salvar una cena.
Fotos y documentos: proteger antes que arreglar#
Con fotos y documentos, la primera regla de emergencia debería ser no borrar nada.
Si Immich, Paperless o el NAS van lentos, no hay que empezar a limpiar carpetas, reiniciar contenedores al azar o tocar volúmenes. En servicios con datos irremplazables, una emergencia doméstica rara vez exige actuar en caliente. Casi siempre exige parar, preservar y pedir ayuda.
Immich lo deja bastante claro en su documentación de backup and restore: la base de datos no contiene las fotos y vídeos, solo metadatos. Para una recuperación completa necesitas copia de la base de datos y de los archivos subidos. También lo recuerda en su guía de inicio rápido, donde insiste en que las imágenes y vídeos en UPLOAD_LOCATION necesitan backup manual.
Ese detalle debería llegar al manual familiar traducido a lenguaje normal:
- Las fotos viven en el servidor, pero también hay copia en otro sitio.
- Si la app no carga, no significa que las fotos se hayan perdido.
- No borrar carpetas de fotos para “hacer sitio”.
- No formatear discos.
- No aceptar asistentes de reparación sin consultar.
Con Paperless pasa algo parecido. La documentación de Paperless-ngx explica opciones de backup y administración. En casa, la versión útil es más simple: los documentos importantes deben existir como PDFs recuperables, no solo como una aplicación bonita con OCR.
Por eso me gusta que el manual diga dónde hay una exportación o copia entendible. No hace falta explicar cada volumen de Docker. Basta con algo así:
“Los documentos importantes están en Paperless. Hay copia diaria en el NAS y copia externa. Si Paperless no abre, no significa que los PDFs se hayan perdido. No borrar nada. Si urge un documento, buscar primero en la carpeta exportada de documentos familiares o pedir ayuda.”
Esto no arregla todos los problemas, pero evita la reacción peligrosa.
Acceso remoto para ayudar sin abrir media casa#
Un buen plan de emergencia también debe permitir que alguien técnico ayude desde fuera. Puede ser Luis desde un portátil, un amigo de confianza o un familiar que sepa más. Pero el acceso remoto tiene que estar pensado antes.
Tailscale encaja muy bien aquí porque permite acceder a dispositivos sin abrir puertos al mundo. Su documentación de subnet routers explica cómo un dispositivo puede dar acceso a una red donde otros equipos no tienen cliente instalado. También tienen una guía para alta disponibilidad con subnet routers, útil si quieres que el acceso remoto no dependa de una sola máquina.
Ahora bien, yo no pondría todo el homelab accesible para cualquiera. El manual debería separar:
- Quién puede pedir ayuda.
- Qué cuenta se usa.
- Qué dispositivo debe estar encendido.
- Qué servicios puede tocar esa persona.
- Qué queda fuera de límites.
Un ejemplo doméstico:
“Para soporte remoto, encender el mini PC marcado como acceso. No abrir puertos en el router. No dar claves por teléfono. Si hace falta ayuda, usar la cuenta compartida de soporte con acceso limitado por Tailscale.”
El detalle de “no abrir puertos” merece estar escrito. En una urgencia, alguien puede buscar tutoriales rápidos y terminar exponiendo un panel interno por desesperación. Mala idea. Si el plan remoto está preparado, no hace falta improvisar.
Qué dejar en papel y qué dejar en digital#
El manual de emergencia debería existir en dos formatos.
Una copia digital, en Markdown, PDF o una nota sincronizada. Cómoda para actualizar.
Una copia física corta. Aburrida, guardada donde tenga sentido. No con secretos completos, pero sí con instrucciones y referencias.
La copia física cubre el caso más tonto y más real: no hay internet, no carga la wiki, el portátil no tiene batería o la persona que necesita la información no sabe dónde está tu repositorio de notas. Si el único manual vive dentro de un servicio del propio homelab, el plan se muerde la cola.
Yo pondría en papel:
- Nombre de los servicios críticos.
- Qué hacer si falla internet.
- Qué hacer si falla el gestor de contraseñas.
- Dónde están los backups importantes, descrito sin rutas privadas.
- A quién llamar.
- Qué no tocar.
Y dejaría fuera:
- Contraseñas completas.
- Tokens.
- IPs internas reales si no hacen falta.
- Claves privadas.
- Detalles de arquitectura que solo confunden.
Si necesitas incluir un secreto, mejor usa un sobre sellado, una caja fuerte doméstica o el mecanismo de emergencia del gestor de contraseñas. El manual no debe convertirse en el punto más débil del sistema.
La plantilla que usaría#
Mi plantilla mínima tendría estas secciones.
1. Qué hay en casa#
Una lista corta de servicios reales. No nombres internos raros.
- Internet y WiFi.
- Fotos familiares.
- Documentos familiares.
- Contraseñas.
- Domótica.
- Backups.
- Acceso remoto.
2. Qué hacer primero#
Tres instrucciones generales:
- No borrar nada.
- Reiniciar solo lo indicado.
- Si hay duda, parar y pedir ayuda.
3. Incidentes comunes#
Un bloque por síntoma:
- No hay internet.
- No abren webs, pero la WiFi conecta.
- No puedo entrar al gestor de contraseñas.
- No veo las fotos.
- Necesito un documento urgente.
- La domótica no responde.
Cada bloque debería tener pocos pasos. Si pasan de media página, ya no es de emergencia.
4. Backups#
No hace falta listar todos los jobs. Sí hace falta decir:
- Qué datos tienen copia.
- Dónde hay copia local.
- Dónde hay copia externa.
- Cuándo se revisó por última vez.
- Qué se ha probado restaurar.
Esto conecta con prueba real de restauración en homelab y con SAI para homelab: qué proteger, cuánta autonomía necesito y cómo apagar limpio. Un plan de emergencia sin restauración probada es una promesa bastante frágil.
5. Contactos de ayuda#
Nombres, canales y contexto. No hace falta contarles toda la red. Basta con decir quién puede ayudar con qué.
- Operador de internet.
- Persona técnica de confianza.
- Soporte del NAS o proveedor cloud si aplica.
- Contacto familiar que entiende el flujo de contraseñas.
6. Cosas prohibidas#
Esta sección parece dura, pero ayuda.
- No formatear discos.
- No borrar carpetas de fotos o documentos.
- No abrir puertos en el router.
- No resetear el NAS.
- No cambiar contraseñas maestras sin avisar.
- No tocar backups antiguos para liberar espacio.
Muchas pérdidas de datos empiezan con alguien intentando arreglar algo de buena fe. Mejor poner barandillas.
Cómo mantenerlo sin convertirlo en otra tarea pesada#
El manual de emergencia solo sirve si está vivo. Pero mantenerlo no puede ser otra ceremonia mensual enorme.
Yo lo engancharía a hábitos que ya existen:
- Revisión mensual del homelab.
- Prueba de restauración pequeña.
- Cambio de router, NAS o servidor.
- Alta o baja de un servicio familiar.
- Cambio de gestor de contraseñas.
- Antes de vacaciones.
Cada vez que algo crítico cambia, actualizas una línea. No una tarde de documentación. Una línea.
También conviene probarlo de forma humilde. Darle la hoja a alguien de casa y preguntar: “si mañana no estoy, ¿entiendes qué harías si no va internet?”. Si la respuesta es no, el manual está escrito para ti, no para la familia.
Eso duele un poco, pero sirve.
Lo que no intentaría resolver#
No intentaría que una persona no técnica pueda administrar todo el homelab. Es una fantasía y además una carga injusta. El manual de emergencia no busca convertir a nadie en operador de sistemas.
Tampoco intentaría documentar cada contenedor, cada IP, cada volumen y cada regla de firewall. Para eso está el inventario automático del homelab y los runbooks caseros.
El manual familiar tiene otra misión: mantener la casa funcionando, proteger datos y saber cuándo parar.
Hay una madurez rara en aceptar eso. El homelab puede seguir siendo divertido, complejo y lleno de pruebas. Pero lo que toca a la familia necesita una capa de simplicidad casi antipática.
Si mañana no estás disponible, nadie debería tener que entender tu arquitectura para no perder las fotos, recuperar internet o encontrar un documento. Una hoja clara no luce en el rack. No sale en capturas. No impresiona a nadie.
Y aun así, probablemente sea una de las mejores piezas de infraestructura doméstica que puedes montar.