Copias de seguridad automatizadas con BorgBackup: deduplicación, almacenamiento remoto y comprobaciones de RESTauración

En esta entrada explico cómo configurar de forma técnicamente sólida Copias de seguridad automatizadas con BorgBackup: desde la arquitectura del repositorio y el almacenamiento con deduplicación, pasando por el transporte remoto, hasta las comprobaciones de RESTauración automatizadas, las estrategias de prune y los pasos típicos de resolución de problemas. El objetivo son procesos operativos seguros para administradores, ingenieros de sistemas y operadores que prioricen la disponibilidad, integridad y mantenibilidad.

¿Por qué BorgBackup? Un breve resumen arquitectónico

BorgBackup (en adelante: Borg) es una herramienta de copias de seguridad a nivel de archivos que ofrece deduplicación dependiente del contenido, cifrado opcional de extremo a extremo y transferencias eficientes vía SSH. La deduplicación significa que se almacenan en el repositorio sólo una vez los tramos de datos idénticos (chunks); esto reduce considerablemente el espacio cuando se realizan copias repetidas. Borg guarda las copias en un repositorio, que puede residir localmente en un servidor o ser accesible por SSH mediante borg serve. La topología del repositorio es clave para el rendimiento, el locking y el mantenimiento, por lo que debe planificarse desde el principio.

Copias de seguridad automatizadas con BorgBackup: arquitectura y reglas operativas

Para un funcionamiento productivo son obligatorios varios aspectos:

• Separación por cliente o servicio: Cree un repositorio independiente por cliente o por servicio crítico cuando las políticas de retención o el control de acceso sean distintos.
• Compatibilidad de versiones: Mantenga sincronizadas las versiones de Borg en cliente y servidor; pruebe los cambios de versión en entornos de staging antes de desplegarlos en producción.
• Seguridad SSH: Use autenticación basada en claves, una cuenta de backup dedicada (p. ej. backup-user) y la RESTricción de comando de AuthorizedKeys para limitar el acceso SSH a borg serve.
• Planificación de recursos: Las copias iniciales son intensivas en CPU y E/S; contemple mayor demanda de RAM/CPU en los clientes y picos de carga en el host del repositorio.

Inicializar el repositorio, estrategias de cifrado y gestión de claves

Borg admite modos de cifrado como repokey (clave en el repositorio, protegida por passphrase) y keyfile (clave privada externa). Repokey es operativamente más sencillo, mientras que keyfile permite una gestión de claves más estricta, porque la clave privada se almacena por separado. La pérdida de claves en repositorios cifrados suele derivar en pérdida permanente de datos: por tanto, planifique procesos de rotación de claves, copia de seguridad y retención.

# Repository lokal initialisieren (repokey)
borg init --encryption=repokey /srv/backup/repo

# Remote-Repository-Init per SSH (auf Backup-Host)
ssh backup-admin@backup.example.com "borg init --encryption=repokey /srv/backup/repo"

Una entrada segura en AuthorizedKeys con RESTricciones evita el acceso a shell interactiva y permite únicamente las operaciones de Borg para el repositorio indicado:

command="/usr/bin/borg serve --RESTrict-to-path /srv/backup/repo",no-agent-forwarding,no-port-forwarding,no-pty ssh-rsa AAAA... backup-client@example

Gestione las claves SSH y las passphrases en un almacén de secretos dedicado (p. ej. HashiCorp Vault) y asegure las claves, según políticas definidas, en un lugar separado y disponible offline. La documentación y la rotación periódica de claves son determinantes para la operación.

Flujo de respaldo práctico y scripting robusto

Las copias de seguridad deben ejecutarse de forma idempotente, atómica y con un registro detallado. Utilice un script de envoltura con set -euo pipefail, bloqueo (p. ej. flock), salida estructurada para el análisis por herramientas de monitorización y manejo de códigos de salida.

#!/usr/bin/env bash
set -euo pipefail

LOCKFILE=/var/lock/borg-backup.lock
exec 9>&1

flock -n 9 || { echo "Backup läuft bereits"; exit 2; }

export BORG_REPO=ssh://backup-user@backup.example.com:22/srv/backup/repo
export BORG_PASSPHRASE_FILE=/etc/borg/passphrase
export BORG_RSH="ssh -i /etc/borg/backup_key -o StrictHostKeyChecking=yes"

LOGFILE=/var/log/borg-backup/$(date +%F).log
mkdir -p $(dirname "$LOGFILE")

