Restic: sacar los datos de tu VPS fuera del servidor

Por qué una copia de seguridad en el mismo servidor no es una copia de seguridad

Restic es una herramienta de copia de seguridad gratuita y de código abierto que envía instantáneas cifradas y deduplicadas de sus archivos a un repositorio ubicado en otro lugar: un segundo VPS, un equipo en casa o un almacenamiento de objetos compatible con S3. Esta guía configura Restic en Ubuntu 24.04, desde la instalación hasta un repositorio mediante SFTP, una primera copia de seguridad, un temporizador nocturno de systemd, una política de retención y la prueba de restauración que demuestra que todo funciona. El destino debe ser otra máquina, porque una copia almacenada en el mismo servidor desaparece junto con el servidor.

Un directorio backup/ en el equipo del que realiza la copia de seguridad sólo le protege de una cosa: borrar un archivo por accidente. No sobrevive a un fallo del disco, porque estaba en ese disco. No sobrevive a un atacante con root, porque primero elimina las copias. Tampoco sobrevive a un error de cuenta que elimine el VPS. El centro de datos menos eficiente del mundo bromea sobre un archivo tar llamado backup_final_v2_REAL situado en la misma matriz que los datos, y el chiste funciona porque muchos hemos hecho exactamente eso. La regla es mantener la copia fuera del equipo, y restic es la forma menos complicada de cumplirla.

Restic en cuatro ideas

Repositorio. Es el lugar donde restic escribe los datos. Es un directorio con el formato propio de restic, lleno de blobs cifrados que sólo restic puede leer. Nunca lo edite manualmente. Acceda a él mediante los comandos de restic y la dirección -r.

Snapshot. Es una imagen de los archivos incluidos en la copia de seguridad en un momento concreto. Cada ejecución de la copia crea un snapshot. Cada snapshot se puede restaurar de forma independiente y se comporta como una copia completa de los datos en ese momento.

Deduplicación. Restic divide los archivos en fragmentos definidos por su contenido y carga sólo los fragmentos que el repositorio no conoce. La primera copia carga todos los datos. Cada ejecución posterior carga aproximadamente lo que haya cambiado. Un snapshot nocturno de 20 GB con 50 MB modificados ocupa unos 50 MB adicionales. Por eso es barato conservar decenas de snapshots.

Cifrado de forma predeterminada. Un repositorio de restic siempre está cifrado (AES-256) y todos los comandos necesitan la contraseña del repositorio. El host de copias de seguridad o el proveedor de almacenamiento sólo ve blobs cifrados. La consecuencia importante es la siguiente: si pierde la contraseña, los datos desaparecen de forma permanente y por diseño. Conserve una copia de la contraseña en una ubicación que no sea este servidor. Esto es tan importante que se menciona dos veces más abajo.

Instalar restic en Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

En Ubuntu 24.04 se instala restic 0.16.4, mientras que la versión actual del proyecto es 0.19.1. La diferencia existe porque una versión LTS (soporte a largo plazo) congela las versiones de sus paquetes. Aquí no supone un problema: 0.16.4 incluye todo lo necesario para esta guía. Si quiere la versión más reciente por sus mejoras de velocidad, descargue la compilación oficial de un solo binario desde la página de versiones del proyecto restic en GitHub, descomprímala con bunzip2 e instálela en /usr/local/bin/restic. No se necesita nada más para instalar restic.

Cree el repositorio en otro servidor mediante SFTP

Necesita una máquina de destino: lo habitual es usar un segundo VPS pequeño, aunque sirve cualquier equipo con un servidor SSH y espacio de disco disponible. Restic admite SFTP (transferencia de archivos mediante SSH), por lo que no es necesario instalar nada en el host de copias de seguridad. En esta guía, el host de copias de seguridad es 10.0.0.12 y usa un usuario llamado restic. No llame a ese usuario backup: Ubuntu y Debian incluyen en todas las instalaciones una cuenta de sistema reservada llamada backup (uid 34, sin shell de inicio de sesión), por lo que adduser backup falla y ssh backup@... termina en nologin.

La tarea nocturna se ejecutará como root en el servidor del que se hacen las copias de seguridad, por lo que root necesita autenticarse mediante una clave en el host de copias de seguridad. Cree una clave dedicada sin frase de contraseña, porque no habrá ninguna persona que la introduzca a las 3am, y cópiela:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Si no está familiarizado con las claves, conceptos básicos de la gestión de claves SSH explica el modelo, los permisos y cómo revocar una clave posteriormente.

