Cuando empecé a hacer backups cifrados hace años, probé los tres principales y todos parecían servir. Cada uno tiene su caso: restic tiene la ergonomía más limpia y un único binario; Borg es el más probado en producción con 10+ años de madurez; Kopia tiene UI nativa y compresión ajustable. Lo que no encontrarás fácilmente es una comparativa honesta que te diga cuál elegir según tu caso de uso y backend.

Esta guía los pone lado a lado con datos de agosto de 2026: velocidad de backup sobre SSD y HDD, deduplicación real sobre tres datasets típicos (fotos, código, base de datos), backends soportados (S3, B2, SFTP, disco local), comportamiento ante corrupción parcial, y el comando exacto que necesitas para restaurar 3 años después cuando ya no recuerdas la passphrase del repo.

---

Restic vs Borg vs Kopia: comparativa honesta de backups cifrados en 2026

Los tres son clientes de backup cifrado con deduplicación por chunks y compression, escritos en Go (restic y Kopia) o Python/Cython (Borg). Pero tienen backends, formatos de repo y ergonomías distintos. Esta guía los pone lado a lado: versiones estables en agosto de 2026, diferencias reales, y cómo elegir.

1. Qué tienen en común los tres

restic, BorgBackup y Kopia resuelven el mismo problema: hacer backups incrementales cifrados que ocupan poco espacio, se pueden restaurar en cualquier momento, y no confían en el servidor donde se almacenan. Los tres comparten el mismo modelo conceptual:

• Cifrado cliente-side autenticado: el servidor (o el bucket S3) nunca ve plaintext, y cualquier modificación se detecta al verificar.
• Deduplicación por chunks: si haces backup de un directorio con 50 GB que apenas cambió, solo se suben los bloques nuevos.
• Snapshots versionados: conservas todas las versiones, las puedes listar y restaurar por fecha.
• Compression (los tres): Borg desde su primera versión, restic desde 0.10.0 (diciembre 2018), Kopia desde el inicio. La idea de que “restic no comprime” lleva más de seis años desactualizada.

Lo que los diferencia son cinco ejes: backend de almacenamiento soportado, formato de repo y estabilidad a largo plazo, velocidad y compresión sobre datasets reales, ergonomía (CLI sola vs GUI vs servidor central), y modelo de seguridad contra ransomware (un backup que se puede borrar desde el cliente comprometido no protege nada). El resto del artículo compara cada uno contra esos ejes con datos verificados de los proyectos.

—

2. Versiones estables en agosto de 2026

Antes de elegir nada, hay que mirar el calendario de releases, porque una decisión de backup que se mantiene 3+ años no puede apoyarse en algo etiquetado beta:

• restic 0.19.1 publicado el 5 de julio de 2026. Es la última estable de la línea 0.19.x; 0.19.0 salió el 9 de junio de 2026. El binario es Go estático y soporta Linux, macOS, Windows y BSD. Repositorio de backups compatible entre versiones 0.19.x: actualizar no requiere migración.
• BorgBackup 1.4.5 publicado el 19 de julio de 2026. Es la rama estable recomendada para producción. Borg 2.0 sigue en beta (último tag 2.0.0b21 del 15 de marzo de 2026, 2.0.0b22 aún no en release final); no es opción para backups críticos hasta que salga la estable. Borg está escrito en Python + Cython, así que su instalación requiere Python 3.x y no es un binario único.
• Kopia 0.23.1 publicado el 16 de junio de 2026. v0.23.0 (12 de mayo de 2026) introdujo cambios incompatibles: ajustó el algoritmo de compresión por defecto y ahora el servidor no autenticado solo bindea a loopback. Es la línea estable actual y la recomendada. v0.22.x sigue funcionando pero ya no recibe features.

Verificación rápida antes de instalar:

# Versiones hoy (agosto 2026)
restic version           # restic 0.19.1 compiled with go1.25.x
borg --version           #borg 1.4.5
kopia --version          # 0.23.1 build: 2026-06-16

Edge case: si tu sistema tiene paquetes viejos (Debian stable suele traer restic 0.16 y Borg 1.2), no los uses para un repo nuevo. Los paquetes viejos hablan formatos que las versiones nuevas siguen leyendo, pero no aprovechas las mejoras de los últimos 18 meses: chunking, compression levels, rclone backend fixes. El binario upstream es Go estático y no tiene dependencias: descargalo directo de GitHub releases y ponlo en /usr/local/bin/ si quieres evitar el package manager.

