Cómo instalar restic para copias de seguridad cifradas

Actualizado: 2026-05-03

Las copias de seguridad son la disciplina donde más se aprende por las malas y menos se escribe sobre ello hasta que duele. Después de varios incidentes —copias que existían pero no eran restaurables, destinos en el mismo servidor que se quemó, cifrado que resultó estar desactivado— he acabado con una rutina basada en restic que cubre lo básico sin pretender ser ingeniería aeroespacial. Esta entrada documenta cómo instalarla en Debian, configurar un repositorio cifrado en almacenamiento S3 compatible, automatizar copias diarias con systemd y, crucialmente, verificar que la restauración funciona antes de necesitarla.

Puntos clave

• restic cifra todo en el cliente con AES-256; el operador del almacenamiento no ve nada útil.
• La deduplicación por bloques variables hace que las copias incrementales sean rápidas: solo viajan los bloques nuevos.
• La contraseña del repositorio es tan importante como los datos: si se pierde, no hay recuperación posible.
• La verificación semanal de restauración no es opcional; un repositorio al que nunca se ha hecho restore es una ilusión.
• El par timer + service de systemd da mejor observabilidad que cron, con métricas Prometheus y alertas de ausencia.

Por qué restic

Las opciones en el espacio de copias de seguridad abiertas y maduras son varias:

• restic — cifrado cliente, S3 nativo, repositorio estable y sin servidor remoto que mantenga estado.
• borg — excelente pero exige un servicio escuchando en el destino.
• duplicity — más antiguo; trabaja con ficheros de parche encadenados que complican restauraciones parciales.
• kopia — moderno pero aún rotando piezas en su ecosistema.

La razón por la que uso restic en la mayoría de casos es la combinación de tres propiedades: escribe en cualquier repositorio S3 compatible sin capas extra, tiene un modelo de cifrado simple y verificable, y su formato de repositorio lleva años estable con alta confianza en la comunidad. restic cifra todo en el cliente con AES-256 antes de enviarlo. El operador del almacenamiento no ve nada, salvo tamaños y metadatos opacos. Deduplica a nivel de bloque variable de forma que un fichero modificado solo transmite los bloques cambiados.

Instalación en Debian 13

La instalación en Debian es directa. El paquete del repositorio oficial suele ir un par de versiones por detrás, así que para producción prefiero instalar desde los binarios oficiales del proyecto, que salen firmados y son fáciles de verificar:

VERSION=0.18.0
curl -LO "https://github.com/restic/restic/releases/download/v${VERSION}/restic_${VERSION}_linux_amd64.bz2"
curl -LO "https://github.com/restic/restic/releases/download/v${VERSION}/SHA256SUMS"
grep "restic_${VERSION}_linux_amd64.bz2" SHA256SUMS | sha256sum -c -
bunzip2 restic_${VERSION}_linux_amd64.bz2
sudo install -m 0755 restic_${VERSION}_linux_amd64 /usr/local/bin/restic

Alternativamente se puede usar apt install restic y aceptar la versión del repositorio, que para la mayoría de casos sirve. La diferencia práctica son correcciones de errores y mejoras de rendimiento en versiones recientes.

Configurar un repositorio en S3 compatible

restic trabaja con muchos tipos de repositorio: directorio local, SFTP, S3, Backblaze B2, Azure, Google Cloud Storage. El caso que cubro aquí es un repositorio en un servicio S3 compatible, que es el patrón que mejor separa datos de copias del servidor protegido. Hetzner Object Storage, Backblaze B2, Wasabi o un bucket en AWS funcionan bien.

Lo primero es generar credenciales con permiso mínimo:

• Solo crear objetos, listarlos y leerlos en el bucket destino.
• No hace falta permiso de borrado: restic gestiona sus propios ciclos de vida y los borrados pueden hacerse con una credencial distinta para limitar el radio de un compromiso.

# Variables de entorno y contraseña
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export RESTIC_REPOSITORY="s3:https://fsn1.your-objectstorage.com/mi-bucket-backup"
export RESTIC_PASSWORD_FILE=/etc/restic-password
openssl rand -base64 48 | sudo tee /etc/restic-password > /dev/null
sudo chmod 400 /etc/restic-password

# Inicialización y primera copia
restic init
restic backup --tag primera --exclude-file /etc/restic-excludes 
    /home /etc /var/lib/docker/volumes /opt