A continuación, la contraseña del repositorio. Genere una contraseña segura en un archivo al que sólo pueda acceder root:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Copie ahora esa contraseña en su gestor de contraseñas antes de continuar. Si este VPS falla, el repositorio y esta contraseña permiten restaurarlo todo; el repositorio sin la contraseña no permite restaurar nada.

Inicialice el repositorio:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

La alternativa de destino es el almacenamiento de objetos compatible con S3, que es la opción adecuada si no quiere administrar una segunda máquina. Cualquier bucket compatible con S3 funciona del mismo modo; sólo cambian la dirección y dos variables de credenciales:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

Todo lo que aparece después de init es idéntico para ambos destinos. El resto de esta guía muestra la dirección SFTP; sustitúyala por la suya.

La primera copia de seguridad, con exclusiones

Haga una copia de seguridad de los datos que no puede reinstalar, no de todo el sistema de archivos. El sistema operativo se recupera mediante una reinstalación; la configuración y los datos no. En un VPS típico, esto incluye /etc, /home y las ubicaciones donde las aplicaciones almacenan su estado, como /srv o /var/www. Excluya las cachés porque ocupan mucho espacio, cambian a diario y se regeneran automáticamente:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

La primera ejecución carga todo, por lo que tarda un tiempo. Ejecute de nuevo el mismo comando y terminará en segundos. Indicará que han cambiado algunos archivos y que se han añadido algunos MiB, porque la deduplicación sólo carga los fragmentos nuevos. Muestre lo que tiene:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Cada instantánea muestra un ID, una hora y las rutas que contiene. Esos ID son los que se utilizan para restaurar los datos.

Ejecuciones nocturnas con un temporizador de systemd

Escribir la dirección del repositorio en cada comando resulta tedioso, y una copia de seguridad que se ejecuta manualmente deja de hacerse al cabo de un mes. Ambos problemas se resuelven con un script y un temporizador. El script define las dos variables de entorno que lee restic, RESTIC_REPOSITORY y RESTIC_PASSWORD_FILE, de modo que todos los comandos que contiene sean más cortos:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

Las líneas forget y check se explican en las dos secciones siguientes. Ahora, la programación: un servicio oneshot que ejecuta el script y un temporizador que lo activa cada noche a las 03:00. Aquí, un temporizador es preferible a una línea de cron porque la ejecución queda registrada en el journal y Persistent=true ejecuta una copia de seguridad pendiente en cuanto el servidor vuelve a estar disponible tras una interrupción.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Habilite el temporizador. Después, ejecute el servicio una vez manualmente y supervise su ejecución:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers muestra cuándo se ejecutará la próxima vez. También puede generar el par de archivos de unidad en lugar de escribirlos manualmente:

El patrón completo de estos dos archivos, incluida la sintaxis de calendario y las directivas de refuerzo de seguridad que puede incluir un servicio, se explica en ejecutar un programa como servicio de systemd en un VPS.

Una copia de seguridad es un rumor hasta que la restaura

Trate esa frase como un mandamiento. Un trabajo de copia de seguridad que termina correctamente todas las noches sólo demuestra que el trabajo se ejecutó; no demuestra que los datos puedan recuperarse. Dos comprobaciones cierran esa brecha.

Primero, restic check, que el script ya ejecuta cada noche. Verifica la estructura del repositorio y el índice, por lo que la corrupción silenciosa en el host de copias de seguridad se detecta la noche siguiente y no el día de la restauración. Una vez al mes, ejecute la versión más profunda, que descarga y verifica criptográficamente una décima parte aleatoria de los datos reales:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

Como el subconjunto es aleatorio cada vez, las ejecuciones mensuales recorren todo el repositorio sin tener que descargarlo por completo.

Segundo, la prueba de restauración. Desde la shell de root anterior, restaure un directorio real de la instantánea más reciente en una ubicación temporal y compárelo con los archivos activos:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

Que diff no muestre nada significa que todos los bytes se recuperaron de forma idéntica. Esa es la única evidencia que cuenta. Elimine /srv/restore-drill después. Realice esta prueba cada mes y, una o dos veces al año, haga la versión completa: restaure toda la instantánea más reciente en un VPS temporal y compruebe que la aplicación realmente se inicia desde ella. El día que necesite que esto funcione bajo presión, querrá que sea un procedimiento que ya haya ejecutado.

Retención: olvidar y depurar

