restic: backups cifrados en Linux (local, S3 y automatización) — guía 2026

restic es un cliente de copias de seguridad cifrado, deduplicado y verificado, escrito en Go. En su versión 0.19.1 (julio de 2026) ofrece soporte para backends locales, SFTP, S3, Azure, GCS, REST y rclone, repositorios comprimidos con zstd y mount estilo FUSE. Esta guía te lleva desde el primer repo hasta una tarea programada con systemd.

—

1. Por qué restic y no tar + cron

Lo que da restic que no da un tarball:

• Cifrado AES-256 con ChaCha20-Poly1305 desde el origen. No se guarda plaintext en el destino.
• Deduplicación por chunks: si haces backup de un directorio con 50 GB de logs que apenas cambian, solo pagas por los chunks nuevos.
• Versionado: conservas snapshots, los etiquetas son consultables. Puedes recuperar el de hace tres jueves.
• Verificación: restic check valida la integridad del repo y la reconstruibilidad de los datos.
• Múltiples backends con la misma sintaxis: local, S3, SFTP, REST, rclone (que abre la puerta a Google Drive, Backblaze B2, etc.).
• FUSE mount: montar un snapshot como directorio y cp lo que necesites.

restic no es una herramienta de archivado “para siempre”: ni quita duplicados inter-snapshot (sí dentro de un snapshot), ni escala bien con cientos de terabytes. Para esos casos BorgBackup, ZBackup o soluciones empresariales pueden ser más adecuadas. Para el 90% de servidores VPS y NAS caseros, restic es la elección correcta.

—

2. Instalación

El binario de restic es un solo ejecutable estático escrito en Go, así que las tres plataformas lo instalan desde el mismo upstream. En Debian/Ubuntu viene empaquetado en los repos oficiales, pero suele estar una o dos versiones atrás del último release; si necesitas una versión más nueva, el script oficial está en https://restic.netlify.app/download.html.

# Debian / Ubuntu
sudo apt install restic
# Fedora / RHEL
sudo dnf install restic
# macOS
brew install restic
# Verificar versión
restic version
# restic 0.19.1 compiled with go1.25.x on linux/amd64

Confirmado con la rama estable: 0.19.1 (5 de julio de 2026). 0.19.0 se publicó el 9 de junio de 2026. Ambas son compatibles en formato de repo, así que actualizar no requiere migración.

Si restic version no devuelve el binario después de instalar, revisa que /usr/bin/restic esté en el PATH (echo $PATH) y que la instalación no haya fallado por dependencias rotas (sudo apt --fix-broken install). En contenedores Docker minimalistas puede faltar xz-utils o libc6; restic los linkea estáticamente, así que si reporta “No such file” suele ser problema de glibc demasiado viejo.

—

3. Inicializar un repositorio

3.1 Repositorio local

restic init crea el directorio del repo y lo inicializa con la estructura interna: un archivo config con la versión, packs de chunks cifrados y un llavero (keys/) con la clave maestra derivada de tu passphrase. Sin passphrase válida, los packs son ruido criptográfico inútil: AES-256 + ChaCha20-Poly1305 no tienen backdoor.

export RESTIC_REPOSITORY=/var/backups/restic
export RESTIC_PASSWORD='una-contraseña-muy-larga-y-aleatoria'
restic init

RESTIC_PASSWORD es la contraseña maestra del repositorio. Si la pierdes, no hay forma de recuperar los datos. Más adelante se explica cómo guardarla mejor.

Edge case: las variables de entorno solo viven en la sesión actual del shell. Para que persistan, definilas en ~/.bashrc, ~/.profile o (mejor) usa un EnvironmentFile de systemd como se muestra en el paso 9. Si restic init te tira Fatal: unable to create config file: directory does not exist, el directorio padre de RESTIC_REPOSITORY no existe; crealo primero con sudo mkdir -p. Y si dice Fatal: wrong password or no key found, ya existía un repo allí: usa restic snapshots para verificar o restic cat config para confirmar antes de pisarlo.

3.2 Repositorio S3

restic usa el SDK de AWS por debajo, así que las credenciales se leen de las mismas variables que la CLI de AWS (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y opcionalmente AWS_DEFAULT_REGION). Para repos nuevos en producción, generá un usuario IAM dedicado con policy de mínimo privilegio (solo s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject sobre el prefijo del bucket) — esto limita el daño si la clave se filtra.

S3 nativo (AWS S3, MinIO, Hetzner Storage Box con S3, Backblaze B2 con S3, etc.):

