El backup que no miras no es un backup. Es una apuesta.
Y lo peor es que casi siempre parece una apuesta ganada. Ves tareas verdes, logs sin gritos, un repositorio que crece, snapshots con nombres bonitos y un dashboard que transmite calma. Hasta que llega el día de restaurar y descubres que llevabas tres meses copiando una carpeta equivocada, que la base de datos no era consistente o que el destino remoto aceptaba datos pero no conserva lo que tú creías.
Me ha pasado en versiones pequeñas. No el incendio total, por suerte, pero sí el susto suficiente para dejar de confiar en el “si el cron no ha fallado, estará bien”. Esa frase es una trampa. El cron solo te dice que algo se ejecutó. No te dice que puedas volver a la vida.
En un homelab doméstico, los backups tienen otro matiz. No solo proteges servidores. Proteges fotos, documentos, configuraciones, contraseñas, domótica, proyectos personales y a veces cosas de trabajo. Algunas se pueden reconstruir. Otras no. Y esa diferencia debería mandar más que la herramienta de moda.
Por eso mi sistema ideal no empieza eligiendo Restic, Borg, Proxmox Backup Server, ZFS snapshots o rsync. Empieza con una pregunta más incómoda: ¿qué necesito recuperar primero si todo se rompe mañana?
no todo merece el mismo backup#
La primera mejora real que hice fue dejar de tratar todos los datos igual.
Hay datos irremplazables. Fotos familiares, vídeos personales, documentos legales, archivos de trabajo, exports de contraseñas guardados con cuidado, notas propias y cualquier cosa que no puedas volver a descargar ni recrear.
Hay datos importantes pero reconstruibles. Configuraciones de servicios, bases de datos de apps, repositorios Git, dashboards, automatizaciones, stacks Docker, plantillas de máquinas, documentación interna.
Y hay datos cómodos pero no críticos. Cachés, descargas, bibliotecas reconstruibles, ISOs, thumbnails, transcodes, logs viejos y todo lo que duele perder pero no cambia tu vida.
Si mezclo esas tres capas, acabo haciendo backups enormes, lentos y difíciles de verificar. Luego no miro nada porque mirar todo da pereza. Mal negocio.
Prefiero separar.
Las fotos y documentos van con prioridad máxima. Quiero más de una copia, una fuera de la máquina principal y alguna fuera de casa o fuera del mismo dominio de fallo.
Las configuraciones van con backup frecuente y restauración fácil. Aquí importa más poder levantar servicios que conservar cada log.
Los datos reconstruibles pueden tener una política más relajada. No quiero llenar discos duplicando basura solo para sentirme prudente.
Esta clasificación baja mucho el ruido. Y con menos ruido, sí miro los backups.
mi regla: backup sin restauración probada no cuenta completo#
Un backup solo demuestra que sabes escribir datos. Una restauración demuestra que sabes volver.
No hace falta restaurar todo cada día. Tampoco hay que montar una ceremonia mensual con velas negras y tres terminales. Pero sí quiero pruebas periódicas.
Para servicios pequeños, la prueba puede ser muy simple. Recuperar un fichero de configuración al azar. Restaurar una base de datos en un contenedor temporal. Montar un snapshot en solo lectura. Sacar un archivo de un repositorio remoto y comprobar checksum. Levantar una VM desde backup en una red aislada.
La prueba cambia según el tipo de dato, pero el principio es el mismo: no basta con que exista una copia. Quiero tocarla.
En Proxmox Backup Server, por ejemplo, me interesa ver que los backups terminan bien, pero también que puedo restaurar una VM o al menos navegar el contenido. En ZFS, un snapshot local es comodísimo para volver atrás rápido, pero no me protege si muere el pool. En Restic o Borg, un check del repositorio ayuda, pero no sustituye una extracción de prueba. En bases de datos, copiar el directorio de datos en caliente puede ser una receta estupenda para fabricar basura consistente.
La restauración de prueba tiene otra ventaja: obliga a documentar. Si no puedes explicar cómo vuelves, probablemente no sabes volver.
las comprobaciones que automatizo#
No me interesa recibir veinte alertas. Me interesa recibir las dos que importan.
Mis comprobaciones mínimas para backups son estas:
- Que la tarea se ejecutó en la ventana esperada.
- Que terminó bien.
- Que el tamaño no es sospechosamente pequeño.
- Que el número de versiones recientes tiene sentido.
- Que el destino tiene espacio suficiente.
- Que puedo listar el repositorio o snapshot.
- Que una restauración pequeña funciona cada cierto tiempo.
El tamaño sospechoso es más útil de lo que parece. Si una copia diaria suele pesar varios gigas y de repente pesa 12 MB, algo cambió. Puede ser normal. Puede ser que estés copiando una carpeta vacía. Ese tipo de fallo a veces no rompe la tarea. Solo rompe tu futuro.
También miro la edad del último backup bueno. No la edad del último intento. Son cosas distintas. Una tarea puede ejecutarse cada noche y fallar cada noche. Si el dashboard solo enseña actividad, engaña.
Para bases de datos, quiero dumps con fecha y alguna comprobación básica. En PostgreSQL o MariaDB, un dump que no se puede restaurar no vale mucho. No necesito restaurarlos todos cada día, pero sí uno de vez en cuando en un entorno temporal.
Para carpetas importantes, me gusta tener checksums o al menos pruebas de lectura. Los discos no siempre fallan con fuegos artificiales. A veces fallan como funcionarios cansados: siguen ahí, pero cuando les pides algo concreto empiezan las excusas.
alertas útiles, no ruido doméstico#
Una alerta que se dispara todos los días acaba siendo decoración.
En casa quiero alertas con criterio. Si falla un backup crítico, avisa. Si el destino baja de cierto espacio, avisa. Si no hay backup bueno en 48 horas para datos importantes, avisa. Si una restauración de prueba falla, avisa con mala leche.
Pero si una copia secundaria de datos reconstruibles se retrasa una hora, quizá no hace falta despertar a nadie. El homelab ya tiene suficientes formas de pedir atención.
También prefiero alertas que digan qué hacer. “Backup fallido” está bien para empezar. Mejor es “backup de documentos falló, último bueno hace 3 días, destino accesible, error de permisos”. No siempre se puede automatizar tanto, pero cuanto más contexto llegue en el mensaje, menos tiempo pierdo abriendo paneles.
Un sistema de alertas bueno reduce ansiedad. Uno malo la aumenta. Si cada notificación exige una investigación completa, el sistema está trabajando para sí mismo, no para ti.
snapshots no son backups, pero los quiero cerca#
Los snapshots son maravillosos para errores rápidos.
Borras una carpeta por accidente. Actualizas una app y se rompe. Cambias una configuración y quieres volver. Ahí un snapshot local es una bendición. Rápido, barato y cómodo.
Pero no lo llamo backup completo. Si el pool muere, el snapshot muere con él. Si el servidor arde, el snapshot se apunta al plan. Si alguien borra snapshots, adiós. Si hay corrupción replicada, quizá acabas conservando el problema con mucho orden.
Mi uso ideal es combinar:
- Snapshots locales para vuelta rápida.
- Backups en otra máquina para fallo del servidor.
- Copia externa para desastre de casa.
- Restauraciones de prueba para no vivir de fe.
Esto suena más pesado de lo que es si separas prioridades. No todo necesita las cuatro capas. Las fotos familiares sí. La caché de un servicio no.
el documento de recuperación#
Una parte absurda y muy útil: tener escrito qué hacer.
No una novela. Una nota corta.
Qué se recupera primero. Dónde están las copias. Qué credenciales hacen falta. Qué comando o procedimiento uso para restaurar. Qué servicios dependen de otros. Qué puedo ignorar hasta mañana.
El día que todo se rompe no estás fino. Estás cansado, cabreado y con ganas de ir rápido. Ahí la documentación no tiene que impresionar a nadie. Tiene que evitar decisiones tontas.
Mi orden típico sería:
- Red básica y DNS.
- Acceso remoto.
- Gestor de contraseñas o copia de emergencia.
- Documentos y fotos.
- Home Assistant si afecta a la casa.
- Servicios de trabajo.
- Medios y servicios cómodos.
El orden real depende de cada casa, pero tenerlo pensado antes cambia mucho. Sin lista, todo parece urgente. Con lista, algunas cosas esperan.
qué errores intento evitar#
El primero es guardar backups en el mismo sitio que los datos. Parece obvio hasta que miras muchas instalaciones caseras. Un directorio llamado backups en el mismo disco no es una estrategia. Es optimismo con path propio.
El segundo es no separar secretos. Un backup cifrado cuya clave solo existe dentro del servidor que ha muerto tiene un punto cómico bastante oscuro. Las claves de recuperación necesitan su propia estrategia.
El tercero es automatizar borrados sin margen. La retención está bien, pero si un fallo lógico empieza a generar copias malas y tu política borra las buenas demasiado rápido, puedes perder el único punto sano. Me gusta conservar ventanas razonables, sobre todo en datos importantes.
El cuarto es olvidar aplicaciones con base de datos. Copiar volúmenes Docker puede funcionar para algunas cosas, pero no me fío por defecto. Si hay base de datos, quiero dump o procedimiento recomendado.
El quinto es no mirar permisos. Restaurar archivos y descubrir que la app no puede leerlos es una pérdida de tiempo evitable.
una política razonable para casa#
Si tuviera que dejar una política simple, sería esta.
Datos irremplazables: copia local, copia en otro equipo y copia externa. Verificación automática y restauración de prueba periódica.
Servicios importantes: backup de configuración, backup de base de datos, nota de restauración y prueba ocasional en entorno temporal.
VMs críticas: backup completo, snapshot antes de cambios grandes y prueba de arranque cada cierto tiempo.
Servicios prescindibles: export de configuración o docker compose guardado en Git. Si se pierden datos, se reconstruyen.
Media reconstruible: backup solo si el coste de reconstruir compensa. A veces no compensa y pasa nada.
La parte difícil no es técnica. Es aceptar que no todo merece protección máxima. Si intentas protegerlo todo igual, acabarás protegiendo mal lo importante.
mi conclusión#
Los backups buenos son aburridos. Eso es señal de salud.
No necesito un dashboard espectacular. Necesito saber que anoche se copiaron los datos importantes, que el destino no está lleno, que el repositorio se puede leer, que una restauración pequeña funciona y que si mañana se muere una máquina no tengo que improvisar desde cero.
La herramienta importa, pero menos que el hábito. Restic, Borg, Proxmox Backup Server, ZFS, rsync o una combinación de varias pueden funcionar. Lo que no funciona es confiar en tareas verdes que nadie revisa.
Mi objetivo no es tener muchos backups. Es tener backups que pueda usar.
Y eso cambia la mentalidad. Dejas de coleccionar copias y empiezas a diseñar salidas. En homelab, esa diferencia vale más que cualquier plugin bonito.