Sin una política, las instantáneas se acumulan indefinidamente y el repositorio sólo crece. La línea forget del script aplica una política cada noche: --keep-daily 7 conserva una instantánea por día de los últimos siete días, --keep-weekly 4 una por semana durante cuatro semanas y --keep-monthly 6 una por mes durante seis meses. Las instantáneas que no están protegidas por ninguna regla se olvidan.

forget por sí solo sólo elimina los registros de las instantáneas; los bloques de datos permanecen en el repositorio hasta que algún proceso los elimina. Eso es lo que hace --prune: busca los bloques a los que ya no hace referencia ninguna instantánea y los elimina. En ese momento se libera realmente el espacio en disco. La depuración realiza trabajo real en el repositorio, por lo que en un repositorio grande algunas personas ejecutan forget cada noche y --prune cada semana; en VPS de tamaño habitual, ejecutarlo cada noche es suficiente.

Bases de datos: primero cree el volcado y después haga una copia de seguridad del volcado

Restic copia los archivos a medida que los lee, mientras la base de datos escribe continuamente en ellos. Si se captura un archivo de base de datos durante una escritura, se restaura como una base de datos dañada porque la copia mezcla páginas anteriores y posteriores a la escritura. La solución es estándar: haga que el motor de la base de datos genere una exportación coherente en un archivo y, después, deje que restic haga una copia de seguridad de ese archivo.

En PostgreSQL, añada una línea de volcado al principio de restic-backup.sh, antes del comando restic backup, e incluya el directorio del volcado en las rutas de la copia de seguridad:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

mysqldump cumple la misma función para MariaDB y MySQL. Para ver un ejemplo completo de este patrón, la sección de copias de seguridad de Nextcloud activa el modo de mantenimiento, vuelca Postgres y copia los archivos como un conjunto coherente, exactamente el conjunto que restic debe sacar del servidor cada noche. Con SQLite se aplica la misma idea con un método más sencillo: la guía de Vaultwarden detiene el contenedor durante unos segundos para hacer una copia en frío de db.sqlite3, y ese archivo es el que restic saca del servidor.

FAQ

¿Las copias de seguridad de restic están cifradas?

Sí, siempre. Todos los repositorios de restic están cifrados con AES-256. No existe un modo sin cifrado y todos los comandos requieren la contraseña del repositorio. La máquina o el proveedor que almacena el repositorio sólo conserva blobs cifrados, por lo que un servidor de copias de seguridad comprometido no expone sus archivos. La condición es absoluta: sin la contraseña, nadie puede recuperar los datos. Por tanto, guarde una copia fuera del servidor.

¿restic realiza copias de seguridad incrementales?

Cada snapshot de restic se comporta como una copia de seguridad completa, pero consume almacenamiento incremental. Restic divide los archivos en bloques y carga sólo los bloques que el repositorio todavía no tiene. Por eso, una ejecución nocturna transfiere aproximadamente lo que cambió ese día. A diferencia de los esquemas incrementales tradicionales, no existe una cadena que haya que reproducir. Cualquier snapshot se restaura directamente y eliminar un snapshot antiguo nunca rompe uno más reciente.

¿Cómo restauro archivos desde una copia de seguridad de restic?

Ejecute restic snapshots para obtener el ID del snapshot y después restic restore <id> --target /some/empty/dir para restaurarlo. Añada --include /path para restaurar sólo una parte. latest funciona en lugar de un ID. Restic vuelve a crear la estructura de directorios original bajo el destino, por lo que restaurar /etc/ssh termina en /some/empty/dir/etc/ssh. Practique este procedimiento antes de necesitarlo, porque una copia de seguridad no probada es sólo una suposición.

¿Con qué frecuencia debo ejecutar restic backup?

Cada noche es el mínimo razonable para un servidor y la deduplicación mantiene bajo el coste: cada ejecución carga sólo los bloques que cambiaron desde la anterior. Los datos que cambian rápidamente, o cuya pérdida de un solo día sería grave, pueden copiarse cada pocas horas con el mismo patrón de temporizador. La frecuencia es sólo la mitad del trabajo. Ejecute también restic check con regularidad y haga una prueba de restauración mensual, porque un calendario sin verificación produce una falsa sensación de seguridad.

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

Las copias de seguridad no se pueden recuperar. El cifrado de restic no tiene puerta trasera ni mecanismo de restablecimiento, por lo que la contraseña es tan importante como las propias copias de seguridad. Guarde una copia en su gestor de contraseñas y en cualquier otro lugar duradero que no sea el servidor respaldado. Mientras aún tenga acceso, restic key add puede registrar una segunda contraseña para el mismo repositorio, lo que le proporciona una contraseña de reserva.