Hay pocas frases más peligrosas en un homelab que “tengo backups”. Suena tranquilizadora. También puede no significar casi nada.
Puedes tener trabajos programados, logs verdes, notificaciones correctas, snapshots diarios, copias en el NAS y una nube barata recibiendo datos cada noche. Todo eso está muy bien. Pero hasta que restauras algo, lo que tienes es una teoría.
La copia puede estar incompleta. Puede guardar los archivos pero no los permisos. Puede tener la base de datos en un estado inútil. Puede depender de una contraseña que no recuerdas. Puede tardar seis horas cuando tú pensabas que serían veinte minutos. Puede restaurar perfecto, pero en una ruta que tu servicio no sabe usar. He visto suficientes backups “correctos” fallar en la restauración como para desconfiar por sistema.
Por eso me gusta hacer comprobaciones post-backup con una muestra pequeña. No hace falta restaurar todo cada semana. Hace falta restaurar algo concreto, leerlo, abrirlo y confirmar que sirve.
El backup no termina cuando acaba el job#
Un trabajo de backup terminado solo responde a una pregunta: ¿el proceso ha copiado algo sin declarar error?
No responde a preguntas más importantes:
- ¿Está todo lo necesario?
- ¿Se puede desencriptar?
- ¿Se puede restaurar en otra máquina?
- ¿Los permisos son correctos?
- ¿La aplicación arranca con esos datos?
- ¿Cuánto tarda la recuperación?
- ¿Qué pasos dependen de memoria humana?
En un homelab doméstico esto importa más de lo que parece. No estamos protegiendo solo contenedores bonitos. A veces hay fotos familiares, documentos, facturas, configuraciones de casa, bases de datos de servicios internos y años de pequeñas decisiones acumuladas.
Cuando algo se rompe, la pregunta no es “¿teníamos una tarea de backup?”. La pregunta es “¿cuándo volvemos a estar de pie y qué hemos perdido?”.
Qué restauraría como muestra#
No elegiría una muestra al azar. Restauraría piezas que representen riesgos distintos.
Para fotos, escogería una carpeta pequeña con varios tipos de archivo: imágenes recientes, algún vídeo corto, metadatos y quizá una estructura con subcarpetas. No basta con ver que los nombres aparecen. Hay que abrir archivos y comprobar que no están corruptos.
Para documentos, probaría PDFs, escaneos, algún archivo ofimático y una carpeta con permisos normales. Aquí busco que la restauración conserve nombres, fechas razonables y estructura. Si el sistema usa OCR o etiquetas, revisaría si esos metadatos viven en archivos, en una base de datos o en ambos sitios.
Para servicios con base de datos, restauraría una copia en un entorno temporal. No hace falta exponerlo ni dejarlo perfecto. Quiero saber si PostgreSQL, MariaDB o SQLite vuelven a un estado legible. Un dump que se genera cada noche pero no importa correctamente vale bastante poco.
Para configuraciones, restauraría un par de archivos críticos y confirmaría que coinciden con lo esperado. Reverse proxy, DNS interno, compose files, variables sin secretos publicados, plantillas de despliegue y notas operativas. Aquí la pregunta es si podría reconstruir el servicio sin ir de memoria.
Para backups cifrados, probaría la contraseña o la clave. Esto parece obvio hasta que no lo es. Una copia cifrada cuya clave solo existe en el servidor muerto es decoración cara.
Mi rutina razonable#
No convertiría esto en una auditoría ISO casera. La gracia es que sea sostenible.
Una rutina mensual me parece suficiente para muchos homelabs familiares:
- Elegir un backup reciente.
- Restaurar una muestra pequeña en una ruta temporal.
- Abrir varios archivos reales.
- Levantar una base de datos pequeña si aplica.
- Comprobar permisos básicos.
- Medir tiempo aproximado.
- Borrar la restauración temporal.
- Anotar resultado y cualquier sorpresa.
Cada trimestre haría una prueba algo más seria con un servicio completo. Por ejemplo, restaurar una instancia de Paperless-ngx, Immich, Vaultwarden o el servicio que más miedo te daría perder. No hace falta hacerlo en producción. De hecho, prefiero hacerlo en una VM temporal o en una máquina de laboratorio.
Lo importante es que la prueba no dependa de una tarde épica. Si validar backups exige montar medio datacenter doméstico, no lo vas a hacer. Tiene que ser pequeño, repetible y aburrido en el buen sentido.
Lo que suele fallar#
El primer fallo típico es copiar volúmenes sin parar o preparar la aplicación. Algunas apps toleran bien copias en caliente. Otras no. Las bases de datos, en particular, merecen respeto. Copiar el directorio de datos mientras escribe puede dejarte una copia que parece completa y luego no arranca.
El segundo fallo son permisos y propietarios. Restauras archivos, pero el contenedor no puede leerlos. O puede leerlos, pero no escribir. O el usuario dentro del contenedor no coincide con el del host. Esto no siempre se ve mirando el tamaño de la copia.
El tercer fallo son rutas absolutas. El backup restaura en una ubicación distinta y de repente todo apunta al sitio viejo. En servicios pequeños se arregla rápido. En un conjunto de contenedores con volúmenes cruzados puede volverse pesado.
El cuarto fallo son secretos fuera del backup. Variables de entorno, claves, tokens, certificados, usuarios, contraseñas de base de datos. No digo que haya que meter secretos en cualquier copia sin pensar. Digo que hay que saber dónde están y cómo se recuperan.
El quinto fallo es confiar en un único formato. Snapshots, repositorios incrementales, dumps y copias de archivos resuelven problemas distintos. Si solo tienes snapshots locales, no estás cubierto frente a pérdida del equipo. Si solo tienes dumps de base de datos, quizá te falta el volumen de ficheros.
Restaurar no es volver a producción#
Una prueba de restauración no tiene que sustituir el servicio real. De hecho, casi nunca debería tocar producción.
Yo prefiero restaurar en una zona aislada:
- una carpeta temporal en el NAS
- una VM de laboratorio
- un contenedor con puertos no publicados
- una red interna separada
- un nombre local distinto
La meta es validar datos, no hacer una migración real cada mes.
Por ejemplo, si pruebo un servicio con base de datos, puedo restaurar el dump, arrancar la aplicación con una copia del volumen y entrar con un usuario de prueba. No necesito que lo use nadie. Necesito ver que los datos tienen sentido.
Para fotos o documentos, el test puede ser más simple. Restaurar una carpeta, abrir diez archivos, comprobar fechas y borrar. Si el backup es cifrado e incremental, además confirmo que puedo listar versiones antiguas.
Tiempo de recuperación: el dato que casi nadie mide#
Hay una diferencia grande entre “puedo restaurarlo” y “puedo restaurarlo en un tiempo aceptable”.
Un backup en la nube puede ser perfecto y aun así tardar días si tienes terabytes y una conexión doméstica normal. Un NAS local puede restaurar rápido, pero no ayudarte si el problema es eléctrico, robo, incendio o error humano replicado. Un disco USB puede ser útil, pero quizá no está actualizado.
Por eso conviene medir tiempos aproximados.
No hace falta cronometrar con precisión ridícula. Basta con saber órdenes de magnitud:
- restaurar configuración crítica: minutos
- restaurar una base de datos pequeña: minutos
- restaurar documentos importantes: minutos u horas
- restaurar una biblioteca de fotos grande: horas o días
- reconstruir un servidor entero: depende de documentación y automatización
Este dato cambia decisiones. Quizá descubres que la copia externa está bien para desastre total, pero no para recuperar rápido una app diaria. Quizá necesitas una copia local más reciente. Quizá un servicio que creías crítico puede esperar.
Qué anoto después de cada prueba#
La documentación mínima gana aquí.
Después de una prueba, anoto:
- fecha de la prueba
- origen del backup
- qué muestra restauré
- dónde la restauré
- si pude abrir datos reales
- cuánto tardó
- problemas encontrados
- cambio pendiente, si lo hay
No hace falta una plataforma enorme. Un markdown en el repositorio privado, una nota en el NAS o una página interna valen. Lo que no vale es “me acordaré”. Nadie se acuerda cuando se rompe algo a las once de la noche.
También me gusta guardar una lista de “primeros servicios a recuperar”. En una casa, el orden importa. Primero red, DNS, acceso y datos críticos. Luego paneles, automatizaciones y juguetes. Si no priorizas antes, lo harás bajo presión y peor.
Automatizar sin perder el contacto manual#
Automatizar comprobaciones está bien. Puedes lanzar un job que liste snapshots, verifique checksums, pruebe un repositorio, restaure un archivo pequeño y mande una alerta si algo falla. Eso ayuda mucho.
Pero mantendría una parte manual de vez en cuando. Abrir un PDF restaurado. Ver una foto. Entrar en una app levantada desde copia. Leer una tabla de base de datos. Hay fallos que un check automático no ve si no está muy bien diseñado.
La automatización responde “el proceso técnico pasó”. La revisión humana responde “esto me serviría si mañana se rompe”.
Para un homelab familiar, esa segunda pregunta pesa bastante.
Ejemplo práctico de política doméstica#
Una política razonable podría ser:
- Backups diarios de servicios y datos importantes.
- Snapshots locales frecuentes para errores pequeños.
- Copia externa cifrada para desastre serio.
- Restauración mensual de muestra.
- Restauración trimestral de un servicio completo.
- Revisión anual de qué datos siguen siendo críticos.
No es perfecto. Es mantenible.
La perfección en backups suele morir por abandono. Diseñas algo precioso, con demasiadas piezas, demasiadas excepciones y demasiados pasos. Luego pasan tres meses y nadie lo mira. Prefiero una política menos ambiciosa que realmente se ejecuta y se prueba.
Mi opinión final#
Un backup sin prueba de restauración es una tranquilidad barata. A veces funciona. A veces no. El problema es que lo descubres el peor día posible.
Restaurar una muestra pequeña cambia la relación con tus copias. Te obliga a mirar permisos, claves, tiempos, rutas, documentación y dependencias. Te enseña qué parte del sistema está protegida en serio y qué parte vive de suposiciones.
Si solo haces una mejora este mes en tu homelab, haría esta: elige un backup reciente, restaura una carpeta pequeña y abre los archivos. Luego restaura una base de datos de algún servicio menor. Si todo va bien, perfecto. Si algo falla, mejor enterarse hoy que cuando las fotos familiares o los documentos importantes dependan de esa copia.
Los backups buenos no presumen. Restauran.