Cuando se gestiona una infraestructura IT compleja, la estrategia de backup es una de las decisiones más críticas. No se trata solo de salvar los datos, sino de garantizar la continuidad operativa en caso de desastre. En un entorno de sala de máquinas, con cientos de VMs, bases de datos y configuraciones, la elección de la herramienta adecuada puede marcar la diferencia entre una recuperación rápida y una interrupción prolongada.
He querido poner a prueba dos de las herramientas de backup open-source más apreciadas: Restic y BorgBackup. El objetivo era entender cómo se comportan con un dataset significativo, simulando una situación real. Preparé un entorno con aproximadamente 2TB de datos heterogéneos, incluyendo discos virtuales, backups de bases de datos y archivos de configuración, para replicar los desafíos de un backup empresarial. Esta prueba no se centró solo en la velocidad del backup inicial, sino también en la eficiencia de la deduplicación, la velocidad de los backups incrementales y, fundamentalmente, la fiabilidad de la restauración. Los resultados destacaron puntos fuertes y débiles específicos para cada uno, que pueden guiar la elección según las necesidades reales de la infraestructura. Lee también: Proxmox Replica: WAN Lenta, RPO Bajo
Tested on: Debian 12 · Restic 0.16.2 · BorgBackup 1.2.7 · Agosto 2026
Requisitos Previos / Entorno de Prueba
Para la prueba, utilicé un servidor dedicado con las siguientes especificaciones:
- Sistema Operativo: Debian 12 (Bookworm)
- CPU: Intel Xeon E3-1270 v6 (4 Core, 8 Thread)
- RAM: 64GB DDR4
- Storage: 2x 4TB NVMe en RAID1 (para los datos de origen) y 1x 8TB HDD SATA (para el repositorio de backup)
- Dataset: 2TB de datos mixtos, compuestos por:
1.2TBde imágenes VM (qcow2, vmdk)500GBde volcados de bases de datos (PostgreSQL, MySQL)300GBde archivos de configuración, logs y documentos varios
Me aseguré de que los sistemas de archivos de origen y destino estuvieran montados con opciones estándar para evitar distorsiones en los benchmarks de I/O. El objetivo era simular un entorno de sala de máquinas con almacenamiento de alto rendimiento para los datos de origen y un almacenamiento más lento, pero de gran capacidad, para los backups, como suele ocurrir en las infraestructuras reales.
Restic: Características y Prueba con 2TB
Restic es conocido por su facilidad de uso y su arquitectura basada en contenidos que permite una deduplicación eficiente y backups incrementales rápidos. Su capacidad para gestionar repositorios en varios backends, incluyendo S3, SFTP y sistemas de archivos locales, lo hace extremadamente versátil.
Inicialización y Primer Backup
La inicialización del repositorio Restic fue inmediata. Creé un repositorio local en el disco HDD de 8TB.
restic init --repo /mnt/backup_resticEl primer backup, que involucró los 2TB de datos, tardó aproximadamente 8 horas y 30 minutos. Durante esta fase, Restic consumió una cantidad significativa de RAM, alcanzando picos de 12GB. Este es un aspecto a considerar para datasets muy grandes, donde la RAM disponible en el servidor de backup puede convertirse en un factor limitante. La deduplicación inicial redujo los 2TB a aproximadamente 1.8TB de datos efectivos en el repositorio. Lee también: PostgreSQL: Query Killer con pg_stat_statements
restic backup /data --repo /mnt/backup_restic --verboseBackups Incrementales y Rendimiento
Luego simulé modificaciones en los datos (añadiendo nuevos logs, modificando archivos de configuración y alterando pequeñas porciones de VMDK) para probar los backups incrementales. Aquí Restic brilló, completando los backups en un tiempo promedio de 15-20 minutos, con un consumo de RAM más contenido (aproximadamente 4-6GB). La velocidad fue impresionante, gracias a su capacidad para identificar y transferir solo los bloques de datos modificados.
BorgBackup: Características y Prueba con 2TB
BorgBackup es otra excelente herramienta de backup, célebre por su deduplicación a nivel de bloque y la encriptación integrada. Es particularmente apreciado por su eficiencia en el espacio y la capacidad de gestionar grandes cantidades de datos con un overhead mínimo una vez que el repositorio está estabilizado.
Inicialización y Primer Backup
También para BorgBackup, la inicialización del repositorio fue sencilla. Creé un repositorio en el mismo destino HDD.
borg init --encryption=repokey /mnt/backup_borgEl primer backup de los 2TB requirió aproximadamente 9 horas y 15 minutos, un tiempo ligeramente superior al de Restic. Sin embargo, la deduplicación fue superior: los 2TB de datos originales se redujeron a aproximadamente 1.5TB en el repositorio, un ahorro de espacio relevante en comparación con Restic en el primer full backup. Esta es una ventaja significativa para quienes tienen limitaciones de espacio de almacenamiento.
borg create --stats --progress /mnt/backup_borg::{hostname}-{now} /dataBackups Incrementales y Rendimiento
Los backups incrementales con BorgBackup tardaron en promedio 25-30 minutos, un poco más lentos que Restic, pero aun así muy eficientes. El consumo de CPU se mantuvo moderado, y la RAM utilizada fue inferior a la de Restic, situándose alrededor de los 2-3GB. Su robustez y la deduplicación agresiva lo hacen ideal para escenarios donde el espacio es un recurso valioso y los backups incrementales son menos frecuentes pero deben ser extremadamente eficientes.
Comparación Detallada y Resultados
La prueba reveló que ambas herramientas son válidas, pero sobresalen en escenarios diferentes. Aquí un resumen de los resultados principales:
| Característica | Restic | BorgBackup |
|---|---|---|
| Tiempo Primer Backup | ~8h 30min | ~9h 15min |
| Deduplicación Inicial | 2TB -> 1.8TB (10% ahorro) | 2TB -> 1.5TB (25% ahorro) |
| Tiempo Incr. | ~15-20 min | ~25-30 min |
| Consumo RAM (Pico) | ~12GB (primer backup), ~4-6GB (incremental) | ~3-5GB (primer backup), ~2-3GB (incremental) |
| Flexibilidad Backend | Alta (S3, SFTP, local, etc.) | Media (SSH, local) |
| Facilidad de Uso | Muy alta | Alta |
La elección entre Restic y BorgBackup depende de las prioridades. Si la velocidad de los backups incrementales y la simplicidad son lo primero, Restic es una opción sólida. Si la máxima eficiencia del espacio y una deduplicación superior son fundamentales, BorgBackup se distingue. Lee también: Honeypot Agosto: 7 Días, 1.200 Ataques SSH
Errores Comunes y Resolución de Problemas
Durante las pruebas, encontré algunos puntos que merecen atención:
- Consumo de RAM de Restic: Para datasets muy grandes, si el servidor de backup tiene RAM limitada, Restic puede agotar la memoria y fallar. Es posible mitigar este problema con la opción
--limit-uploado segmentando los backups, pero la mejor solución es tener RAM suficiente. - Consumo de CPU de BorgBackup: El primer backup de Borg puede ser intensivo para la CPU. Asegúrate de que el servidor tenga recursos suficientes o planifica el primer backup en horas de baja carga.
- Verificación de los Repositorios: Ambas herramientas ofrecen comandos para verificar la integridad del repositorio. Es fundamental ejecutarlos regularmente para asegurarse de que los backups sean recuperables. Un backup no verificado es un backup inexistente.
restic check --repo /mnt/backup_restic
borg check /mnt/backup_borg- Gestión de las Credenciales: Utilizar variables de entorno para las contraseñas de los repositorios (
RESTIC_PASSWORDoBORG_PASSPHRASE) es una práctica segura para la automatización, evitando escribirlas directamente en los scripts.
FAQ — Preguntas Frecuentes
¿Puedo usar Restic/BorgBackup en NAS o almacenamiento de red?
Sí, ambos soportan repositorios en almacenamiento de red a través de SSH (sftp) o protocolos cloud (S3 para Restic). Es fundamental asegurarse de que la conexión de red sea estable y suficientemente rápida para no comprometer los tiempos de backup y restauración. La latencia y el ancho de banda pueden influir significativamente en el rendimiento.
¿Cuál es la mejor herramienta para la recuperación de desastres?
Ambos son excelentes. Restic permite montar el repositorio como un sistema de archivos virtual, facilitando la recuperación de archivos individuales. BorgBackup ofrece una interfaz de línea de comandos robusta para extraer archivos o directorios. La elección depende de la preferencia personal y del flujo de trabajo de recuperación.
¿La encriptación integrada es segura?
Sí, ambos utilizan algoritmos de encriptación estándar de la industria (AES-256 en modo CTR para Restic, autenticado con HMAC-SHA256; AES-256 para BorgBackup). Es crucial proteger la frase de contraseña del repositorio, ya que sin ella los datos son irrecuperables. No es aconsejable confiar solo en estas encriptaciones para datos extremadamente sensibles, pero son un excelente primer nivel de protección.
¿Cómo puedo automatizar los backups y la limpieza de las snapshots antiguas?
Ambas herramientas se pueden integrar fácilmente en scripts bash o systemd timers. Es una buena práctica combinar el comando de backup con un comando de limpieza (por ejemplo, restic forget --prune o borg prune) para mantener el repositorio optimizado y cumplir con las políticas de retención. Lee también: ACN Incidente: Notificación en 24 Horas
Conclusiones con Puntos Clave Operativos
La elección entre Restic y BorgBackup no es universal, sino que depende de las necesidades específicas de tu entorno. Para una organización con 2.000 endpoints y más de 300 VMs, donde la velocidad de recuperación (RTO) y la frecuencia de los backups (RPO) son cruciales, la comprensión de sus diferencias es fundamental. Si necesitas backups incrementales extremadamente rápidos y una buena versatilidad de backends, Restic es una excelente solución, siempre y cuando tengas suficiente RAM. Si, por el contrario, la prioridad es la máxima eficiencia del espacio de almacenamiento y una deduplicación agresiva, BorgBackup ofrece una ventaja innegable, especialmente para archivos a largo plazo. El consejo operativo es siempre probar ambas herramientas con tu dataset real, monitorizando no solo los tiempos, sino también el uso de los recursos y, sobre todo, la capacidad de restaurar los datos de forma fiable. Un backup es útil solo si puede ser restaurado.
Actualizado: Agosto 2026
