Restic o BorgBackup: cuál usar para tus copias

Restic frente a BorgBackup, en un solo párrafo

Restic y BorgBackup realizan la misma tarea principal: copias de seguridad incrementales, cifradas y con deduplicación de un servidor Linux. La diferencia que determina la elección es el destino de la copia de seguridad. Restic admite de forma nativa S3 y otras API de almacenamiento de objetos, por lo que un bucket es un destino de primer nivel sin instalar nada en el extremo remoto. Borg necesita tener instalado el programa borg 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 un almacenamiento de objetos, esa diferencia resuelve la elección. Si el destino es otro equipo Linux que administra, Borg es una opción válida y a menudo más rápida.

El resto son diferencias menores. Ambos dividen los archivos mediante fragmentación definida por el contenido, por lo que un directorio de 40 GB que haya cambiado en 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 figura sólo como versión de pruebas, por lo que hoy debe implementar la versión 1.4.

La diferencia real está en el modelo de repositorio

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 funcionar con tantos backends. Cualquier almacenamiento que permita guardar, obtener, listar y eliminar blobs puede alojar 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 pasivo. En un repositorio remoto, Borg inicia borg serve en el otro extremo mediante SSH y utiliza su propio protocolo para comunicarse con ese proceso. El lado servidor realiza trabajo real: mantiene el repositorio, aplica la transacción y responde a las consultas sobre los índices. Por eso Borg no tiene un backend S3 y el proyecto no ha añadido uno. No hay ningún proceso que ejecutar dentro de un bucket.

Este único hecho de diseño explica la mayoría de las diferencias prácticas que se indican a continuación.

# 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 cifra los datos. No tiene 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 que se escriben 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 mantiene la clave cifrada dentro del repositorio, por lo que la frase de contraseña por sí sola permite restaurar los datos. --encryption=keyfile mantiene la clave en el cliente, en ~/.config/borg/keys/, de modo que quien robe el repositorio completo no obtiene nada; por tanto, debe hacer una copia de seguridad de ese archivo de clave por separado o sus archivos dejarán de ser legibles. 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 administra.

La regla práctica es la siguiente: repokey-blake2 para una copia de seguridad normal del servidor, keyfile cuando el repositorio se encuentra en una ubicación en la que no confía plenamente y nunca none en una máquina alquilada.

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

Borg incluye compresión desde el principio. La opción predeterminada es lz4, porque es suficientemente rápida para mantenerla activada en todo. zstd acepta los niveles del 1 al 22 y usa 3 de forma predeterminada. zlib y lzma son útiles cuando el tamaño importa más que el tiempo. auto aplica una heurística a cada bloque para no volver a comprimir los datos que ya están comprimidos.

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

Restic no tuvo 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 sigue sin compresión hasta que se migra. Por tanto, si el repositorio de restic es anterior a 0.14 y nunca lo migró, sigue ocupando el tamaño completo para el texto, los registros y los volcados de bases de datos.

Destinos remotos: S3 frente a SSH

Aquí es donde normalmente se toma la decisión.

Para que restic acceda a S3 necesita credenciales en el entorno y no requiere que haya ningún otro proceso en ejecución. El mismo patrón funciona con un bucket que aloje usted mismo. Es una combinación habitual: ejecute MinIO para ofrecer una API 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

Para que Borg acceda a un repositorio remoto necesita SSH y una instalación de Borg en el sistema remoto. Además, la versión remota debe ser compatible con la del cliente. Esto supone una limitación si el sistema remoto no está bajo su control. No supone ningún problema si es un segundo servidor que ya administra. A cambio, ofrece la protección más sólida contra ransomware que proporciona cualquiera de las dos herramientas: una clave SSH de sólo anexado. Haga que la clave ejecute borg serve. Así, el cliente puede añadir archivos, pero no puede eliminarlos, por lo que un equipo comprometido no puede borrar su propio historial.

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

Restic sólo ofrece un equivalente cuando se ejecuta su propio servidor REST, que admite un modo de sólo anexado. Con S3 sin más, puede obtener el mismo efecto mediante una política de bucket o el bloqueo de objetos. Esa función corresponde al proveedor, no a restic. Restrinja también el transporte, porque el acceso SSH requiere la misma protecció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: implicaciones de cada diseño

Ningún proyecto publica una prueba de rendimiento que deba considerar válida para sus propios datos. Por tanto, razone a partir del mecanismo.

