Respaldos de servidores Linux con restic y BorgBackup: guía práctica

Para respaldos a nivel de archivos en servidores Linux, restic y BorgBackup son las dos opciones de código abierto probadas. Ambas cifran los datos en el servidor antes de que salgan, deduplican para que los respaldos diarios ocupen poco y conservan muchos puntos de restauración. Una buena configuración tiene cinco partes: un repositorio cifrado en otra máquina u otro proveedor, volcados de las bases de datos justo antes de cada respaldo, una política de retención aplicada con forget/prune, un temporizador de systemd que lo ejecuta sin intervención, y monitoreo junto con pruebas de restauración periódicas. Lo ideal es que el servidor respaldado no pueda borrar sus propios respaldos.

Esta guía aplica a servidores actuales con Debian 12/13, Ubuntu 24.04 y RHEL/AlmaLinux 9/10. Si usa máquinas virtuales en Proxmox, los respaldos a nivel de imagen se explican en nuestra guía de Proxmox Backup Server; los respaldos de archivos los complementan.

¿restic o Borg?

Ambos son maduros y están bien documentados. Las diferencias prácticas:

	restic	BorgBackup
Destinos de almacenamiento	Local, SFTP, REST server, compatible con S3, Azure, Google Cloud Storage, rclone	Local o SSH (Borg debe estar instalado en el lado remoto)
Cifrado	Siempre activo (AES-256 con autenticación Poly1305)	Se elige en borg init; repokey con una frase de contraseña fuerte es la opción general documentada
Protección ante un cliente comprometido	rest-server --append-only	borg serve --append-only mediante comando forzado de SSH
Paquetes	Un solo binario en Go; en Debian, Ubuntu y EPEL	En Debian, Ubuntu y EPEL; esta guía usa la serie estable 1.4

Elija restic si quiere almacenamiento de objetos (buckets compatibles con S3) o un solo binario en todas partes. Elija Borg si respalda a su propio servidor SSH y le gustan sus opciones flexibles de compresión. No use ambos sobre los mismos datos; elija uno y hágalo bien.

Elija el que elija, guarde la contraseña o la llave del repositorio fuera del servidor, por ejemplo en su gestor de contraseñas. Ambos proyectos son explícitos: si pierde la contraseña (y en Borg, la llave), los respaldos no se pueden leer. En Borg, exporte la llave con borg key export y guárdela en un lugar seguro.

Paso 1: Primero, vuelque las bases de datos

Copiar los archivos en uso de una base de datos PostgreSQL o MySQL/MariaDB en funcionamiento no produce un respaldo consistente. Primero haga un volcado (dump) y luego respalde ese volcado.

## PostgreSQL: formato personalizado, restaurable con pg_restore
sudo -u postgres pg_dump -Fc appdb > /var/backups/db/appdb.dump

## MySQL / MariaDB (InnoDB): volcado consistente sin bloquear tablas
mysqldump --single-transaction --routines --triggers appdb > /var/backups/db/appdb.sql
## En MariaDB la misma herramienta también se llama mariadb-dump

restic también puede enviar un volcado directamente al repositorio, sin archivo temporal:

restic backup --stdin-filename appdb.sql \
  --stdin-from-command -- mysqldump --single-transaction appdb

restic revisa el código de salida del comando: si el volcado falla, no se crea ninguna instantánea y restic termina con error, que es exactamente lo que usted quiere.

Paso 2: Cree el repositorio

Mantenga el repositorio fuera del servidor: otro servidor en una ubicación distinta, un equipo de respaldo o un bucket compatible con S3. Un repositorio en el mismo disco solo protege contra errores humanos.

restic

Ponga la configuración en un archivo de entorno que solo root pueda leer, /etc/restic/env (modo 600):

RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/web01
RESTIC_PASSWORD_FILE=/etc/restic/password

Para almacenamiento compatible con S3, use en su lugar estas líneas:

RESTIC_REPOSITORY=s3:https://s3.example-provider.com/company-backups/web01
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...

sudo bash -c 'set -a; . /etc/restic/env; restic init'

SFTP requiere inicio de sesión SSH con llave hacia el servidor de respaldo, porque un respaldo automático no puede responder a una solicitud de contraseña.

Borg

export BORG_PASSCOMMAND="cat /etc/borg/passphrase"
borg init --encryption=repokey [email protected]:/srv/borg/web01
borg key export [email protected]:/srv/borg/web01 /root/web01-borg-key.txt
## Lleve ese archivo de llave a su gestor de contraseñas y luego bórrelo del servidor

La documentación de Borg recomienda repokey con una frase de contraseña fuerte como opción general, y repokey-blake2 si el procesador no tiene aceleración por hardware para SHA-256.

Paso 3: Haga los respaldos de solo anexado (append-only)

El ransomware y los intrusos atacan cada vez más los respaldos. Si el servidor puede borrar su propio repositorio, un atacante que controle el servidor también puede. Ambas herramientas ofrecen un modo append-only en el que el cliente puede agregar respaldos, pero no borrar ni modificar los existentes:

• restic: ponga el repositorio detrás de rest-server con --append-only (y --private-repos para que cada servidor vea solo su propio repositorio).
• Borg: en el servidor de respaldo, restrinja la llave SSH del cliente en ~/.ssh/authorized_keys:

