Restic frente a BorgBackup: cuál elegir

Restic frente a BorgBackup, en un párrafo

Restic y BorgBackup realizan la misma tarea principal: copias de seguridad deduplicadas, cifradas e incrementales de un servidor Linux. La diferencia que determina la elección es dónde se almacenan las copias. Restic admite de forma nativa S3 y otras API de almacenamiento de objetos, por lo que un bucket es un destino de primera clase sin necesidad de instalar nada en el extremo remoto. Borg necesita que el programa borg esté instalado en la máquina que contiene el repositorio, porque un repositorio de Borg lo sirve un proceso, no un sistema de archivos ni una API. Si el destino es almacenamiento de objetos, esa diferencia ya resuelve la elección. Si el destino es otro equipo Linux que administra, Borg es una opción y suele ser más rápido.

El resto son diferencias menores. Ambos dividen los archivos mediante fragmentación basada en el contenido, por lo que un directorio de 40 GB cuyos cambios ocupan 200 MB carga aproximadamente 200 MB. Ambos cifran los datos en el cliente. Ambos montan una instantánea con FUSE (sistema de archivos en espacio de usuario), para que pueda copiar un archivo individual. En julio de 2026, restic está en la versión 0.19.1 y la serie estable de Borg es la 1.4, concretamente la 1.4.5. Borg 2.0 lleva años en fase beta y todavía está marcado solo como versión de prueba, por lo que actualmente debe implementar la versión 1.4.

El modelo del repositorio es la diferencia real

Un repositorio de restic es un directorio de archivos: config, keys/, snapshots/, index/ y data/, que contiene archivos pack. No se necesita nada más para leerlo. Por eso restic puede usar tantos backends. Cualquier almacenamiento que pueda escribir, leer, enumerar y eliminar blobs puede contener un repositorio de restic. Así, un único binario admite rutas locales, SFTP, su propio servidor REST, S3, Backblaze B2, Azure, Google Cloud Storage y cualquier destino al que pueda acceder rclone.

Un repositorio de Borg también está formado por archivos en disco, pero Borg nunca accede a él mediante un transporte sin funciones adicionales. Para un repositorio remoto, Borg inicia borg serve en el sistema remoto mediante SSH y se comunica con ese proceso usando su propio protocolo. El lado servidor realiza trabajo real: contiene el repositorio, aplica la transacción y responde a las consultas de índices. Por eso Borg no tiene backend para S3 y el proyecto no ha añadido uno. No hay ningún proceso que ejecutar dentro de un bucket.

Este único aspecto del diseño genera la mayoría de las diferencias prácticas siguientes.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Cifrado: uno de ellos se puede desactivar

Restic siempre está cifrado. No existe un modo sin cifrado. restic init solicita una contraseña, deriva una clave a partir de ella mediante scrypt y cifra y autentica todos los archivos pack escritos después. Si pierde la contraseña, los datos se pierden porque, por diseño, no existe ningún mecanismo de recuperación.

Borg permite elegir el cifrado al crear el repositorio, y la elección es permanente. borg init --encryption=repokey conserva la clave cifrada dentro del repositorio, por lo que la frase de contraseña por sí sola permite restaurar los datos. --encryption=keyfile conserva la clave en el cliente, en ~/.config/borg/keys/, por lo que quien robe el repositorio completo no podrá hacer nada. En este caso, debe hacer una copia de seguridad de ese archivo de clave por separado; de lo contrario, sus archivos de archivo no se podrán leer. Cada modo tiene una variante -blake2 que autentica con BLAKE2b en lugar de HMAC-SHA256. Es más rápida en hardware sin aceleración para SHA. --encryption=none también existe y es una opción válida cuando el repositorio se encuentra en un disco cifrado que usted controla.

Regla práctica: repokey-blake2 para una copia de seguridad normal del servidor, keyfile cuando el repositorio se encuentra en un lugar en el que no confía plenamente y nunca none en una máquina alquilada.

Compresión y por qué restic la incorporó tarde

Borg ofrece compresión desde el principio. El valor predeterminado es lz4, elegido porque es suficientemente rápido para mantenerlo activado en todo momento. zstd acepta los niveles 1 a 22 y usa 3 de forma predeterminada. zlib y lzma se utilizan cuando el tamaño importa más que el tiempo. auto aplica una heurística a cada bloque para no comprimir dos veces los datos que ya están comprimidos.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

Restic no ofrecía compresión hasta el formato de repositorio 2, que requiere restic 0.14.0 o una versión posterior. El formato 2 es ahora el predeterminado para los repositorios nuevos, y la compresión se configura con --compression usando los valores auto, off o max. Un repositorio antiguo con formato 1 permanece sin compresión hasta que se migra. Por tanto, si el repositorio de restic es anterior a 0.14 y nunca lo migraste, sigues usando el tamaño completo para el texto, los registros y los volcados de bases de datos.