/usr/bin/borg create -v --stats --compression zstd,6 
  $BORG_REPO::"$(hostname)-$(date +%Y-%m-%d_%H:%M:%S)" 
  /etc /var/www /srv/data 
  --exclude '/var/cache' --exclude '/proc' --exclude '/sys' 2>&1 | tee -a "$LOGFILE"

exit_code=${PIPESTATUS[0]}

if [ "$exit_code" -ne 0 ]; then
  echo "Borg create failed with exit $exit_code" | tee -a "$LOGFILE"
  exit $exit_code
fi

# Prune nur nach erfolgreichem Backup
/usr/bin/borg prune -v --list $BORG_REPO --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=1 2>&1 | tee -a "$LOGFILE"

Ejecute este script mediante systemd-timer, no mediante Cron, para obtener un comportamiento de arranque más fiable, políticas de reintento automáticas y conexión nativa de registro a journalctl.

Ejemplo: servicio y temporizador de systemd

# /etc/systemd/system/borg-backup.service
[Unit]
Description=Borg Backup Job
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/run-borg-backup.sh
Nice=10

# /etc/systemd/system/borg-backup.timer
[Unit]
Description=Daily Borg Backup Timer

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Ajuste Nice y la afinidad de CPU, si es necesario, para descargar las tareas de copia de seguridad frente a los servicios productivos.

Deduplicación: funcionamiento e implicaciones operativas

Borg utiliza segmentación definida por contenido (content-defined chunking): los datos se dividen en bloques variables identificados mediante hash criptográfico. La deduplicación ahorra espacio, pero tiene implicaciones:

• La deduplicación es a nivel de repositorio: el ahorro se produce únicamente dentro del mismo repositorio, no entre repositorios.
• El chunking genera carga de CPU y, en ocasiones, de RAM; los clientes con muchos archivos pequeños se benefician especialmente, pero la creación de chunks consume recursos.
• Al RESTaurar grandes volúmenes de datos se producen muchas lecturas pequeñas; planifique perfiles de E/S y pruebe las ventanas de recuperación.

Opciones de almacenamiento remoto: evaluación y recomendaciones

El repositorio SSH (borg serve) es la opción recomendada: rutas de código probadas, manejo correcto de locks y baja complejidad. Los backends alternativos conllevan riesgos:

• NFS/SMB: pueden provocar problemas de bloqueo y de consistencia y favorecer la corrupción del repositorio; por ello no se recomiendan sistemas de archivos de red montados.
• Almacenamiento de objetos (p. ej. S3): Borg no soporta S3 de forma nativa; son posibles gateways (puentes SFTP o de sistema de archivos), pero aumentan la complejidad y deben evaluarse en cuanto a integridad, latencia y rendimiento.

Recomendaciones de hardware para el repositorio

Para repositorios con alta carga de RESTauración o escritura, los backends basados en SSD son ventajosos, ya que manejan de forma más eficiente muchos I/O pequeños. Para archivado a largo plazo se pueden utilizar matrices HDD de bajo coste con RAID o erasure coding adecuados, siempre que realice pruebas de RESTauración y contemple el ancho de banda disponible.

Estrategias de retención, planificación de prune y efectos

La retención debe equilibrar los puntos de recuperación (RPO) con los costes de almacenamiento. Prácticamente comprobado:

• Retención a corto plazo: snapshots diarios (p. ej., 7 días)
• A medio plazo: snapshots semanales y mensuales
• A largo plazo: archivos anuales para cumplimiento

# Prune dry-run zur Überprüfung
borg prune -v --list $BORG_REPO --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=1 --dry-run

Prune solo elimina archivos; debido a la deduplicación, los Chunks se borran físicamente cuando ningún archivo RESTante los referencia. Realice dry-runs periódicos y documente qué puntos de RESTauración se perdieron para asegurar la conformidad con el SLA.

Comprobaciones automatizadas de RESTauración y flujos de validación

Un backup solo es tan bueno como su RESTauración. Dos niveles de comprobación son prácticos:

1. Integridad del repositorio: borg check --repository-only periódicamente; de forma periódica borg check --verify-data en ventanas de mantenimiento, ya que esto último es intensivo en E/S.
2. Prueba de RESTauración funcional: extraer artefactos críticos (p. ej., configuraciones, DB-Dumps) a un entorno de prueba y validar con sumas de verificación, pruebas de importación de bases de datos o arranque de servicios en un entorno aislado.

# RESTore-Validierung: Beispiel für nginx-Konfiguration
set -euo pipefail
TMPDIR=$(mktemp -d /tmp/borg-RESTore-test-XXXX)
trap 'rm -rf "$TMPDIR"' EXIT