command="borg serve --append-only --restrict-to-path /srv/borg/web01",restrict ssh-ed25519 AAAA... web01-backup

La contrapartida: la depuración de respaldos antiguos debe hacerse desde una máquina de administración separada y bien protegida, con acceso completo, no desde el cliente. La documentación de Borg también advierte que la compactación no hace nada en modo append-only y que una depuración posterior en modo normal vuelve permanentes los borrados, así que verifique el repositorio (borg check --verify-data) antes de depurar. Las instantáneas o el versionado del lado del almacenamiento en el servidor de respaldo, que el cliente no puede cambiar, agregan otra capa. Esta es la idea de "copia inmutable" detrás de la estrategia de respaldo 3-2-1.

Paso 4: Ejecute los respaldos con un temporizador de systemd

Los temporizadores de systemd son más fáciles de monitorear que las tareas de cron: cada ejecución queda registrada en el journal, y Persistent=true recupera una ejecución perdida mientras el servidor estaba apagado.

/etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStartPre=/usr/local/sbin/dump-databases.sh
ExecStart=/usr/bin/restic backup --exclude-file=/etc/restic/excludes /etc /home /srv /var/backups/db
Nice=10
IOSchedulingClass=idle

/etc/systemd/system/restic-backup.timer:

[Unit]
Description=Nightly restic backup

[Timer]
OnCalendar=*-*-* 01:30:00
RandomizedDelaySec=20m
Persistent=true

[Install]
WantedBy=timers.target

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

El equivalente en Borg llama a borg create con un nombre de archivo como '{hostname}-{now}' y --compression lz4, seguido de borg prune y borg compact (cuando el repositorio no es append-only).

Paso 5: Retención con forget y prune

Decida hasta qué fecha necesita poder volver y deje que la herramienta lo aplique. Una política común es 7 puntos diarios, 4 semanales y 12 mensuales.

## restic: primero una vista previa, luego aplicar
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --dry-run
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

## Borg
borg prune --glob-archives '{hostname}-*' --keep-daily 7 --keep-weekly 4 --keep-monthly 12
borg compact

Dos detalles de la documentación oficial importan aquí. En restic, forget solo elimina las referencias a las instantáneas; los datos se borran realmente con prune (o forget --prune), y la depuración bloquea el repositorio, así que prográmela lejos de los respaldos. En Borg, el filtro --glob-archives '{hostname}-*' evita que la depuración de un servidor toque los archivos de otro servidor en un repositorio compartido.

Paso 6: Verifique la integridad y pruebe restauraciones

Un respaldo que nunca ha restaurado es una esperanza, no un respaldo.

## restic: verificar la estructura y leer una muestra de los datos reales
restic check --read-data-subset=5%

## restaurar un directorio en una ubicación temporal
restic restore latest --target /tmp/restore-test --include /etc

## Borg
borg check [email protected]:/srv/borg/web01
borg extract --dry-run [email protected]:/srv/borg/web01::web01-2026-10-27T01:30:00

Una vez por trimestre, haga un simulacro real: restaure un volcado de base de datos en un servidor de prueba, inicie la aplicación y confirme que los datos están al día. Anote cuánto tardó; ese es su tiempo de recuperación realista.

Paso 7: Monitoree las fallas

La mayoría de las fallas de respaldo son silenciosas: una credencial de nube vencida, un disco lleno, una contraseña cambiada. Vigílelas:

• Códigos de salida. restic termina con 0 si todo salió bien, con 1 ante un error fatal (sin instantánea) y con 3 cuando algunos archivos no se pudieron leer (instantánea incompleta). Trate el 3 como una advertencia que debe investigar, no como un éxito.
• Estado de systemd. systemctl status restic-backup.service y journalctl -u restic-backup.service muestran la última ejecución. Una unidad OnFailure= puede enviar una alerta.
• Un "interruptor de hombre muerto". Haga que la tarea informe su éxito a su sistema de monitoreo y que este alerte cuando ese informe no llegue, lo que también detecta un temporizador que nunca se ejecutó.
• Antigüedad de las instantáneas. restic snapshots --latest 1 o borg list --last 1 siempre deberían mostrar la fecha de anoche.

Lista de verificación de respaldos

• Repositorio en otra máquina u otro proveedor, cifrado, con la contraseña guardada fuera del servidor.
• Volcados de bases de datos antes de cada respaldo de archivos.
• Acceso append-only para el cliente; depuración desde una máquina de administración separada.
• Temporizador de systemd con Persistent=true y alertas de falla.
• Retención aplicada con forget --prune o prune + compact.
• Verificaciones de integridad mensuales y simulacros de restauración trimestrales.

¿Quiere que verifiquemos los respaldos de sus servidores?

Core Florida IT diseña y monitorea respaldos de servidores empresariales en Miami-Dade y todo el sur de Florida, con soporte remoto en todo el país, en servidores en la nube y dedicados y planes de soporte de TI administrado. Si no está seguro de que su último respaldo realmente se pueda restaurar, solicite una evaluación de TI gratuita y lo probaremos con usted.

Fuentes

• Documentación de restic: Backing up
• Documentación de restic: Preparing a new repository
• Documentación de restic: Removing backup snapshots
• restic rest-server (modo append-only)
• Documentación de BorgBackup: Quick Start
• Documentación de BorgBackup: Additional notes (modo append-only)
• Documentación de BorgBackup: borg init
• Manual de systemd.timer