Destinos remotos: S3 frente a SSH

Aquí suele tomarse la decisión.

Restic al acceder a S3 necesita credenciales en el entorno y no requiere que haya nada más en ejecución en ningún otro lugar. El mismo patrón funciona con un bucket que aloje usted mismo. Es una combinación habitual: ejecute MinIO para una API de S3 en su propio VPS y apunte restic a él.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Borg al acceder a un repositorio remoto necesita SSH y una instalación de Borg en el otro extremo. Además, la versión de ese extremo debe ser compatible con la del cliente. Esto supone una limitación si el otro extremo no está bajo su administración. No supone ningún problema si es un segundo servidor que ya administra. A cambio, ofrece el control más sólido contra el ransomware que cualquiera de las dos herramientas puede proporcionar: una clave SSH de solo adición. Obligue a la clave a ejecutar borg serve. El cliente podrá añadir archivos, pero no eliminarlos. Por tanto, una máquina comprometida no podrá borrar su propio historial.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Restic solo ofrece un equivalente cuando ejecuta su propio servidor REST, que admite un modo de solo adición. Con S3 estándar, puede obtener el mismo efecto mediante una política del bucket o el bloqueo de objetos. Esa función corresponde al proveedor, no a restic. Restrinja también el transporte. El acceso mediante SSH requiere la misma atención que cualquier otro inicio de sesión: aplique SSH con acceso exclusivo mediante clave y una entrada restringida en authorized_keys a la cuenta de copias de seguridad.

Velocidad: qué implica cada diseño

Ningún proyecto publica un benchmark que deba considerarse fiable para sus propios datos, así que conviene razonar a partir del mecanismo.

Borg sobre SSH es rápido en un enlace con latencia porque el servidor tiene capacidad de procesamiento. El cliente formula una consulta, el proceso remoto borg serve responde a partir del índice del repositorio y la transacción se confirma en un solo lugar. Las búsquedas de fragmentos no se convierten en viajes de ida y vuelta por la red para cada archivo pequeño.

Restic sobre almacenamiento de objetos no tiene procesamiento en el servidor, por lo que debe construir su estado a partir de archivos de índice y archivos pack que descarga mediante HTTP. Para mantener bajo control el número de solicitudes, agrupa muchos fragmentos pequeños en archivos pack más grandes antes de subirlos y mantiene una caché local en ~/.cache/restic para que la siguiente ejecución no tenga que volver a descargar todo el índice. Si se elimina esa caché, la siguiente copia de seguridad será lenta mientras la reconstruye. En un enlace de alta latencia con millones de archivos pequeños, este es el caso en el que restic parece más lento que Borg con los mismos datos.

En un disco local o en una LAN rápida, la diferencia se reduce principalmente y ambas herramientas terminan limitadas por la velocidad con la que pueden leer y calcular el hash del origen.

Bloqueo y copias de seguridad de varias máquinas

Borg 1.4 obtiene un bloqueo exclusivo del repositorio durante toda la operación. Dos clientes no pueden escribir en el mismo repositorio al mismo tiempo: el segundo espera y después falla porque se agota el tiempo de espera del bloqueo. El patrón admitido es usar un repositorio por cliente. Esto también significa que la deduplicación solo se realiza dentro del repositorio de una máquina. Por tanto, diez servidores casi idénticos almacenan diez copias del mismo sistema base.

Restic permite que varios clientes realicen copias de seguridad en el mismo repositorio al mismo tiempo, porque una copia de seguridad obtiene un bloqueo compartido y solo las tareas de mantenimiento, como prune, obtienen un bloqueo exclusivo. Diez servidores similares que usan un mismo repositorio de restic realizan la deduplicación entre sí. Por ello, el segundo servidor suele almacenar muy pocos datos. El coste es el alcance de una posible pérdida: hay una sola contraseña y un solo repositorio que contiene todo. Si se pierde la contraseña, se pierden los datos de los diez servidores.

Retención: olvidar y podar frente a podar y compactar

Ambas herramientas separan la decisión sobre qué conservar de la recuperación del espacio, y en ambas debes ejecutar el segundo paso.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

El problema es el mismo en ambas herramientas y conviene explicarlo claramente. En Borg, borg prune elimina archivos, pero por sí solo no libera espacio en disco. El espacio se recupera cuando se ejecuta borg compact. Por tanto, un trabajo de cron que poda y nunca compacta deja un repositorio que crece indefinidamente, aunque la lista de archivos siga siendo corta. En restic, forget sin --prune solo elimina las referencias a las instantáneas, y los datos permanecen hasta que se ejecuta una poda.