Borg sobre SSH es rápido en una conexión con latencia porque el lado del servidor es inteligente. El cliente envía 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 un viaje de red por cada archivo pequeño.

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

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

Bloqueo y copias de seguridad de varias máquinas

Borg 1.4 adquiere un bloqueo exclusivo sobre el 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 por agotarse el tiempo de espera del bloqueo. El patrón compatible es usar un repositorio por cliente. Esto también significa que la deduplicación sólo se realiza dentro del repositorio de una máquina, por lo que diez servidores casi idénticos almacenan diez copias del mismo sistema base.

Restic permite que varios clientes realicen copias de seguridad en un mismo repositorio al mismo tiempo, porque una copia adquiere un bloqueo compartido y sólo las tareas de mantenimiento, como prune, adquieren uno exclusivo. Diez servidores similares que apunten a un mismo repositorio de restic se deduplican entre sí, y el segundo servidor suele almacenar muy pocos datos adicionales. El coste es el alcance del incidente: 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 «decidir qué conservar» de «recuperar el espacio», y en ambas debe 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

La trampa es la misma en ambas herramientas y conviene explicarla claramente. En Borg, borg prune elimina archivos, pero no libera espacio en disco por sí solo. El espacio se recupera cuando se ejecuta borg compact. Por tanto, una tarea de cron que poda y nunca compacta deja un repositorio que crece indefinidamente mientras la lista de archivos se mantiene corta. En restic, forget sin --prune sólo elimina las referencias a las instantáneas, y los datos permanecen hasta que se ejecuta una poda.

Ejecute restic check después de podar. Este comando verifica las estructuras del repositorio e indica si algo está dañado. Es mucho mejor que descubrirlo durante una restauración.

Restaurar: la única prueba que cuenta

Ambas herramientas montan una snapshot para que pueda examinarla. 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 explique 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.

Que una restauración termine sin errores no demuestra que sea correcta. La aplicación tiene su propio criterio para determinar si una restauración está completa. Por ejemplo, un servidor Immich reconstruido a partir de una copia del directorio de datos de Postgres puede recuperar todas las fotos en el disco, pero mostrar una línea de tiempo vacía. Ese es precisamente el problema que la copia de seguridad y restauración de Immich debe resolver.

Independientemente de la herramienta que elija, la programación sólo cubre la mitad del trabajo. Ejecute periódicamente una restauración en un directorio temporal que realmente supervise, igual que hace el tutorial completo de la guía de copias de seguridad de restic para un VPS mediante un temporizador de systemd.

Qué opción conviene para cada trabajo

Elija restic cuando el destino sea un almacenamiento de objetos, cuando quiera usar un único 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 pueda no ser usted. Es un único binario estático que usa una URL para acceder al repositorio, y eso es difícil de superar desde el punto de vista operativo.

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

Ambas son opciones correctas. La opción incorrecta es la que nunca prueba. Si ya genera volcados en el nivel de la aplicación, consérvelos: 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 copiar un archivo de base de datos activa en un momento aleatorio no equivale a hacer un backup de la base de datos.

FAQ

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

En un disco local o una LAN rápida, el rendimiento es similar y ambos terminan limitados por la velocidad de lectura y de cálculo de hashes del origen. Borg suele ganar a través de un enlace SSH con mucha latencia y una gran cantidad de archivos pequeños, porque un proceso borg serve en el extremo remoto responde a las consultas del índice sin requerir un viaje de red por cada bloque. Restic suele ganar cuando el destino es un 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 ofrece el proceso borg serve mediante SSH, y ningún proceso de ese tipo se ejecuta dentro de un bucket. Una solución habitual consiste en 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 restauraciones locales rápidas y restic en el almacenamiento de objetos para la copia externa. No comparten nada, por lo que paga dos veces el coste de lectura y cálculo de hashes, y debe almacenar dos contraseñas de forma segura. Hágalo sólo si ha probado ambas restauraciones.

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

Los datos son irrecuperables con ambas herramientas. Restic deriva su clave de la contraseña mediante scrypt y no existe ningún método alternativo. Borg en el modo repokey almacena la clave cifrada dentro del repositorio, por lo que basta la frase de contraseña para restaurarlo; 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é en el servidor del que realiza la copia 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 únicamente como versión de prueba. La serie estable es la 1.4, actualmente la 1.4.5. Empiece ahora con la 1.4. Borg 2 cambia el formato del repositorio y ofrece una ruta de actualización documentada, por lo que empezar hoy no le impedirá migrar más adelante.