ARCHIVE=$(borg list --short $BORG_REPO | tail -n1)

borg extract $BORG_REPO::"$ARCHIVE" etc/nginx/nginx.conf --target "$TMPDIR"
sha256sum "$TMPDIR/etc/nginx/nginx.conf" | awk '{print $1}' > /tmp/RESTore-check-actual
# Vergleichen Sie die resultierende Prüfsumme mit einer erwarteten Prüfsumme

Las comprobaciones automatizadas de RESTauración deben generar alertas orientadas al resultado (Mail/ChatOps/Monitoring-Event) y ejecutarse al menos semanalmente para artefactos críticos. Utilice hosts de prueba o contenedores para el aislamiento, de modo que la validación no modifique datos de producción.

Supervisión, análisis de salidas y alertas

Recoja estas métricas para observabilidad: última ejecución exitosa, duración, tamaño de los datos transferidos, número de bytes deduplicados, resultados de prune y códigos de salida de borg. Desarrolle un parser robusto que tenga en cuenta las diferencias de texto dependientes de la locale.

# Beispiel: sehr simples Parsing (nur Ausgangspunkt)
transferred_bytes=$(grep "Transferred" $LOGFILE | awk '{print $2}')
processed_files=$(grep "Number of files" $LOGFILE | awk -F: '{print $2}' | tr -d ' ')

# Senden an Monitoring (pseudo)
# curl -X POST http://monitoring.example.local/metrics -d "borg_transferred_bytes=$transferred_bytes"

Para entornos de producción se recomienda un exporter o conector dedicado que genere logs estructurados (JSON) o envíe métricas directamente a Prometheus/Grafana. Pruebe el parser con distintas versiones de borg.

Casos de error típicos y una secuencia de comprobación rápida

Ante fallos de backup, aplique una secuencia de comprobación estandarizada que debe documentarse en el runbook de incidentes:

1. Comprobar la conexión SSH:
   ShellCode kopieren

   ssh -vvv backup-user@backup.example.com

   — muestra errores de clave y autenticación.

2. Comprobar espacio en el host del repo:
   ShellCode kopieren

   ssh backup@backup.example.com df -h /srv/backup

3. Comprobar el estado del repo:
   ShellCode kopieren

   borg list $BORG_REPO
   borg info $BORG_REPO::ARCHIVNAME

4. Problemas de bloqueo:
ShellCode kopieren

borg break-lock $BORG_REPO

— solo tras análisis y si no hay ningún proceso de Borg activo.

5. Integridad:
   ShellCode kopieren

   borg check --repository-only $BORG_REPO

Evite intentos de reparación precipitados como borg check --repair sin antes realizar una copia de seguridad de los metadatos del repositorio; documente cada paso.

Estrategia de migración y emergencia

Para migraciones o emergencias se recomiendan medidas claras:

1. Haga una copia de seguridad de los metadatos del repositorio y cree un snapshot del sistema de archivos del host de backup (por ejemplo, snapshot LVM o ZFS).
2. Realice una RESTauración de prueba en un host separado y valide las cargas de trabajo críticas.
3. En caso de corrupción del repositorio: primero borg check --repository-only, documente, contacte a la comunidad o al soporte, y luego planifique acciones de reparación específicas.

Tenga preparada una estrategia de retroceso: si un cambio de versión planificado de Borg falla, debe poder revertir a la versión anterior de Borg y continuar trabajando con un snapshot del sistema de archivos del repositorio.

Optimización de rendimiento e integración con el sistema de archivos

Optimizaciones probadas en la práctica:

• Nivel de compresión: --compression zstd,6 es un buen compromiso entre carga de CPU y tamaño; niveles más altos ahorran más espacio, pero aumentan el consumo de CPU.
• Caché de archivos: Borg puede usar caches de listas de archivos; pruebe BORG_FILES_CACHE para sistemas de archivos muy grandes.
• Instantáneas para consistencia: para bases de datos utilice snapshots de almacenamiento (LVM, ZFS) o volcados consistentes (por ejemplo pg_dump) antes de ejecutar Borg, ya que Borg es una herramienta a nivel de archivos.

Mantenimiento del repositorio: compact, upgrade y cambio de versión

El mantenimiento regular ayuda a limitar el número de archivos de segmento y a mantener el rendimiento. Use:

# Repository komprimieren/neu packen
borg compact $BORG_REPO

# Vor einem Versionswechsel: Backup aller Repository-Metadaten und Tests in Staging
borg upgrade --help  # prüfen, wenn Versionswechsel nötig ist