export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:s3.amazonaws.com/mi-bucket
restic init

Para S3-compatible (MinIO local, Wasabi, etc.):

export RESTIC_REPOSITORY=s3:http://192.168.1.10:9000/mi-bucket
export AWS_ACCESS_KEY_ID=minio
export AWS_SECRET_ACCESS_KEY=minio123
restic init

Troubleshooting: si te tira Fatal: unable to open config file: ..., permission denied, la policy IAM no concede s3:GetObject sobre la clave config. Si el error es The specified bucket does not exist, revisa la región: s3.amazonaws.com/mi-bucket apunta a us-east-1; para otra región usa s3.us-west-1.amazonaws.com/mi-bucket. En Wasabi, el endpoint es s3.wasabisys.com. En Backblaze B2 con S3, usa el endpoint https://s3..backblazeb2.com que te da la consola. HTTPS sin certificado válido en MinIO local exige agregar --s3-insecure o --s3-no-verify-tls (no recomendado en producción).

3.3 SFTP

Este backend abre una conexión SSH al servidor remoto y opera sobre archivos planos usando el protocolo SFTP. Es útil cuando tienes un servidor con SSH abierto y quieres backups sin montar nada extra, pero es el backend más lento de los nativos: cada operación es un round-trip SSH. Si vas a subir muchos GB, S3 o rclone te va mejor.

export RESTIC_REPOSITORY=sftp:usuario@servidor:/var/backups/restic
restic init

Troubleshooting: el primer intento suele caer con Fatal: unable to open config file: ..., permission denied o connection refused. Causa típica: el usuario SSH no tiene permiso de escritura sobre el directorio remoto. Asegurate de que /var/backups/restic exista en el servidor destino (ssh usuario@servidor mkdir -p /var/backups/restic) y que los permisos permitan escritura. Si usas clave privada con passphrase, exportá RESTIC_SSH_KEY_FILE o SSH_AUTH_SOCK con un ssh-agent cargado. Para SFTP en un puerto no estándar: sftp:user@host:2222:/path.

3.4 rclone (Google Drive, B2, Dropbox, etc.)

rclone config lanza un asistente interactivo que te deja crear un “remote” con nombre (en el ejemplo, drive) y guardar sus credenciales OAuth localmente. A partir de ahí, cualquier backend que rclone soporte queda disponible para restic sin código extra: Google Drive, OneDrive, Dropbox, Backblaze B2, Box, S3 de cualquier proveedor, etc.

restic 0.16+ incluye soporte nativo:

rclone config   # crea un remote llamado "drive"
export RESTIC_REPOSITORY=rclone:drive:restic-backups
restic init

rclone añade una capa de compatibilidad: cualquier backend de rclone funciona con restic. Restic lee en streaming, evita tocar el disco si es posible.