# Restauración de prueba (parte del script semanal)
TEMPDIR=$(mktemp -d)
restic restore latest --target "$TEMPDIR" --include /etc/hostname
test "$(cat $TEMPDIR/etc/hostname)" = "$(hostname)" && echo "restore_ok" || echo "restore_fail"
rm -rf "$TEMPDIR"

La contraseña guardada en /etc/restic-password es lo único que se necesita para descifrar el repositorio. Guardarla además en una ubicación secundaria fuera del servidor es parte fundamental de la estrategia: si se pierde, se pierde el repositorio entero aunque los datos sigan en el bucket. Un gestor de contraseñas, una caja fuerte física con el valor impreso, otro servidor que la replique. La opción concreta importa menos que tener al menos dos copias independientes.

Primera copia de seguridad

El fichero de exclusiones merece cuidado. Hay directorios que no conviene incluir:

• /tmp y cualquier sitio con cachés grandes o sockets Unix.
• Las rutas de los propios datos del gestor de contenedores si ya cubres sus volúmenes.
• Ficheros sensibles no cifrados que no deben viajar al repositorio aunque restic los cifre.

La primera copia tarda porque transmite todo. Las siguientes son mucho más rápidas porque restic deduplica contra lo ya presente: solo viajan los bloques nuevos. En mi experiencia una copia incremental sobre un servidor con decenas de gigas de datos tarda entre treinta segundos y dos minutos, dominado por la enumeración de ficheros más que por la red.

Automatización con systemd

El patrón que uso es un par timer + service, porque da mejor observabilidad y control que cron. El servicio:

• Declara Type=oneshot y lee un EnvironmentFile=/etc/restic/restic.env con las credenciales.
• Ejecuta un script que hace la copia, aplica forget con política de retención (últimos siete diarios, cuatro semanales, doce mensuales) y ejecuta prune para liberar espacio.
• Escribe métricas en /var/lib/node-exporter/textfile/restic.prom con éxito, duración y tamaño.

El timer usa OnCalendar=*-*-* 02:00:00, RandomizedDelaySec=30m para evitar tormentas, y Persistent=true para recuperar copias perdidas si el servidor estuvo apagado. Las unidades se activan con systemctl enable --now restic-backup.timer.

Las métricas se vigilan con reglas de alerta que avisan si la copia falla o si no se ha ejecutado en más de 36 horas. El segundo tipo de alerta, el de ausencia de métrica, atrapa fallos silenciosos donde el script ni siquiera llega a escribir resultado — el mismo principio que aplicamos en la monitorización de servicios críticos con herramientas como Uptime Kuma para monitorización básica.

Verificación de restauración

La parte que se olvida con más frecuencia y la que duele más cuando toca. Un repositorio al que nunca se ha hecho restore no es una copia de seguridad, es una ilusión. La rutina que mantengo es semanal: un timer distinto dispara un script que elige un snapshot reciente, extrae un subconjunto conocido a un directorio temporal, compara contra una instantánea de referencia y reporta el resultado. Si la verificación falla, llega una alerta inmediata.

Además del restore de muestra, una vez por semana ejecuto restic check --read-data-subset=5% que verifica integridad de una fracción del repositorio leyendo y comparando contra los hashes almacenados. En seis meses he detectado dos fallos: uno fue una credencial expirada que el script no reportaba como error, otro fue un bloque corrompido que el proveedor de almacenamiento repuso tras abrir incidencia. Sin la verificación semanal ninguno se habría detectado hasta el desastre.

Conclusión

La propuesta mínima razonable para un servidor en producción es esta: restic instalado desde binarios verificados, repositorio en un proveedor S3 independiente del servidor, contraseña replicada fuera del servidor en al menos dos sitios, copia diaria por systemd con política de retención, restauración de muestra semanal y alerta si algo de esto falla o deja de reportar métricas. Todo eso se monta en una tarde la primera vez y evita la clase de desastre que acaba carreras. El tiempo dedicado en frío es trivial comparado con el que se ahorra cuando algo sale mal.

Combinado con una infraestructura bien monitorizada —por ejemplo Dokku como PaaS mínimo o Kubernetes con alertas SRE— restic cierra el ciclo de seguridad básica sin complejidad innecesaria.