Realice el mantenimiento del repositorio en ventanas de mantenimiento y pruebe el efecto sobre el tiempo de RESTauración y la carga de E/S.

Lista de comprobación de buenas prácticas para el funcionamiento

• Comprobaciones de RESTauración automatizadas y periódicas (por ejemplo, semanales para archivos críticos)
• Separación de hosts de backup y de producción; endurecimiento SSH para el usuario de backup
• Documentar la política de prune; realizar ejecuciones de prueba (dry-runs) de prune periódicamente
• Monitorización basada en códigos de salida y registro estructurado
• Gestión segura de claves: copia de seguridad y rotación de frases de contraseña/archivos de clave
• Pruebas en staging para actualizaciones de versión de Borg y mantenimiento del repositorio
• Runbooks de incidentes documentados con secuencias de verificación claras

Conclusión

BorgBackup es una solución consolidada para backups automatizados con deduplicación, siempre que la topología del repositorio, la seguridad SSH, el cifrado y la validación de RESTauraciones estén planificados con rigor. Son decisivos las comprobaciones de RESTauración automatizadas, un proceso de prune comprobable y la monitorización de los resultados de las tareas. La deduplicación reduce considerablemente las necesidades de almacenamiento y ancho de banda, pero exige cuidado en la planificación de recursos y la gestión de claves. Con runbooks claros, pruebas periódicas y un flujo de trabajo de monitorización estricto, se consigue una estrategia de backup resistente que soporta de forma fiable la operación y la recuperación.

Si necesita un plan de implementación concreto o una auditoría de su topología de backups, de ello puede derivarse un runbook operativo seguro que cubra tanto los requisitos de almacenamiento como de RESTauración.

COPIAS DE SEGURIDAD automatizadas con BorgBackup: georedundancia, auditoría y atributos de archivo

Además de la planificación rutinaria, debe considerar expresamente tres áreas relevantes en la práctica: almacenamiento georedundante, trazabilidad de accesos y el tratamiento de atributos de archivo/ACLs. Estos puntos afectan directamente la recuperabilidad, el cumplimiento y la respuesta ante incidentes.

Georedundancia y patrones de replicación

Borg no proporciona replicación Multi‑Site integrada. Patrones probados son:

• Push secuencial: escribir la copia de seguridad de forma sucesiva en dos repositorios (local → Remoto A → Remoto B). Ventaja: lógica sencilla; desventaja: mayor duración total.
• Replicación a nivel de almacenamiento: usar ZFS‑Send/Receive, replicación de bloques u object‑store‑replication por debajo del sistema de archivos para generar réplicas atómicas. Ventaja: copias consistentes; desventaja: mayor complejidad de infraestructura.
• Snapshots como punto de transferencia: generar un snapshot consistente del almacenamiento (LVM/ZFS) y replicar este en la sede secundaria en lugar de copiar archivos individuales del repositorio.

Asegúrese de incorporar bloqueos, comprobaciones de consistencia y planificación de ancho de banda. La replicación sin verificación de integridad puede multiplicar la corrupción.

Auditoría, control de accesos y trazabilidad

RESTrinja el acceso SSH mediante AuthorizedKeys-Command, registre todas las operaciones de Borg de forma centralizada (journal/syslog → SIEM) e instrumente la cuenta de backup con reglas de auditoría (auditd) para eventos de archivos y procesos. Así detectará exportaciones o RESTauraciones no autorizadas y podrá reconstruir horarios de acceso y responsables.

Atributos de archivo, ACLs y SELinux‑Kontexte

Compruebe si sus copias de seguridad necesitan Extended Attributes, POSIX‑ACLs y SELinux‑Kontexte (archivos de configuración, directorios Home). Active las opciones de archivado correspondientes y valide, al RESTaurar, que permisos y contextos se conservan; esto es decisivo para reinicios productivos.

Runbook rápido de emergencia (resumen)

1. Asegurar disponibilidad: redirigir DNS/LoadBalancer al host de RESTauración.
2. Chequeo rápido: ejecutar borg list / borg info sobre el repositorio secundario.
3. Comprobación de integridad: borg check –repository-only.
4. RESTore de failover: extraer y validar primero las configuraciones críticas.
5. Auditoría y documentación: registrar todos los pasos; rotar claves si están comprometidas.

Estas medidas cierran la brecha entre “la copia de seguridad está funcionando” y “podemos volver a operar productivamente tras un desastre” y deberían formar parte de su runbook operativo.

Para este tema también son importantes las operaciones de prune de backups. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que centrarse en el día a día.