Hay una frase que me repito bastante cuando reviso backups: si nunca lo he restaurado, no sé si tengo un backup. Tengo un archivo, una tarea programada y una sensación de tranquilidad bastante sospechosa.
En un homelab doméstico esto pasa mucho. Montas copias en el NAS, snapshots, sincronización a otro disco, quizá una copia externa, quizá algo cifrado en la nube. Ves logs verdes. Ves carpetas con fechas. Ves que el almacenamiento sube. Todo parece correcto. Luego llega el día malo y descubres que la base de datos no estaba consistente, que la clave de cifrado estaba en el servidor que acaba de morir, que el backup excluía justo la carpeta importante o que restaurar 800 GB por una línea de fibra doméstica no es exactamente una experiencia espiritual.
Por eso una prueba de restauración no es postureo. Es la diferencia entre “creo que podría recuperar esto” y “lo he hecho hace poco, tardé tanto, falló esto y sé por dónde empezar”.
No hace falta montar un simulacro militar. De hecho, si lo haces demasiado grande, no lo repetirás nunca. Mi enfoque es más bruto y más útil: elegir un servicio importante, restaurarlo en un entorno separado y comprobar que funciona sin tocar producción.
Qué intento demostrar#
Una prueba de restauración no tiene que demostrar que puedo reconstruir todo el homelab en una tarde. Eso está muy bien como fantasía, pero en casa casi nadie tiene tiempo, energía o documentación para hacerlo así.
Yo busco responder cuatro preguntas:
- ¿Puedo encontrar el backup correcto sin pensar demasiado?
- ¿Puedo descifrarlo o acceder a él si el servidor original no existe?
- ¿Puedo restaurar datos y configuración en una máquina limpia?
- ¿El servicio vuelve a funcionar con datos reales?
Si esas cuatro respuestas salen bien para los servicios importantes, duermo bastante mejor. Si una falla, prefiero descubrirlo un martes cualquiera que a las once de la noche con alguien preguntando por fotos, documentos o domótica.
La parte incómoda es que casi siempre aparece algo. Una ruta mal documentada, una variable de entorno que no estaba en Git, un token que no debería estar en el backup, un volumen con permisos raros, una versión de base de datos distinta. Es normal. La gracia de probar es encontrar esas pequeñas vergüenzas antes de que cobren intereses.
Elijo un servicio, no todo el castillo#
El error típico es querer probarlo todo. NAS, Proxmox, contenedores, bases de datos, fotos, documentos, DNS y media vida digital. Suena responsable, pero acaba siendo tan grande que no se hace.
Prefiero elegir un servicio por ronda. Uno. Si ese mes toca documentos, pruebo documentos. Si toca fotos, pruebo fotos. Si toca contraseñas, pruebo contraseñas con muchísimo cuidado y sin exponer datos reales más de lo necesario.
Para decidir, uso una clasificación simple:
- Crítico familiar: fotos, documentos, contraseñas, domótica básica, DNS si la casa depende de él.
- Importante personal: notas, repositorios, automatizaciones, dashboards, servicios de trabajo.
- Recreativo: multimedia, laboratorios, servicios que puedo reinstalar sin drama.
Los críticos familiares van primero. Lo demás puede esperar. Nadie en casa va a montar una revuelta porque un dashboard de métricas tarde dos días en volver. Si desaparecen fotos familiares o documentos escaneados, la cosa cambia bastante.
Mi prueba mínima viable#
La prueba más útil que hago tiene cinco pasos.
Primero, apunto el estado de partida. Qué servicio voy a restaurar, dónde vive, qué datos usa, qué base de datos tiene, qué volumenes necesita y cuál es el backup elegido. No escribo una novela. Basta una nota corta con fecha.
Segundo, preparo un destino limpio. Puede ser una VM temporal, un contenedor nuevo o una máquina de laboratorio. Lo importante es que no sea el servidor original. Restaurar encima del mismo sitio prueba menos de lo que parece, porque te deja dependencias ya resueltas sin darte cuenta.
Tercero, recupero datos y configuración desde backup. Aquí no vale copiar a mano desde producción. Si hago eso, estoy probando mi habilidad para hacer trampas, no el backup. Uso la misma ruta que usaría si el original estuviera muerto.
Cuarto, arranco el servicio aislado. Si necesita DNS, le doy un nombre temporal. Si necesita puertos, los cambio. Si puede enviar correos o notificaciones, lo desactivo antes. No quiero que una prueba de restauración empiece a mandar avisos reales o a pisar integraciones.
Quinto, valido con acciones concretas. Entrar en la interfaz no basta. Hay que abrir documentos, ver miniaturas, lanzar una búsqueda, comprobar usuarios, revisar permisos y leer logs. Un servicio puede levantar y estar medio roto.
Ese último punto es donde más cosas se cazan.
Qué mido de verdad#
No soy partidario de llenar esto de métricas absurdas. En una casa, el objetivo no es hacer una auditoría ISO. Pero hay tres datos que sí apunto siempre.
El primero es el tiempo hasta tener algo usable. No el tiempo total hasta dejarlo bonito. El tiempo hasta poder decir “los datos importantes están accesibles”. Ese número cambia mucho la percepción del riesgo. No es lo mismo restaurar un servicio en 20 minutos que en 7 horas.
El segundo es el tamaño real restaurado. Los backups pequeños engañan. Restaurar una base de datos de 2 GB no se parece a restaurar una biblioteca de fotos de 600 GB. Si hay muchos ficheros pequeños, peor todavía. El rendimiento cae y empiezan las sorpresas.
El tercero son los pasos manuales. Cada paso manual es una oportunidad para equivocarse cuando estás cansado. Si una restauración depende de recordar una opción rara, esa opción tiene que estar escrita. Si depende de un archivo local que solo existe en una máquina, ese archivo es un problema esperando turno.
Mi nota final suele tener este aspecto:
| |
Esto no es glamuroso. Funciona.
La clave de cifrado también forma parte del backup#
Aquí hay una trampa seria. Cifrar backups está muy bien, pero la clave de cifrado no puede vivir solo dentro del sistema que estás intentando proteger.
Parece obvio. Aun así, es de los fallos más fáciles de cometer. Tienes un script perfecto, un repositorio cifrado, una clave en una variable de entorno y todo funcionando. El servidor muere. La clave estaba en el servidor. Fin de la comedia.
Mi regla es que cualquier secreto necesario para restaurar tiene que estar accesible desde fuera del homelab principal, con protección razonable. Gestor de contraseñas, copia impresa guardada donde toque, almacenamiento externo cifrado o el método que encaje en cada casa. Lo importante es probarlo.
En una prueba real, intento responder esto sin mirar el servidor original:
- ¿Dónde está la clave?
- ¿Sé cuál es la buena?
- ¿Puedo usarla desde una máquina limpia?
- ¿Alguien de confianza podría encontrarla si yo no estoy?
La última pregunta incomoda un poco, pero es importante. Un homelab familiar no debería depender de que una sola persona recuerde una contraseña concreta en mitad de un mal día.
Bases de datos: donde los backups bonitos se rompen#
Los ficheros normales son agradecidos. Los copias, los restauras, compruebas permisos y suelen funcionar. Las bases de datos son menos simpáticas.
He visto demasiados montajes domésticos donde se hace backup del volumen de PostgreSQL, MariaDB o SQLite sin pensar en consistencia. A veces funciona. A veces no. Y el problema es que puede parecer que funciona hasta que intentas arrancar la aplicación.
Para servicios con base de datos prefiero tener un volcado lógico además del backup del volumen, sobre todo si el servicio importa. Un pg_dump, un dump de MariaDB o una exportación propia de la aplicación suelen ser más fáciles de mover entre versiones. No sustituyen siempre a una copia completa, pero salvan muchas restauraciones.
La prueba tiene que incluir la base de datos. No vale restaurar solo la carpeta de uploads. Si una app necesita base de datos y volumenes, restauro ambas cosas. Si no, estoy probando media aplicación.
También apunto la versión. Restaurar un dump viejo en una versión nueva suele ir bien. Restaurar datos de una versión nueva en una vieja puede ser un festival. Mejor saberlo antes.
El orden de recuperación importa#
Cuando algo se rompe de verdad, el orden evita perder tiempo. No todos los servicios merecen volver a la vez.
Mi orden doméstico sería algo así:
- Red básica y DNS mínimo.
- Acceso remoto o VPN si estoy fuera.
- Almacenamiento donde viven los backups.
- Contraseñas y documentación operativa.
- Fotos, documentos y servicios familiares.
- Automatizaciones y servicios secundarios.
- Multimedia, dashboards y laboratorio.
Esto cambia según cada casa, pero la idea es clara. Primero lo que permite arreglar lo demás. Luego lo que tiene valor real. Al final, lo prescindible.
La prueba de restauración también sirve para validar ese orden. A veces descubres que para restaurar un servicio necesitas otro que pensabas secundario. Por ejemplo, necesitas el DNS interno para resolver el NAS, o necesitas el gestor de contraseñas para entrar al panel donde están las claves del backup. Esa dependencia circular hay que romperla.
Una buena señal es poder restaurar usando nombres, rutas y secretos documentados fuera del sistema caído. Una mala señal es depender de memoria, autocompletado del shell y suerte.
Lo que suelo encontrar cuando pruebo#
Las pruebas de restauración rara vez fallan de forma espectacular. Fallan de formas pequeñas y pesadas.
Permisos de ficheros. Usuarios con UID distinto. Rutas absolutas que no existen en la máquina temporal. Variables de entorno que estaban en un .env no incluido en el backup. Configuraciones en la interfaz web que nadie exportó. Certificados que caducaron. Volúmenes con nombres distintos. Jobs que restauran datos, pero no restauran metadatos.
Nada de eso es dramático si lo encuentras en una prueba. Es una nota, una corrección y listo. En un incidente real, cada una de esas tonterías consume paciencia.
También aparece una categoría especial de basura: backups que llevan meses guardando algo inútil. Tareas verdes que copiaban una carpeta vacía. Scripts que cambiaron de ruta después de una migración. Exclusiones demasiado agresivas. Retención tan corta que justo lo necesario ya no estaba.
Por eso no me fío de los logs verdes. Los logs verdes son una pista, no una garantía.
Cómo lo documentaría sin montar burocracia#
La documentación buena de un homelab tiene que sobrevivir a dos enemigos: la pereza y el cansancio.
Si exige mantener diagramas perfectos, no durará. Si son cuatro notas claras, sí. Para cada servicio importante dejo un runbook pequeño:
- Qué datos hay que restaurar.
- Dónde están los backups.
- Qué secretos hacen falta.
- Qué comando o procedimiento inicia la restauración.
- Cómo comprobar que funciona.
- Qué hice la última vez que lo probé.
Con eso basta. No necesito literatura. Necesito que mi yo cansado pueda seguir pasos sin ponerse creativo.
También me gusta dejar una sección de “fallos conocidos”. No para recrearme en la miseria, sino porque los problemas se repiten. Si la última vez hubo que corregir permisos, probablemente vuelva a pasar. Si una app tarda diez minutos en regenerar índices, mejor saberlo antes de pensar que está rota.
Cada cuánto probar#
No hay una frecuencia universal. Depende de cuánto cambie tu homelab y de cuánto valor tengan los datos.
Mi regla razonable sería:
- Servicios críticos: una prueba parcial cada 3 o 4 meses.
- Servicios importantes: una vez al año o después de migraciones grandes.
- Servicios recreativos: cuando los toques o si te apetece.
También pruebo después de cambios que afecten a backups: cambiar NAS, mover datos, cambiar rutas, actualizar una base de datos grande, cambiar herramienta de copia o tocar cifrado. Ahí no espero al calendario.
La prueba no tiene que ser perfecta. Tiene que existir. Un simulacro pequeño hecho hoy vale más que un plan precioso que nunca se ejecuta.
Mi conclusión práctica#
Un backup no es una estrategia. Es una pieza de la estrategia. La restauración es donde se ve si esa pieza sirve.
Si tuviera que dejar una sola recomendación sería esta: esta semana elige un servicio importante, crea una máquina temporal y restáuralo sin mirar producción. Cronométralo. Apunta lo que falle. Arregla una cosa, no diez.
La primera prueba probablemente será incómoda. Mejor. Esa incomodidad es información. Lo preocupante no es encontrar problemas. Lo preocupante es no haberlos buscado nunca.
En un homelab, los backups no deberían ser decoración cara. Deberían ser una salida real. Y una salida real se abre de vez en cuando para comprobar que no está pintada en la pared.