Ejecuta restic check después de podar. Verifica las estructuras del repositorio e indica si hay daños. Esto es mucho mejor que descubrirlos durante una restauración.

Restaurar es la única prueba que cuenta

Ambas herramientas montan una instantánea para que pueda explorarla. Es la forma más rápida de recuperar un archivo.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

Observe el formato de la ruta en borg extract. Las rutas dentro de un archivo comprimido se almacenan sin la barra inicial. Por eso etc/nginx es correcto, mientras que /etc/nginx no coincide con nada y no extrae nada. No se muestra ningún error que indique el motivo. La extracción también escribe en el directorio de trabajo actual. Cambie primero a un directorio temporal para no sobrescribir archivos activos con versiones antiguas.

Independientemente de la herramienta que elija, la programación solo cubre la mitad del trabajo. Ejecute periódicamente una restauración en un directorio temporal y supervise esa tarea. Hágalo igual que en la guía completa de copias de seguridad de restic para un VPS, la guía de copias de seguridad de restic para un VPS, que utiliza un temporizador de systemd.

Cuál gana para cada trabajo

Elige restic cuando el destino sea un almacenamiento de objetos, cuando quieras usar un solo binario y no instalar software en el extremo remoto, cuando varias máquinas deban deduplicar entre sí o cuando la persona que restaure los datos quizá no seas tú. Es un único binario estático al que se indica la URL de un repositorio, y eso es difícil de superar desde el punto de vista operativo.

Elige Borg cuando el destino sea un equipo Linux que controles, cuando el enlace tenga latencia y el conjunto de datos contenga millones de archivos pequeños, cuando quieras usar la clave SSH de solo adición como medida de protección contra ransomware o cuando quieras ajustar la compresión para cada trabajo. Es la herramienta más antigua, su serie estable avanza lentamente y, en el software de copias de seguridad, eso es una ventaja.

Ambas son respuestas correctas. La respuesta incorrecta es la que nunca pruebas. Si ya generas volcados de las aplicaciones, consérvalos: el patrón de la configuración de Nextcloud en Docker con volcados de la base de datos se aplica a cualquiera de las dos herramientas, porque un archivo de base de datos activo copiado en un momento aleatorio no constituye una copia de seguridad de la base de datos.

FAQ

¿Es más rápido restic o BorgBackup?

En un disco local o una LAN rápida, su rendimiento es similar y ambos terminan limitados por la velocidad de lectura y de cálculo de hashes en el origen. Borg suele ser más rápido a través de un enlace SSH de alta latencia con muchos archivos pequeños, porque un proceso borg serve en el extremo remoto responde a las consultas del índice sin requerir un viaje de ida y vuelta por la red para cada bloque. Restic suele ser más rápido cuando el destino es almacenamiento de objetos, al que Borg no puede acceder directamente.

¿Puede BorgBackup hacer copias de seguridad en S3 o Backblaze B2?

No directamente. Un repositorio de Borg lo sirve el proceso borg serve mediante SSH, y ningún proceso de ese tipo se ejecuta dentro de un bucket. Para sortear esta limitación, se puede montar el almacenamiento de objetos como un sistema de archivos con rclone, pero el proyecto Borg no lo recomienda, porque un montaje que se interrumpe durante una transacción puede dañar el repositorio. Si necesita almacenamiento de objetos, use restic.

¿Puedo ejecutar ambas herramientas con los mismos datos?

Sí, y algunas personas lo hacen: Borg en un segundo servidor para una restauración local rápida, y restic en almacenamiento de objetos para la copia externa. No comparten nada, por lo que se paga dos veces el coste de lectura y cálculo de hashes, y hay dos contraseñas que deben almacenarse de forma segura. Hágalo solo si ha probado ambas restauraciones.

¿Qué ocurre si pierdo la contraseña del repositorio?

Los datos no se pueden recuperar con ninguna de las dos herramientas. Restic deriva su clave de la contraseña mediante scrypt y no existe ningún método alternativo. En el modo repokey de Borg, la clave cifrada se almacena dentro del repositorio, por lo que basta la frase de contraseña para restaurar. En el modo keyfile también necesita el archivo de clave de ~/.config/borg/keys/. Guarde la contraseña en un gestor de contraseñas que no esté alojado en el servidor del que se hacen copias de seguridad, y exporte la clave de Borg con borg key export si usa keyfile.

¿Debo esperar a Borg 2.0?

No. En julio de 2026, Borg 2.0 todavía está en fase beta, en la versión 2.0.0b22, y el proyecto lo clasifica como destinado únicamente a pruebas. La serie estable es la 1.4, actualmente en la versión 1.4.5. Empiece ahora con la versión 1.4. Borg 2 cambia el formato del repositorio y ofrece una ruta de actualización documentada, por lo que empezar hoy no le dejará sin una vía de actualización.