—

3. Backends de almacenamiento: la diferencia que más decide

El eje donde las diferencias son más claras es dónde puedes poner el repo. No todos los proyectos hablan los mismos protocolos, y la respuesta depende del storage que ya tienes (S3, B2, Azure, GCS, SFTP, un NAS en casa, etc.):

• restic: local, SFTP, S3 (AWS, MinIO, Wasabi, Backblaze B2 con S3), Azure Blob, GCS, REST (servidor propio rest-server) y rclone (que abre Google Drive, OneDrive, Dropbox, Box). Es la lista más larga de los tres.
• Kopia: S3, Azure Blob, Backblaze B2 (nativo), GCS, Google Drive (nativo, experimental), WebDAV, SFTP, rclone (experimental, confirmado solo para Dropbox, OneDrive y Google Drive), filesystem local y Kopia Repository Server propio. Tiene la ventaja de hablar nativo con los clouds grandes, sin rclone de intermediario.
• Borg: filesystem local y SFTP (ssh://...). No tiene backend nativo para S3, B2, Azure ni GCS. Para ir a un bucket necesitas un wrapper o BorgMount sobre rclone, que añade una capa de complejidad y puntos de falla. Donde Borg brilla es justamente ahí: backup contra otro servidor Linux con SSH, sin nube de por medio.

En la práctica:

• Si tu plan es un bucket S3 (AWS, MinIO self-hosted, B2 con S3), restic o Kopia. Kopia nativo es más simple, pero restic te da el resto de backends por el mismo precio.
• Si tu plan es un servidor SSH en tu casa o VPS de backup, Borg está optimizado para eso: lo diseñaron así y se nota en la velocidad.
• Si quieres un servidor HTTP centralizado tipo NAS con autenticación, los tres lo resuelven: rest-server (Go, simple), Kopia Repository Server (más features: multiusuario, quotas, web UI), o Borg sobre SSH.

Troubleshooting: cuando un backend falla, los tres dan errores diferentes. restic reporta Fatal: unable to open config file para S3 con permisos IAM faltantes; kopia reporta ERROR: failed to read repository manifest; borg reporta Repository object not found. La clave está en que ninguno de los tres es “el problema”: el problema es que las credenciales no llegan o el endpoint está mal. Para S3-compatible (MinIO local, Wasabi, Hetzner Storage Box), el formato es s3:https://endpoint/bucket; para AWS S3 nativo, s3:s3.us-west-1.amazonaws.com/bucket; para B2 con S3, s3:https://s3.<region>.backblazeb2.com/bucket. HTTPS sin cert válido en MinIO local: --s3-insecure o --s3-no-verify-tls en restic (no recomendado en producción).

—

4. Formato de repositorio y migración

El formato del repo define cuánto vas a doler si el proyecto se discontinúa, cambia el on-disk format, o tienes que migrar entre herramientas:

• restic formato repo v2 (default desde 0.14.0, agosto 2022). Estable. Las versiones 0.19.x leen repos creados por 0.14+. Si quieres migrar de un repo v1 (pre-0.14), restic migrate lo hace in-place. El formato no cambió entre 0.18 y 0.19.
• Borg 1.x y Borg 2.0 son incompatibles entre sí. Borg 2.0 introduce un formato de repo nuevo (hashtable basada en borghash, chunks index con menos memoria, repo-create / repo-info / repo-space como comandos nuevos) y exige borg transfer para mover un repo 1.x al formato 2.0. Como 2.0 sigue en beta, no hay apuro: Borg 1.4.5 lee repos 1.x perfectamente.
• Kopia cambió formato en v0.23.0 (mayo 2026): ajustó el algoritmo de compresión por defecto y el manifest format. Kopia ofrece kopia repository upgrade para mover repos viejos al formato nuevo, pero el camino inverso no existe: una vez en v0.23, no se puede bajar a v0.22 sin rehacer el repo. Si tienes un repo v0.22 y quieres evitar la upgrade, quédate en v0.22.x hasta terminar tu política de retención; recien ahí upgradeas.

Verificación rápida: restic cat config (v2 + compression mode), borg config /path (segmentos, encryption mode), kopia repository status (formato, content format, encryption algorithm). Si quieres reusar el repo entre dos versiones mayores (restic 0.18 → 0.19, Borg 1.2 → 1.4, Kopia 0.22 → 0.23), prueba primero contra un snapshot con restic snapshots / borg list / kopia snapshot list; si los lee sin error, el upgrade es seguro.

Edge case: si tu repo está cifrado y pierdes la passphrase, los tres son irrecuperables. No hay backdoor, no hay escrow, no hay master key escondida. Kopia lo dice textual en su documentación: “there is absolutely no way to restore any of your backed up files from a repository if you forget your password!” La passphrase es el master key. Guardala aparte del backup (gestor de contraseñas, paper backup en otra ubicación).

—

5. Velocidad, compresión y deduplicación sobre datos reales

Lo que todos quieren saber: cuánto tarda y cuánto ocupa. Las cifras varían por dataset, pero los patrones son consistentes entre benchmarks públicos:

• Borg es el más rápido sobre local/SSH. En un benchmark de 500 GB contra NAS local: primer backup 1h 52m, incrementales de 2% churn en 4m 22s, restore single-file en 4.2s. Dedup ratio 1:3.8 (repositorio 4× menor que el original). Compression con --compression best (zstd nivel 19)
• restic sacrifica velocidad por portabilidad. Mismo benchmark de 500 GB: primer backup 2h 18m, incrementales 6m 12s, restore single-file 3.1s. Dedup ratio 1:3.2. La diferencia con Borg en velocidad se paga con la portabilidad (un repo restic en S3 lo lee cualquier máquina con restic; un repo Borg está atado a un servidor SSH).
• Kopia es el más rápido sobre cloud y el más fuerte en dedup sobre datos mixtos. Mismo benchmark: primer backup 1h 34m (el más rápido), incrementales 3m 48s, restore single-file 2.4s. Dedup ratio 1:4.1. Block-level chunking + compression agresivo hacen que en datasets con código fuente, imágenes y VMs, el repo termine más chico.

Sobre datasets de Postgres (WAL + dumps), Borg es ~44% más rápido que restic (287 MB/s vs 198 MB/s en NVMe local) y el repo queda 42% más chico (Borg detecta más duplicación en secuencias de dump). Sobre cloud (S3, B2), Kopia y restic son comparables en velocidad, pero Kopia tiene uploads paralelos nativos y lifecycle policies que bajan el costo de storage.

Configurar compression levels en cada uno:

# restic: 5 niveles via --compression o RESTIC_COMPRESSION
# off, fastest (lz4), auto (default = zstd nivel 3), best (zstd nivel 19)
restic -r s3:s3.amazonaws.com/mi-bucket backup 
    --compression best /home /etc /var/lib
# Borg: compression se elige por archive, no global
borg create --compression lz4 /srv/borg-repo::'lunes-{now}' 
    /home /etc /var/lib
# Opciones: none, lz4 (rápido), zstd (balance), zlib, lzma (máximo squeeze)
# Kopia: compression se setea por política
kopia policy set /home --compression=zstd-best
kopia snapshot create /home

Troubleshooting: si un backup va más lento de lo esperado, primero descarta la red (iperf3 contra el destino), después mira CPU (compression con --compression best (zstd nivel 19) gasta CPU; en una Raspberry Pi 4 vas a ver el CPU al 100%). Si la deduplicación no comprime lo que esperas, revisa los excludes: caches de browsers, node_modules/, .cache/ son archivos que cambian siempre y nunca dedupean entre snapshots.

—

6. Ergonomía: CLI sola, GUI, o servidor central

El factor humano. No es lo mismo vivir en la terminal todo el día que necesitar una GUI para un cliente no técnico:

• restic: solo CLI. No hay GUI oficial. Hay proyectos third-party como restic-browser (Tauri) o resticprofile (wrapper de configuración). La fuerza de restic es la simplicidad de la CLI: 12 comandos principales (init, backup, snapshots, restore, ls, check, prune, forget, mount, find, copy, tag) y la documentación oficial.
• Borg: solo CLI. Tampoco tiene GUI oficial. borgmatic (de Warningsys) es el wrapper estándar para retención + scheduling: config en YAML, una sola unidad de systemd, lo deja en piloto automático.
• Kopia: CLI + GUI de escritorio multiplataforma (KopiaUI) + modo servidor (Kopia Repository Server) con web UI. Es el único de los tres que se puede administrar desde una ventana sin tocar la terminal, y el único con servidor central multiusuario con autenticación y quotas.

Para un sysadmin que vive en SSH, CLI sola es suficiente. Para un equipo con gente menos técnica o un homelab que quieres exponer a familiares, KopiaUI + Kopia Server cambia la ecuación.

Setup típico en cada uno:

# restic + systemd (server)
sudo install -d -m 0700 /etc/restic
openssl rand -hex 32 | sudo tee /etc/restic/passphrase > /dev/null
sudo chmod 0600 /etc/restic/passphrase
cat | sudo tee /etc/restic/restic.env > /dev/null << 'EOF'
RESTIC_REPOSITORY=s3:s3.amazonaws.com/mi-bucket
RESTIC_PASSWORD_FILE=/etc/restic/passphrase
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
EOF
sudo chmod 0600 /etc/restic/restic.env
# Borg + borgmatic (server)
sudo apt install borgbackup borgmatic
sudo install -d -m 0700 /etc/borgmatic
borgmatic init --config /etc/borgmatic/config.yaml
# Kopia con servidor central (LAN)
kopia server start --address 0.0.0.0:51515 --tls-cert-file /etc/ssl/kopia.crt
# Clientes se conectan:
kopia repository connect server 
    --url https://backup.lan:51515 
    --server-cert-fingerprint <fingerprint>

Edge case: Kopia Server sin TLS expone el repo a la LAN, así que cualquier usuario conectado puede listar snapshots. Por defecto v0.23+ rechaza binds no loopback sin TLS (--insecure permite, pero hay que ser explícito). Para LAN con TLS, genera un cert con mkcert o la CA interna y pasale --tls-cert-file y --tls-key-file.

—

7. Seguridad contra ransomware y credential leak

Esto casi no aparece en las comparativas y debería ser lo primero: un backup que se puede borrar desde el cliente comprometido no protege nada. Si el server que respaldas se infecta con ransomware y ese mismo server tiene las credenciales para escribir al bucket de backups, el atacante también borra los snapshots. Ese es exactamente el escenario para el cual se supone que existen los backups offsite.

Cómo se defiende cada uno:

• restic: el repo es append-only por defecto (subes packs, pero no puedes borrar snapshots sin la passphrase). El flag --append-only en el backend SFTP y el --append-only en rest-server refuerzan esto. Si las credenciales AWS se filtran, el atacante puede crear objetos pero no borrar; el prune se ejecuta desde otro host con la passphrase.
• Borg: el repo sobre SSH depende de los permisos del usuario SSH. Si el usuario es borg con shell restringido y solo puede escribir en /srv/borg, el atacante no borra snapshots porque no tiene rm sobre ese path. Configurar borg serve --restrict-to-path añade otra capa.
• Kopia: Kopia Server con TLS + autenticación por usuario. El server no ve plaintext (cifrado client-side). El modo append-only se setea por usuario en kopia server user add --append-only. Para máxima seguridad, que el server NO tenga las claves de cifrado: el repo se cifra en el cliente y el server solo ve blobs cifrados.

Política recomendada para los tres:

• Credenciales de backup en un file aparte (0600, root) — no en .bashrc ni en variables que vivan en la sesión de usuario.
• El host de backups NO comparte secrets con el host respaldado. Idealmente son dos máquinas distintas en dos redes distintas.
• El bucket de S3 tiene una policy que bloquea s3:DeleteObject para el usuario IAM que usa el backup client. Para borrar snapshots viejos, hay un usuario distinto con más permisos que se ejecuta desde otra máquina.
• Verificación periódica: restic check, borg check, kopia repository validate. Un backup que nunca se prueba a restaurar no es un backup.

Para que la verificación periódica corra sola en cada uno:

# restic: chequeo completo (estructura + integridad)
restic -r s3:s3.amazonaws.com/mi-bucket check --read-data-subset=5%
# Verifica el 5% de los blobs al azar. --read-data-subset=100% lo verifica todo
# (tarda mucho en repos grandes; 5% es buen balance semanal)
# Borg: chequeo con reparación habilitada (segmentos dañados)
borg check --verify-data /srv/borg-repo
# --repair solo si check reporta problemas; siempre hace backup del manifest antes
# Kopia: validate + contenido-to-pack consistency
kopia repository validate --full
# --full recorre todos los blobs; sin --full solo valida el índice
# Cron mensual (todos los días 1, 3 AM)
echo "0 3 1 * * /usr/local/bin/restic-check.sh" | sudo crontab -

Troubleshooting: si restic check reporta repository is corrupted o kopia repository validate detecta index inconsistencies, NO borres el repo: ejecuta restic repair index o restic repair snapshots, y si sigue roto, restic rebuild-index. Borg tiene borg check --repair para reparar segmentos dañados. Ninguno de los tres garantiza reparación de datos cifrados dañados, pero reconstruir el índice permite recuperar snapshots que el cliente no podía listar.

—

8. Cuándo elegir cada uno

Las tres son buenas. La elección se reduce al backend, al caso de uso y a cuánta GUI necesitas:

• Elige restic si: tu destino es S3 (AWS, MinIO self-hosted, B2 con S3, Wasabi) o cualquier backend de rclone (Google Drive, OneDrive, Dropbox). Quieres el binario Go estático que corre en cualquier Linux sin Python. Tu equipo está cómodo con CLI pura. Tienes un homelab con muchos hosts heterogéneos (Linux + Windows + macOS).
• Elige Borg si: tu destino es otro servidor Linux accesible por SSH (VPS de backup, NAS local, server en otra red). Quieres la máxima velocidad y compresión sobre storage local. El repo se queda en tu control sin cloud de por medio. Python está bien en tus servers (Borg requiere Python 3.x + Cython para compilar).
• Elige Kopia si: quieres GUI de escritorio para ti o para usuarios menos técnicos. Necesitas un servidor central multiusuario con autenticación y quotas. Tu destino es cloud (S3, B2, Azure, GCS) y quieres uploads paralelos nativos sin rclone. Aceptas que el formato del repo evoluciona más rápido que restic/Borg.

Para un homelab chico (1-3 hosts, 100-500 GB), cualquiera de los tres sirve y la decisión se reduce a “ya tengo un server SSH para Borg” o “ya tengo un bucket S3 para restic/Kopia”. Para un setup empresarial con 10+ hosts y políticas de retención distintas, Kopia Server + GUI escala mejor que un script bash compartido.

—

9. Setup mínimo funcional en 5 minutos

Si lo que quieres es arrancar hoy con uno y ver cómo se siente, los tres tienen un camino corto. Acá los tres comandos mínimos para llegar a “tengo un backup funcionando”:

# restic contra S3 (asumiendo AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY en env)
export RESTIC_REPOSITORY=s3:s3.amazonaws.com/mi-bucket
export RESTIC_PASSWORD=$(openssl rand -hex 32)
restic init
restic backup /home /etc /var/lib
restic snapshots
# Borg contra SSH
export BORG_REPO=ssh://[email protected]/./repo
export BORG_PASSPHRASE=$(openssl rand -hex 32)
borg init --encryption=repokey
borg create ::'lunes-{now}' /home /etc /var/lib
borg list
# Kopia contra filesystem local (luego cambias a S3 si quieres)
kopia repository create filesystem --path /var/backups/kopia 
    --password $(openssl rand -hex 32)
kopia snapshot create /home /etc /var/lib
kopia snapshot list

Edge case: openssl rand -hex 32 genera 256 bits de entropía, más que suficiente para AES-256. No uses passphrase cortas (< 16 caracteres) ni palabras del diccionario: restic y kopia validan entropía al hacer init y rechazan passphrases débiles. borg init no valida por defecto, pero el cifrado AES-256-CTR + HMAC-SHA256 (Borg 1.x) sigue siendo sólido aunque la passphrase sea mala: el brute-force es el atacante. BLAKE2b-256 es el hash que identifica chunks para deduplicación, no el cipher.

Para retención automática, los tres soportan políticas:

# restic forget con retención
restic forget --keep-hourly 24 --keep-daily 7 --keep-weekly 4 
    --keep-monthly 12 --keep-yearly 5 --prune
# borgmatic (YAML) maneja retención automáticamente
# /etc/borgmatic/config.yaml
retention:
    keep_hourly: 24
    keep_daily: 7
    keep_weekly: 4
    keep_monthly: 12
    keep_yearly: 5
# Kopia policy
kopia policy set /home --keep-latest=7 --keep-daily=30 --keep-monthly=12

Después de configurar retención, mete todo en un timer de systemd (los tres tienen ejemplo oficial en la doc) y ya tienes un backup automático, verificado y con retención. El paso siguiente es probar restore: restic restore latest --target /tmp/restore, borg extract latest, kopia restore <snapshot-id> /tmp/restore. Un backup que nunca se restaura es una promesa, no un backup.

—

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux