Copias de seguridad con restic

Módulo 8: Copias de seguridad y monitorización · Tiempo de lectura: 12 minutos

Objetivo de aprendizaje: Después de esta lección podrá crear con restic copias de seguridad cifradas en un almacenamiento fuera de su servidor, eliminar versiones antiguas según un esquema de retención, comprobar la copia de seguridad y restaurar archivos, y hacer que todo funcione de forma automática.

Conceptos clave: restic, repositorio, init, contraseña (archivo de contraseña), backend (sftp, S3, rest-server), backup, snapshots, forget, --keep-daily/--keep-weekly/--keep-monthly, prune, check, restore, mount, deduplicación, append-only, temporizador de systemd

¿Por qué restic?

Existen muchos programas de copias de seguridad. restic es una buena elección para un servidor propio, porque:

• cifra todo antes de que salga del servidor; el almacenamiento solo ve bloques ilegibles;
• deduplica: un archivo que no ha cambiado no se vuelve a guardar, así que las copias diarias ocupan poco espacio;
• admite muchos tipos de almacenamiento: una carpeta, otro servidor por SFTP, almacenamiento compatible con S3, un rest-server propio;
• es un único programa, disponible en los repositorios de paquetes de Debian y Ubuntu (apt install restic).

Una alternativa con características similares es BorgBackup. Los principios de esta lección también se aplican a ella.

Los conceptos

• Repositorio: el lugar donde restic guarda las copias de seguridad. Siempre fuera del servidor del que hace la copia.
• Snapshot: una copia de seguridad en un momento concreto. (Atención: no es lo mismo que la snapshot de su proveedor de la lección 8.1.)
• Contraseña: cada repositorio tiene una contraseña con la que se cifra todo. La documentación de restic es clara al respecto: quien pierde la contraseña pierde los datos de forma irreversible.

Crear un repositorio

Supongamos que tiene un servidor de almacenamiento backup.example.net al que puede acceder por SFTP con una clave, como usuario web1. Cree primero un archivo de contraseña en el servidor (y guarde la misma contraseña en su gestor de contraseñas, lección 8.1):

root@web1:~# install -m 600 /dev/null /root/.restic-wachtwoord
root@web1:~# openssl rand -base64 32 > /root/.restic-wachtwoord
root@web1:~# export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
root@web1:~# export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
root@web1:~# restic init
created restic repository 5f1a9c2e3b at sftp:web1@backup.example.net:/srv/restic/web1

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Con las variables de entorno RESTIC_REPOSITORY y RESTIC_PASSWORD_FILE no necesita escribir cada vez las opciones -r y --password-file.

Crear una copia de seguridad

Primero el volcado de la base de datos (lección 8.1), después la copia de seguridad:

root@web1:~# restic backup /etc /var/www /opt /var/backups/db \
    --exclude /var/www/*/cache --tag dagelijks
repository 5f1a9c2e opened (version 2, compression level auto)
...
Files:        8421 new,     0 changed,     0 unmodified
Dirs:         1203 new,     0 changed,     0 unmodified
Added to the repository: 612.338 MiB (402.117 MiB stored)

processed 8421 files, 1.204 GiB in 0:41
snapshot 3c7e91d4 saved

Al día siguiente es mucho más rápida: solo se incluye lo que ha cambiado.

root@web1:~# restic snapshots
ID        Time                 Host  Tags       Paths
-----------------------------------------------------------------------
3c7e91d4  2026-11-08 03:10:02  web1  dagelijks  /etc /opt /var/backups/db /var/www
a18f0b77  2026-11-09 03:10:05  web1  dagelijks  /etc /opt /var/backups/db /var/www
-----------------------------------------------------------------------
2 snapshots

Limpiar: forget y prune

Una snapshot más cada día significa 365 snapshots al cabo de un año. Con forget decide cuáles conserva, mediante un esquema de retención:

root@web1:~# restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Así funciona el esquema:

• --keep-daily 7: mira los últimos siete días en los que hay una snapshot y conserva la más reciente de cada día;
• --keep-weekly 4: lo mismo para las últimas cuatro semanas (de lunes a domingo);
• --keep-monthly 6: lo mismo para los últimos seis meses.

Una snapshot se conserva si cumple al menos una de las reglas. Todo lo que no cumple ninguna regla se olvida. Pruebe primero un esquema nuevo con --dry-run: así verá qué se eliminaría sin que cambie nada.

Diferencia importante: forget solo elimina la referencia a una snapshot. Los datos permanecen en el repositorio hasta que prune limpia los bloques que ya no utiliza ninguna snapshot. La opción --prune de forget lo hace todo de una vez. Prune lleva tiempo y bloquea el repositorio; por eso no lo programe a la misma hora que su copia de seguridad.

Comprobar: check

Una copia de seguridad que se daña en silencio solo la detecta al restaurar. Haga que restic compruebe el repositorio con regularidad:

root@web1:~# restic check
...
no errors were found
root@web1:~# restic check --read-data-subset=5%

Un simple check comprueba la estructura. Con --read-data-subset también vuelve a leer realmente una parte de los datos y comprueba su contenido. Hágalo, por ejemplo, cada semana con un pequeño porcentaje; así, con el tiempo, todo se habrá leído alguna vez.

Restaurar: restore y mount

Restaure en una carpeta aparte, nunca directamente sobre el original:

root@web1:~# restic restore latest --target /tmp/terug --include /etc/nginx
restoring snapshot a18f0b77 of [/etc /opt /var/backups/db /var/www] at 2026-11-09 03:10:05 ...
Summary: Restored 41 files/dirs (88.104 KiB) in 0:00
root@web1:~# diff -r /tmp/terug/etc/nginx /etc/nginx && echo gelijk
gelijk

latest es la snapshot más reciente; también puede usar un ID (restic restore 3c7e91d4 ...). Con restic mount /mnt/restic (requiere FUSE) ve todas las snapshots como carpetas y puede explorarlas y copiar archivos sueltos. Para detenerlo, pulse Ctrl+C.

Una base de datos se restaura recuperando el volcado e importándolo, por ejemplo gunzip < alles.sql.gz | mariadb.

Automático, cada noche

Cree un script y un temporizador de systemd (lección 6.3). El script:

#!/bin/sh
# /usr/local/sbin/backup.sh
set -eu
export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles.sql.gz
restic backup /etc /var/www /opt /var/backups/db --tag dagelijks
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Un .service con Type=oneshot y ExecStart=/usr/local/sbin/backup.sh, y un .timer con OnCalendar=*-*-* 03:10:00 y Persistent=true. set -eu hace que el script se detenga en el primer error, de modo que systemd considere fallida la ejecución. Asocie una alerta (lección 8.3); si no, no se enterará de que una copia de seguridad ha fallado.

Contra el ransomware: append-only

Con el script anterior, el propio servidor también puede borrar la copia de seguridad (forget y prune). Por tanto, si un atacante se hace con el servidor, también puede hacerlo él. Dos formas de evitarlo:

• rest-server en modo append-only: en el servidor de almacenamiento ejecuta el rest-server propio de restic con la opción --append-only. El servidor web puede entonces añadir copias de seguridad, pero no borrar nada. La limpieza (forget --prune) la hace desde otra máquina bien protegida y con permisos completos.
• Almacenamiento con control de versiones o bloqueo de objetos en un proveedor S3, para que los objetos eliminados se puedan recuperar durante un tiempo.

Tenga en cuenta una trampa sutil que menciona la propia documentación de restic: un atacante que añade snapshots falsas puede hacer que un esquema como --keep-weekly olvide snapshots reales. Con --keep-within (por ejemplo --keep-within 30d) se conserva todo lo de ese periodo, falso o real.

Resumen

• restic cifra, deduplica y puede guardar en muchos tipos de almacenamiento fuera de su servidor; si pierde la contraseña, lo pierde todo.
• init crea el repositorio, backup una snapshot, snapshots las muestra.
• forget con --keep-* determina lo que conserva; solo prune (o --prune) elimina realmente los datos. Pruebe con --dry-run.
• check (con --read-data-subset) comprueba, restore --target restaura en una carpeta aparte, mount le permite explorar.
• Automatice con un temporizador y una alerta, y mantenga al menos un repositorio fuera del alcance del servidor (append-only).

Cuestionario

Ejercicio

Ejercicio Z8.2: ¿Qué queda después de forget? El archivo de ejemplo restic-snapshots.txt contiene una lista de snapshots y un esquema de retención. Determine qué snapshots quedan después de restic forget con ese esquema. El programa lo compara con la clave fija.

Ejercicio O8.2: Una prueba de restauración. Cree en su propio servidor un repositorio restic fuera del servidor, haga una copia de seguridad de /etc y de sus datos, y restaure una carpeta en /tmp/terug. Compare con diff, anote cuánto tiempo tardó y responda dónde están guardados, fuera del servidor, su contraseña y sus datos de acceso al almacenamiento.

Para saber más

• Estrategia de copias de seguridad: la regla 3-2-1 para su propia empresa
• Documentación de restic, Preparing a new repository: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
• Documentación de restic, Removing backup snapshots (forget y prune): https://restic.readthedocs.io/en/stable/060_forget.html
• Documentación de restic, Restoring from backup: https://restic.readthedocs.io/en/stable/050_restore.html
• rest-server (append-only): https://github.com/restic/rest-server