Tuve una historia de amor y odio con los backups durante años. Amor porque siempre tenía la intención de montarlo bien. Odio porque cada solución que intentaba tenía algo que me echaba atrás: demasiado complicada, demasiado lenta, imposible de verificar, o que dejaba de funcionar en silencio durante semanas sin que yo me enterara.
Rsync para hacer copias de directorios. Duplicati con su interfaz web que prometía mucho y entregaba poco. Borg Backup, que es técnicamente excelente pero que tiene una curva de aprendizaje suficientemente pronunciada como para que lo dejara a medias dos veces.
Llevo usando Restic desde hace algo más de dos años. En ese tiempo no he perdido datos, he restaurado cosas tres o cuatro veces sin dramas, y el setup que tengo funcionando no me ha dado ningún problema que requiriera intervención manual. Para mí eso ya es un éxito.
Por qué Restic y no otra cosa#
La razón más práctica: Restic es un solo binario escrito en Go. No hay dependencias, no hay daemon que mantener, no hay base de datos que pueda corromperse. Lo copias a /usr/local/bin/ y funciona.
Lo segundo: los backups son incrementales por naturaleza. Restic divide los archivos en chunks (bloques de datos), les asigna un hash, y solo sube los chunks que no ha visto antes. El resultado es que el primer backup es lento y los siguientes son rápidos. Mucho más rápidos de lo que esperaría. En un directorio de 50 GB que cambia poco, una ejecución diaria me tarda entre 30 segundos y 2 minutos.
Lo tercero, y esto me parece importante: puedo verificar los backups. Restic tiene un comando check que valida la integridad del repositorio sin restaurar nada. Si algo está roto, me lo dice. Si todo está bien, me lo confirma. Nunca más confiar en que el backup “existe” sin saber si funciona.
Los destinos son otro punto fuerte. Restic soporta:
- Disco local o montaje NFS/SMB
- SFTP (cualquier servidor SSH)
- Amazon S3 y compatibles (MinIO, Backblaze B2, Wasabi)
- Azure Blob Storage
- Google Cloud Storage
- rclone como capa de abstracción para casi cualquier otra cosa
Eso significa que el mismo comando que uso para hacer backup local funciona cambiando solo la URL del repositorio si quiero mandarlo a un bucket S3.
Instalación#
En Debian/Ubuntu:
| |
O descargarlo directamente de GitHub si quieres la versión más reciente:
| |
Verificar:
| |
Inicializar un repositorio#
Un “repositorio” en Restic es el destino donde se guardan los backups. Hay que inicializarlo una vez antes de usarlo.
Para un repositorio local:
| |
Para un repositorio SFTP en otro servidor:
| |
Para Backblaze B2 (lo que yo uso para offsite):
| |
Restic pide una contraseña para cifrar el repositorio. Esta contraseña es crítica, si la pierdes los datos son irrecuperables. La guardo en Vaultwarden y también en un fichero de texto en un sitio diferente al backup.
El primer backup#
| |
Acepta múltiples rutas de origen. También puedo excluir cosas:
| |
Las exclusiones son importantes. En mi caso, los directorios de caché de Jellyfin pueden ocupar 20 GB y no me aporta nada hacer backup de ellos. Los genero solos cuando Jellyfin los necesita.
Ver los snapshots existentes#
Cada vez que ejecuto un backup, Restic crea un “snapshot”. Para listarlos:
| |
Muestra la fecha, el host origen, las rutas incluidas y un identificador único. Con ese ID puedo restaurar una versión específica.
Restaurar#
Restaurar todo un snapshot en una ruta específica:
| |
Restaurar solo un archivo o directorio concreto:
| |
Esto me ha salvado más de una vez. No para recuperarme de un desastre total, sino para recuperar un fichero de configuración que sobreescribí sin querer, o una base de datos de una aplicación antes de una migración que salió mal.
Automatizar con cron#
La parte que convierte Restic de herramienta interesante a sistema de backups real: ejecutarlo automáticamente.
Creo un script en /usr/local/bin/backup-homelab.sh:
| |
Lo hago ejecutable:
| |
Y lo añado al crontab del root para que se ejecute cada día a las 3 AM:
| |
| |
La política de retención#
El comando restic forget elimina snapshots según las reglas que le indiques. Las que uso yo:
--keep-daily 7: conservar el último snapshot de cada día de los últimos 7 días--keep-weekly 4: conservar el último snapshot de cada semana de las últimas 4 semanas--keep-monthly 6: conservar el último snapshot de cada mes de los últimos 6 meses
El resultado es que tengo acceso a cualquier punto en los últimos 7 días, cualquier semana de los últimos 4 meses, y cualquier mes de los últimos 6 meses. Para un homelab personal me parece más que suficiente.
El flag --prune es importante: sin él, forget solo marca los snapshots como eliminados pero no libera espacio en disco. Con --prune, elimina físicamente los datos huérfanos.
Múltiples destinos: estrategia 3-2-1#
Un solo backup no es suficiente. La regla 3-2-1 dice: tres copias de los datos, en dos medios distintos, uno fuera de casa.
Yo tengo:
- Datos originales en mi servidor principal (Phatt)
- Backup en NAS local (Synology DS1621+) via NFS
- Backup en Backblaze B2 (nube, fuera de casa)
Restic lo pone fácil porque puedo tener el mismo script apuntando a dos repositorios distintos. Ejecuto el backup al NAS cada noche y el backup a B2 cada semana. El incremental hace que el backup semanal a B2 sea rápido incluso con conexiones domésticas normales.
Para el repositorio B2, el script tiene variables de entorno adicionales:
| |
El coste de B2 para mis datos (unos 80 GB comprimidos y deduplicados) son céntimos al mes. Menos de un euro.
Monitorización#
El punto débil de cualquier sistema de backups: ¿cómo sabes si falló anoche?
Tengo dos capas de monitorización:
La primera es Uptime Kuma con un “heartbeat” monitor. Restic envía un ping a una URL de Uptime Kuma al final del script si todo fue bien:
| |
Si en 26 horas no llega el ping, Uptime Kuma me manda una notificación.
La segunda es revisar el log periódicamente. Nada automatizado, solo mirar /var/log/restic-backup.log de vez en cuando para ver que los tamaños de backup tienen sentido y que no hay errores raros.
Restauración real: la prueba de fuego#
Un backup que nunca has restaurado no es un backup, es una esperanza.
Cada mes hago una prueba de restauración de algún directorio en /tmp y verifico que los archivos están bien y que puedo abrirlos. Tarda cinco minutos y me da una tranquilidad que no tiene precio.
El comando de verificación de integridad del repositorio también ayuda:
| |
El flag --read-data-subset=10% verifica un 10% aleatorio de los datos reales en cada ejecución. Si lo ejecuto a diario en el cron, en 10 días ha verificado el 100% del repositorio sin dedicar tiempo de CPU y I/O excesivo en cada pasada.
Lo que no hace Restic (y cómo lo compenso)#
Restic no tiene interfaz web. No hay dashboard bonito. Para eso existe Restic Browser, que es una aplicación de escritorio que permite navegar repositorios de forma visual, pero yo no lo uso porque prefiero la línea de comandos para este tipo de tareas.
Tampoco gestiona la configuración de múltiples repositorios de forma centralizada. Si tienes cinco servidores haciendo backup a destinos distintos, necesitas organizar los scripts tú mismo o usar algo como Autorestic, que es una capa de configuración YAML por encima de Restic.
Para mi setup actual, con tres o cuatro servidores y dos destinos por servidor, me vale con tener los scripts ordenados en /usr/local/bin/ y documentados. No necesito más abstracción.
Alternativas que consideré#
Borg Backup: más antiguo y maduro, con deduplicación similar. La diferencia más práctica es que Borg requiere que el repositorio esté en un servidor con Borg instalado (no sirve cualquier destino). Restic es más flexible en ese sentido.
Duplicati: tiene interfaz web y es más sencillo de configurar para alguien no técnico, pero he visto demasiados casos de bases de datos corruptas y backups que parecían bien hasta que intentabas restaurar. Personalmente no me fío.
rclone: excelente para sincronización y para mover datos entre destinos en la nube, pero no hace deduplicación ni versionado. Es una herramienta diferente que se complementa bien con Restic (de hecho, puedes usar rclone como backend de Restic).
Mi configuración actual resumida#
Para quien quiera una referencia rápida de lo que tengo funcionando:
- Servidor principal (Phatt): backup diario de
/opt/appdata(configs y datos de servicios Docker) al NAS vía NFS - Servidores K3s: backup semanal de PVCs críticos (Vaultwarden, Gitea, bases de datos) al NAS
- Offsite: backup semanal desde NAS a Backblaze B2 (ejecutado desde el propio NAS con un script Restic)
- Retención local: 7 días / 4 semanas / 6 meses
- Retención offsite: 4 semanas / 12 meses
- Monitorización: heartbeat en Uptime Kuma por cada job
El tiempo que tardé en configurarlo todo fue un sábado por la mañana. El tiempo que le dedico al mantenimiento ahora es prácticamente cero, salvo las pruebas de restauración mensuales que me autoimpongo.
Si tienes un homelab y no tienes backups automatizados y verificados, Restic es donde yo empezaría. No porque sea la herramienta más potente, sino porque es la que más fácil resulta montar bien desde el principio y luego olvidarse de que existe.