Troubleshooting: si rclone config no muestra el backend que quieres en el menú, actualizá rclone (sudo rclone selfupdate o reinstalá desde https://rclone.org/install/); los backends nuevos se agregan con cada release. Después de configurar, validá la conexión con rclone lsd drive: (debería listar las carpetas raíz de Google Drive) ANTES de pasarle esa URL a restic; si rclone no puede listar, restic tampoco. Ojo con los tokens OAuth de Google Drive: vencen cada ~12 meses; cuando vencen, los backups fallan silenciosamente con 401 Unauthorized. Automatizá la renovación con rclone config reconnect drive: o un cron anual.

—

4. El archivo de configuración de restic

En lugar de exportar variables en cada shell o en cada unit de systemd, lo más limpio es centralizar la configuración en un archivo al que apunta RESTIC_REPOSITORY y RESTIC_PASSWORD_FILE. Como va a contener credenciales, este archivo debe ser legible solo por root (o por el usuario que corre el servicio).

Para evitar variables de entorno en cada comando, crea /etc/restic/restic.env:

# /etc/restic/restic.env
RESTIC_REPOSITORY=s3:s3.amazonaws.com/mi-bucket
RESTIC_PASSWORD_FILE=/etc/restic/passphrase
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...

RESTIC_PASSWORD_FILE apunta a un archivo con la contraseña. La contraseña debe ser única por repo y no reutilizarse.

El segundo bloque crea el directorio con permisos 0700 (solo root entra), genera 32 bytes hex aleatorios con openssl rand -hex 32 (256 bits de entropía, más que suficiente para AES-256) y deja el archivo en 0600 (solo root puede leer). Sin estos permisos, restic puede negarse a usarlo por seguridad.

sudo install -d -m 0700 /etc/restic
sudo openssl rand -hex 32 | sudo tee /etc/restic/passphrase > /dev/null
sudo chmod 0600 /etc/restic/passphrase

Una buena práctica muy práctica: subir la contraseña a un gestor de secretos (pass, Bitwarden, Vault) y dejar el archivo solo en el servidor. La contraseña es lo único que evita ataques offline contra el bucket.

Verificación rápida: sudo cat /etc/restic/passphrase | head -c 8 te muestra los primeros 8 caracteres — confirmas que el archivo tiene contenido y que sudo puede leerlo. Si restic se queja de password file is world-readable, los permisos no se aplicaron bien; revisa que chmod 0600 haya corrido como root y que no haya ACLs extendidas (getfacl /etc/restic/passphrase).

—

5. Tu primer backup

Por defecto, restic hace snapshots incrementales: lee cada archivo, lo corta en chunks de tamaño variable (4 MiB promedio, usando Buzhash como rolling hash para detectar bloques movidos), cifra cada chunk, deduplica contra el repo existente y sube solo lo nuevo. El primer backup es el más lento porque sube todo; los siguientes son sub-segundos si nada cambió.

restic backup /home /etc /var/www

Por defecto, restic hace snapshots incrementales. Solo copia los chunks nuevos. Para excluir patrones:

--exclude-file lee patrones línea por línea (estilo .gitignore), --exclude-caches salta directorios marcados con CACHEDIR.TAG (los que respetan el estándar XDG, como ~/.cache y target/ de Cargo), --tag te permite filtrar después con restic snapshots --tag nocturno.

restic backup 
  --exclude-file=/etc/restic/excludes 
  --exclude-caches 
  --tag auto,nocturno 
  /home /etc

/etc/restic/excludes:

*.tmp
*.swp
**/.cache
**/node_modules
**/__pycache__

Listar snapshots:

restic snapshots lee el índice del repo y muestra todos los snapshots con su ID corto (8 caracteres hex), host, tags y paths incluidos. El ID corto sirve para restic restore o restic forget. Filtrá por tag con --tag nocturno o por host con --host srv01.

restic snapshots
|ID        Time                 Host    Tags          Paths
|a1b2c3d4  2026-08-01 03:30:00  srv01   auto,nocturno  /home /etc
|e5f6g7h8  2026-08-02 03:30:00  srv01   auto,nocturno  /home /etc

Troubleshooting: si el primer backup se queda en 0% y tarda mucho, es normal en el primer snapshot (toda la data se cifra y sube). Si está corriendo pero lento, revisa la red con iftop o nethogs. Si ves Error: ... no such file or directory, alguno de los paths no existe — restic backup no falla si un path está vacío, pero sí falla si no existe. Si dice Fatal: index is not locked, hay otro proceso restic corriendo contra el mismo repo; espera a que termine o ps aux | grep restic para identificarlo. Para bases de datos o archivos vivos (VMDK, KVM disk images), sacá un snapshot del FS con lvcreate --snapshot o usa --exclude y respaldá por separado con pg_dump.

—

6. Restaurar: lo que de verdad importa

Lo que distingue a una herramienta de backup son sus opciones de restore. Conviene probar estas antes de necesitarlas en serio.

6.1 Restaurar todo un snapshot

latest es un alias que resuelve al snapshot más reciente del repo (ordenado por timestamp, no por ID). El --target es el directorio donde se materializan los archivos: si ya tiene contenido, restic sobrescribe los archivos modificados pero no borra los que sobran. Para un restore limpio a un directorio vacío, pasá un path nuevo.

restic restore latest --target /tmp/restore

6.2 Restaurar un solo archivo

--include con un path absoluto dentro del snapshot restaura solo los archivos que coinciden. Útil cuando sabes exactamente qué archivo se rompió y no quieres tocar el resto. Si el patrón no matchea nada, restic termina con código 1 y un warning — siempre chequea el exit code en scripts de recuperación.

restic restore latest --target /tmp/restore --include /etc/nginx/nginx.conf

6.3 Restaurar a partir de un snapshot concreto

Cuando latest no es el snapshot que quieres (por ejemplo, el último está corrupto o tiene un cambio que quieres revertir), pasá el ID corto (a1b2c3d4) o el largo (a1b2c3d4e5f6...). El ID se obtiene con restic snapshots.

restic restore a1b2c3d4 --target /var/restore

6.4 Montar un snapshot como carpeta (FUSE)

restic mount usa FUSE para exponer la estructura snapshots// como un árbol de directorios navegable. Cada timestamp es una carpeta de solo lectura, así que puedes navegar con ls, find, cp o cualquier herramienta estándar. No es un mount persistente: cuando hacés fusermount -u, todo desaparece.

mkdir -p /mnt/restore
restic mount /mnt/restore
# En otra terminal
ls /mnt/restore/snapshots/2026-08-01-03-30-00/etc/nginx/
cp /mnt/restore/snapshots/2026-08-01-03-30-00/etc/nginx/nginx.conf /etc/nginx/
fusermount -u /mnt/restore

Troubleshooting: si fusermount -u dice entry not found in /etc/mtab, el kernel no está trackeando el mount (común en contenedores o sistemas sin /etc/mtab); usa fusermount3 -u o umount /mnt/restore. Si restic mount falla con fusermount: failed to open /dev/fuse, cargá el módulo kernel: sudo modprobe fuse y agregalo a /etc/modules. Para que un usuario no-root pueda montar, asegurate de estar en el grupo fuse (usermod -aG fuse $USER).

—

7. Política de retención y olvido

Por defecto, restic conserva todos los snapshots indefinidamente y nunca libera espacio en el repo aunque los snapshots se borren — los chunks siguen ahí hasta que un --prune los reescribe. Para que los backups no crezcan sin tope, hay que separar dos operaciones: forget (marca qué snapshots borrar) y prune (compacta el repo en disco).

restic forget 
  --keep-hourly 24 
  --keep-daily 7 
  --keep-weekly 4 
  --keep-monthly 6 
  --keep-yearly 2 
  --prune

--prune reescribe el repo para liberar espacio en disco. Hazlo solo cuando estés seguro: hasta que termina, restauraciones fallarán si el repo se interrumpe a la mitad.

Para automatizar el forget con la copia de seguridad, el patrón recomendado es correr restic backup sin --prune y luego restic forget con --prune. Si la conexión con S3 se cae durante --prune, una próxima ejecución con --prune lo retoma.

Troubleshooting: --prune es la operación más pesada (lee y reescribe packs enteros); en repos de cientos de GB puede tardar horas. Si necesitas liberar espacio YA sin esperar al --prune, puedes usar --max-unused 5% para mantener un colchón de chunks sin snapshot asociado. La política de retención no es aditiva entre reglas: restic toma la regla más generosa que aplique a cada snapshot según su antigüedad, así que “horario 24, diario 7” significa “los últimos 24 snapshots se conservan por hora, los siguientes 7 por día, etc.”. Si ves Fatal: unable to find a suitable policy, ningún snapshot matchea la política y --prune borraría todo; revisa las fechas con restic snapshots --json | jq '.[].time'.

—

8. Verificación periódica

restic check hace dos cosas distintas: validar la integridad estructural del repo (lee el index, recorre los packs, verifica que cada blob listado exista) y opcionalmente descargar y verificar el contenido de los datos. La verificación estructural es rápida (segundos), la verificación de datos es cara (lee del bucket).

Añade una verificación semanal al cron de systemd:

restic check                # verifica integridad del repo
restic check --read-data-subset=5%  # verifica el 5% de los datos
restic check --with-cache    # usa el cache local para acelerar

check --read-data-subset es caro: lee datos reales del bucket. Para repos de varios terabytes, ejecútalo semanalmente con un 1-5%.

Troubleshooting: si restic check reporta error in repository: pack XXX not present in repository, hay un pack perdido o corrupto. La causa típica es una interrupción durante un --prune o un bucket con versionado inconsistente. Para recuperarte, primero prueba restic repair index (regenera el índice desde los packs); si no alcanza, restic repair packs (relinkea packs sueltos) — pero esto último puede perder blobs huérfanos. --read-data-subset=N% lee N% de los blobs cada vez; con --read-data-subset=100% verificas todo el repo, pero tardás más que un backup completo en repos grandes. Si tienes dudas sobre la integridad, haz un restore de prueba a /tmp/restore-test y compara tamaños con du -sh.

—

9. Automatización con systemd

9.1 El unit de backup

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Backup con restic
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
EnvironmentFile=/etc/restic/restic.env
ExecStart=/usr/bin/restic backup 
  --exclude-file=/etc/restic/excludes 
  --tag auto,nocturno 
  /home /etc /var/www
ExecStartPost=/usr/bin/restic forget 
  --keep-hourly 24 --keep-daily 7 --keep-weekly 4 --keep-monthly 6 
  --keep-yearly 2 --prune
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7

Nice=10 baja la prioridad para no molestar a la carga útil. IOSchedulingClass=best-effort indica al kernel que prefiera procesos interactivos.

9.2 El timer

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Backup diario con restic
[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
Unit=restic-backup.service
[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

daemon-reload es obligatorio después de tocar cualquier unit en /etc/systemd/system/ (sin esto, systemd ve el archivo viejo cacheado). enable --now hace dos cosas: crea el symlink para que el timer arranque en cada boot (enable) y lo arranca inmediatamente (now). list-timers restic-backup.timer te muestra la próxima ejecución y cuánto falta — si dice n/a, hay un error de sintaxis en el unit, mira systemctl status restic-backup.timer.

9.3 Unit de verificación

# /etc/systemd/system/restic-check.service
[Unit]
Description=Verificación semanal del repo restic
[Service]
Type=oneshot
EnvironmentFile=/etc/restic/restic.env
ExecStart=/usr/bin/restic check --read-data-subset=5%
CPUQuota=50%
MemoryMax=512M

# /etc/systemd/system/restic-check.timer
[Unit]
Description=Verificación semanal
[Timer]
OnCalendar=Sun 04:00:00
Persistent=true
Unit=restic-check.service
[Install]
WantedBy=timers.target

—

10. Configuración declarativa con resticprofile

resticprofile es un wrapper opcional que lee profiles en un archivo YAML y llama a restic con los parámetros correctos. Útil cuando tienes varios repos.

resticprofile se distribuye como binario único en GitHub releases; la alternativa oficial es instalarlo desde el PPA de restic (ppa:ricotz/resticprofile en Ubuntu) o desde el repo community de Arch. La ubicación /usr/local/bin/ está en el PATH antes que /usr/bin/, así que toma precedencia.

sudo install resticprofile /usr/local/bin/
# o: sudo apt install resticprofile

/etc/restic/profiles.toml:

default = "servidor"
[global]
restic-binary = "/usr/bin/restic"
[backup]
repository = "s3:s3.amazonaws.com/mi-bucket"
password-file = "/etc/restic/passphrase"
initialize = true
[backup.backup]
source = ["/home", "/etc", "/var/www"]
exclude-caches = true
exclude-file = "/etc/restic/excludes"
tag = ["auto", "nocturno"]
[backup.retention]
keep-hourly = 24
keep-daily = 7
keep-weekly = 4
keep-monthly = 6
keep-yearly = 2
prune = true
[backup.check]
read-data-subset = "5%"
[backup.snapshots]
group-by = "host,paths"

Ahora systemd invoca resticprofile directamente:

ExecStart=/usr/local/bin/resticprofile --config /etc/restic/profiles.toml --name backup backup
ExecStartPost=/usr/local/bin/resticprofile --config /etc/restic/profiles.toml --name backup retention

La ventaja es que la misma configuración sirve para ejecutarla a mano, programarla, y subir registros a un dashboard.

—

11. Buenas prácticas de seguridad

1. Cifra el repo, pero también la contraseña. No guardes la passphrase en el mismo sistema que respaldas. Usa un password manager fuera del servidor.

2. Aísla las credenciales S3. Crea un bucket dedicado, con una IAM policy que permita solo Put/Get sobre el prefijo del repo. Rota las claves cada 90 días.

3. Habilita versioning en S3. Un backup cifrado malo no se puede deshacer. Versioning te permite revertir el bucket entero si algo sale mal.

4. Prueba el restore. Un backup sin restore probado es una hipótesis. Programa restauraciones a un directorio temporal y revisa archivos críticos.

5. Monitoriza el último backup. restic check con --with-cache es rápido. Si una sola ejecución falla, Heartbeat / Healthchecks / Uptime Kuma debe avisarte.

6. No respaldes archivos vivos. Para bases de datos, haz un dump previo (pg_dump, mysqldump) y respalda ese dump, no el directorio de datos.

7. Reposa backups en frío. Tier Glacier o Standard-IA reduce costes a la mitad para backups semanales si esperas más de 30 días para restaurar.

—

12. Conclusión

restic en 2026 cubre el caso del 90% de sysadmins y usuarios avanzados: repositorio cifrado, deduplicado, verificable y movible. La mayor parte del trabajo está en operarlo bien: automatizar con timers de systemd, vigilar el espacio, y probar restores periódicamente. Si haces backup sin haber restaurado nunca, no tienes 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