BorgShield: Sistema de Backup Linux Eficiente, Fiable y Verificable

Un análisis técnico basado en BorgBackup para entornos Debian/Ubuntu

Autor: Arcadio Ortega Reinoso
Versión del sistema: 2.1.0
Fecha: Julio 2026
Plataforma objetivo: Debian 11+ / Ubuntu 22.04+ (x86_64)

Puedes encontrarlo en: BorgShield

Fortalezas Diferenciales

Valor Diferencial Claro: La inclusión de 23 tipos de metadatos
(repositorios git, dconf, claves GPG, snaps, flatpaks, etc.) resuelve el
problema de tener los archivos pero no saber cómo reconstruir el entorno.
No es solo "tus datos están a salvo", es "sabemos exactamente qué tenías
y cómo volver a dejarlo igual".

Restauración Semántica: test-restore va más allá de borg check.
Mientras que otras herramientas solo verifican checksums (integridad
técnica), nosotros verificamos si los datos son realmente legibles y útiles
(integridad semántica): ¿el SQL de las BBDD se puede leer? ¿los paquetes
están en formato válido? ¿las rutas esenciales existen? ¿los gzips no
están corruptos?

Asistente Guiado: restore-full y restore-dry-run forman un sistema
de dos velocidades: simular antes de ejecutar, y guiar paso a paso durante
la ejecución real. Esto reduce significativamente el "pánico" durante un
desastre real, guiando incluso en la reinstalación de paquetes y fuentes APT.

Resumen

Este documento presenta el diseño, la implementación y la evaluación de
backup.sh, un sistema de backup para Linux orientado a disco externo
local. El sistema se basa en BorgBackup como motor de almacenamiento
deduplicado, cifrado y comprimido. Se analizan las alternativas existentes
(rsync, rsnapshot, restic), se justifican las decisiones de diseño y se
presentan proyecciones de rendimiento basadas en métricas obtenidas de un
sistema real con ~360 GB de datos, ~3200 paquetes instalados y ~460 paquetes
instalados manualmente.

Los resultados muestran que BorgBackup reduce el espacio de almacenamiento
del backup completo a ~160 GB (55% de compresión con deduplicación), los
backups incrementales se completan en 3-8 minutos, y el sistema permite
restauración granular por archivo, por directorio o completa del sistema
operativo con una guía interactiva paso a paso.

1. Ventaja Diferencial

1.1 Matriz de diferenciación

Ninguna herramienta existente cubre más de 2 de estas 13 capacidades.

1.2 Lo que otros tienen y backup.sh no

Conclusión: backup.sh sacrifica portabilidad cloud e interoperabilidad
a cambio de profundidad en metadatos, automatización de BBDD y restauración
guiada. Es la herramienta correcta para backup local a disco externo donde
se necesita recuperación completa del sistema, no para backup cloud.

2. Introducción y Planteamiento del Problema

2.1 El problema del backup en Linux

A día de hoy, hacer backups efectivos en Linux sigue siendo un desafío
técnico. Aunque existen numerosas herramientas, la mayoría adolece de al
menos uno de estos problemas:

1. Ausencia de deduplicación: los backups completos duplican datos que no han cambiado, consumiendo espacio innecesario.
2. Falta de verificación: sin checksums, no hay garantía de que los datos almacenados sean recuperables.
3. Dependencia del sistema de archivos: los sistemas basados en hardlinks (rsnapshot, rsync + --link-dest) requieren soporte del FS subyacente, problemático en NTFS u otros formatos comunes en discos externos.
4. Restauración compleja: recuperar un sistema completo desde cero requiere múltiples herramientas y conocimientos.
5. Carencia de cifrado: los datos en disco externo viajan sin protección.

2.2 Requisitos del sistema

El sistema que nos ocupa presenta las siguientes características:

El objetivo es diseñar un sistema de backup que cumpla:

• Eficiencia: backups rápidos que minimicen el espacio en disco.
• Fiabilidad: verificación criptográfica de integridad.
• Restaurabilidad: recuperación granular (archivo individual) y total (sistema completo desde una instalación limpia).
• Operación autónoma: ejecución desatendida via cron, con notificación de errores.
• Seguridad: cifrado de los datos en reposo.

3. Soluciones Existentes y sus Limitaciones

3.1 rsync con hardlinks (rsnapshot)

Mecanismo: rsync -aAX --link-dest=<anterior> + cp -al para crear
snapshots con hardlinks a archivos sin cambios.

Ventajas:

• Los archivos son directamente accesibles (cada snapshot es un directorio).
• Sin dependencias adicionales más allá de rsync.

Limitaciones:

• Dependencia del FS: NTFS-3G soporta hardlinks, pero con significativa degradación de rendimiento. La creación de hardlinks en NTFS requiere operaciones de metadatos lentas.
• Sin compresión: los archivos se almacenan tal cual, ocupando el 100% del espacio original.
• Sin cifrado nativo: requiere capa adicional (gpg, encfs).
• Sin verificación: no hay checksums de los datos almacenados.
• Growth lineal: cada nuevo "full" copia todo aunque no haya cambios.

Proyección para nuestro sistema: Con ~360 GB de origen y rotación de 3
fulls, ocuparíamos ~1.1 TB en 12 meses. En un disco de 1.9 TB con 418 GB
libres, esto es inviable a largo plazo.

3.2 Restic

Mecanismo: repositorio chunk-based con deduplicación y cifrado,
similar a Borg pero con énfasis en almacenamiento en la nube.

Ventajas:

• Excelente para backups remotos (S3, Backblaze, Azure).
• Deduplicación y cifrado.
• FUSE mount.

Limitaciones:

• Compresión menos eficiente que Borg en escenarios locales (no usa zstd).
• Menor madurez en el ecosistema (Borg tiene 15+ años).
• Montaje FUSE menos estable.

3.3 Timeshift (modo rsync)

Mecanismo: rsync con hardlinks + interfaz gráfica.

Ventajas:

• Interfaz amigable.
• Bueno para snapshots del sistema.

Limitaciones:

• No cifra.
• No comprime.
• No tiene verificación.
• Depende de hardlinks.
• Orientado a restauración del sistema, no de archivos de usuario.

3.4 BorgBackup

Mecanismo: repositorio chunk-based con deduplicación global (no por
archivo, por bloque de 64 KiB-1 MiB), compresión y cifrado.

Ventajas:

• Deduplicación independiente del sistema de archivos subyacente. Funciona sobre NTFS, FAT, exFAT, etc. sin depender de hardlinks.
• Compresión Zstandard configurable (niveles 1-22).
• Cifrado autenticado AES-256 con HMAC-SHA256.
• Verificación de integridad mediante checksums SHA-256 en cada chunk.
• Montaje FUSE nativo.
• Madurez: 15+ años de desarrollo continuo.

Limitación principal: no está diseñado para backup directo a la nube
(aunque se puede usar rclone como capa de transporte).

Conclusión: BorgBackup es la opción superior para backup a disco
externo local.

4. Arquitectura Propuesta

4.1 Visión general del sistema

┌─────────────────────────────────────────────────────────┐
│                   SISTEMA (/)                           │
│  /home  /etc  /root  /var/www  /opt  /usr/local        │
└──────────────┬──────────────────────────────────────────┘
               │
               │ rsync / borg mount
               ▼
┌─────────────────────────────────────────────────────────┐
│               backup.sh (orquestador)                   │
│                                                         │
│  1. Collect metadata (packages, sources, snaps, ...)    │
│  2. borg create --compression zstd,3                    │
│  3. borg prune (retención automática)                   │
│  4. Logging + notificación                              │
└──────────────┬──────────────────────────────────────────┘
               │
               │ borg create / extract / mount
               ▼
┌─────────────────────────────────────────────────────────┐
│          DISCO EXTERNO (NTFS 1.9 TB)                    │
│                                                         │
│  Backups_linux/                                         │
│  ├── borg/aorsrv/   ← Repositorio Borg (cifrado)        │
│  ├── meta/aorsrv/   ← Metadatos en texto plano          │
│  ├── logs/aorsrv/   ← Historial de ejecución            │
│  └── backup.sh      ← El script mismo                   │
└─────────────────────────────────────────────────────────┘

4.2 Flujo de ejecución de backup.sh now

[Inicio]
  │
  ├─ check: borg instalado?
  ├─ check: disco montado?
  ├─ check: repositorio existe? (init si no)
  ├─ acquire: flock() (evitar concurrencia)
  │
  ├─ collect_metadata():
  │   ├─ dpkg --get-selections > packages.list
  │   ├─ apt-mark showmanual > packages_manual.list
  │   ├─ cp /etc/apt/sources* meta/sources/
  │   ├─ snap list > snaps.list
  │   ├─ flatpak list > flatpak.list
  │   ├─ systemctl list-unit-files > services.list
  │   ├─ getent passwd > users.list
  │   └─ lsblk > disk_layout.txt
  │
  ├─ borg create:
  │   ├─ compression: zstd,3
  │   ├─ one-file-system: sí
  │   ├─ exclude-caches: sí
  │   ├─ includes: /home /etc /root /var/www /opt /usr/local ...
  │   ├─ excludes: /proc /sys /dev /run /tmp /mnt /media *.iso *.vdi ...
  │   └─ output: borg_repo::hostname-YYYYMMDD_HHMMSS
  │
  ├─ if success:
  │   ├─ borg prune (keep-daily=7, keep-weekly=4, keep-monthly=6)
  │   ├─ copy metadata to meta/ dir
  │   └─ log success
  │
  └─ if failure:
      └─ log error + notify if configured

[Fin]

4.3 Estructura de un snapshot Borg

Cada snapshot contiene rutas relativas a / para permitir extracción
directa en el lugar correcto. Los metadatos se almacenan en una ruta
predecible backup-meta-{timestamp}/meta/:

hostname-20260722_142530/
├── home/aor/...
├── etc/ssh/sshd_config
├── etc/hostname
├── root/.bashrc
├── var/www/html/index.html
├── opt/myapp/config.yml
├── usr/local/bin/myscript
├── var/spool/cron/crontabs/aor
└── backup-meta-20260722_142530/
    └── meta/
        ├── system_info.txt
        ├── packages.list
        ├── packages_manual.list
        ├── sources/sources.list
        ├── sources/sources.list.d/
        ├── sources/trusted.gpg
        ├── snaps.list
        ├── flatpak.list
        ├── services_enabled.list
        ├── users.list
        ├── disk_layout.txt
        ├── network.txt
        ├── git_repos.txt
        ├── dev_environments.txt
        ├── excluded_report.txt
        └── vm_images.txt

Nota: La ruta de metadatos es siempre backup-meta-{YYYYMMDD_HHMMSS}/meta/. El
timestamp se extrae del nombre del snapshot (hostname-{timestamp}),
permitiendo a los comandos test-restore, restore-dry-run y restore-full localizar los
metadatos automáticamente sin configuración adicional. vm_images.txt contiene
solo inventario — las imágenes de VM se excluyen del backup por su gran tamaño.

La ruta de metadatos es siempre backup-meta-{YYYYMMDD_HHMMSS}/meta/. El
timestamp se extrae del nombre del snapshot (hostname-{timestamp}),
permitiendo a los comandos test-restore y restore-full localizar los
metadatos automáticamente sin configuración adicional.

4.4 Gestión de metadatos fuera del repositorio

Además de almacenar los metadatos dentro de cada snapshot, el script copia
los metadatos comprimidos a meta/hostname/ en el disco de backup. Esto
permite:

• Consultar la lista de paquetes sin montar el repositorio Borg.
• Verificar rápidamente el contenido de un backup sin extraer nada.
• Acceder a los metadatos incluso si el repositorio Borg se corrompe.

5. Evaluación Comparativa

5.1 Métricas del sistema real

Las métricas que siguen se obtuvieron del primer backup completo del
sistema de referencia (Ubuntu 22.04, ~360 GB en /):

5.2 Proyección de espacio en disco

Con la política de retención actual (7 diarios + 4 semanales + 6
mensuales) y un crecimiento estimado de 2-3 GB/mes en datos nuevos:

El disco de 1,9 TB con 418 GB libres tiene capacidad para más de 3 años
de backups sin necesidad de ampliar.

5.3 Proyección de tiempo de ejecución

El tiempo depende del tipo de backup y del medio de almacenamiento:

Los incrementales son rápidos porque Borg solo procesa los chunks que
cambiaron. En un uso normal de escritorio (documentos, navegación, correo),
el cambio diario es de 100-500 MB. Solo si se instalan paquetes grandes o
se descargan archivos pesados el incremental se alarga.

5.4 Matriz de características

6. Garantías de Restauración

6.1 Nivel 1: Restauración por archivo

Para recuperar un archivo o directorio concreto sin necesidad de montar
el snapshot completo:

backup.sh restore aorsrv-20260722_142530 etc/hostname ./
backup.sh restore aorsrv-20260722_142530 home/aor/documentos/importante.pdf /tmp/

Borg extrae la ruta exacta del archive y la deposita en el destino
indicado. No requiere montaje FUSE ni permisos de root (a menos que el
destino los requiera). El comando restore también permite restaurar
archivos del snapshot sin tener que navegar manualmente.

6.2 Nivel 2: Restauración por directorio (montaje FUSE)

Para explorar y copiar múltiples archivos sin extraer todo el snapshot:

backup.sh mount aorsrv-20260722_142530
ls /mnt/backup_drive/Backups_linux/mnt/aorsrv-20260722_142530/
cp -r /mnt/backup_drive/Backups_linux/mnt/aorsrv-20260722_142530/home/aor/ ./recuperado/
backup.sh umount

El montaje FUSE es de solo lectura. Se pueden usar herramientas
estándar (cp, rsync, find, grep) sobre los archivos montados.
Ideal para restaurar directorios enteros sin extraer el snapshot completo
al sistema de archivos.

6.3 Nivel 3: Restauración completa del sistema (desastre)

Para recuperar un sistema desde cero tras un fallo catastrófico:

# En una instalación limpia de Ubuntu:
sudo apt install borgbackup
# Montar disco externo con el backup
backup.sh restore-full aorsrv-20260722_142530

restore-full es un asistente interactivo que guía al usuario por:
instalación de Borg, restauración de fuentes APT, reinstalación de
paquetes, extracción de archivos y tareas post-restauración. Está
diseñado para que un usuario con conocimientos básicos de Linux pueda
recuperar el sistema siguiendo las instrucciones en pantalla.

6.4 Verificación de restaurabilidad

backup.sh incluye verificación de integridad a tres niveles:

1. Por comando: borg check verifica que todos los chunks son legibles y que sus checksums coinciden.
2. Por snapshot: backup.sh mount <snap> y navegación manual comprueba que los archivos están accesibles.
3. Por repositorio: borg info muestra el ratio de deduplicación, que sirve como indicador de salud (un ratio anómalo puede indicar corrupción).

7. Decisiones de Diseño

7.1 ¿Por qué un script y no una herramienta con interfaz?

Un script bash no requiere ni interfaz gráfica, ni servidor, ni base de
datos. Funciona en cualquier terminal, incluso sobre SSH, en una sesión
de recovery, o desde un live USB. Es editable con cualquier editor de
texto, se puede auditar línea por línea, y no introduce dependencias
adicionales más allá de las que ya necesita Borg. No hay riesgo de que
una actualización de la GUI rompa el backup: si bash funciona, el script
funciona.

7.2 ¿Por qué la configuración en variables del script?

Un solo archivo autocontenido. No hay archivos de configuración externos
que puedan perderse, olvidarse al copiar el script a otro equipo, o
desincronizarse. Se editan 3 variables (BACKUP_BASE, HOSTNAME,
PASSPHRASE_FILE) y el sistema está operativo. La configuración se
exporta con backup.sh export-config para uso en otros equipos.

7.3 ¿Por qué metadatos fuera del repositorio?

Para poder consultar la lista de paquetes, fuentes APT o servicios del
sistema sin tener que montar el repositorio Borg. Si el disco externo
está conectado pero no se quiere (o no se puede) ejecutar Borg, los
metadatos en texto plano son accesibles con cat, grep o less.
Además, proporciona una capa de redundancia: si el repositorio Borg se
corrompe, los metadatos del sistema sobreviven en texto plano.

7.4 ¿Por qué repokey y no keyfile?

En el modo repokey, la clave de cifrado viaja dentro del propio
repositorio. No se necesita gestionar un archivo de clave aparte. La
clave está protegida por la frase de paso (PBKDF2), por lo que tener el
repo no basta para descifrarlo. En modo keyfile, si se pierde el
archivo de clave, el repositorio es irrecuperable aunque se tenga la
frase de paso. repokey reduce el riesgo de pérdida de clave a cambio
de una protección ligeramente menor (la clave está en el repo, no en un
archivo separado).

7.5 ¿Por qué compresión zstd,3?

Zstandard en nivel 3 ofrece la mejor relación compresión/velocidad en
hardware moderno (CPU de los últimos 10 años). Comprime aproximadamente
igual que gzip -6 pero 2-3 veces más rápido. Niveles superiores (10-19)
apenas mejoran la compresión para datos mixtos (binarios + texto) y
ralentizan significativamente el backup. Nivel 3 es el recomendado por
los propios desarrolladores de Borg para uso general.

7.6 ¿Por qué capturar colas de logs y no los logs completos?

/var/log/ puede ocupar fácilmente 500 MB o más, y la mayoría del
contenido son líneas antiguas sin valor para una restauración. Capturar
las últimas 200 líneas de los logs del sistema proporciona el contexto
necesario para diagnosticar el estado del sistema en el momento del
backup (errores recientes, arranques, apagados, problemas de red) sin
el peso de almacenar cientos de megabytes de registros históricos que
ya están en el sistema original.

7.7 ¿Por qué pre-backup hooks para bases de datos?

Uno de los errores más comunes en backups de Linux es copiar los archivos
raw de bases de datos (/var/lib/mysql/, /var/lib/postgresql/) mientras
el motor está en ejecución. Esto produce copias inconsistentes que pueden
no ser restaurables.

La alternativa correcta —y la implementada en backup.sh— es realizar
volcados lógicos (dumps) antes de cada backup:

Ventajas de los dumps frente a copia raw:

1. Portabilidad: un dump de MySQL 5.7 se restaura en MySQL 8.0, MariaDB 10.x, Percona Server, etc. La copia raw solo funciona con la versión exacta.
2. Consistencia transaccional: mysqldump --single-transaction garantiza una instantánea consistente del momento en que comenzó el dump.
3. Espacio: los dumps omiten índices, logs binarios, tablas temporales y páginas no utilizadas. Un dump es típicamente un 30-50% más pequeño que los datos raw.
4. Restauración selectiva: un dump SQL se puede editar con un editor de texto para restaurar solo una tabla o una fila.
5. Integridad referencial: los dumps preservan claves foráneas, disparadores, procedimientos almacenados, funciones y vistas en el orden correcto de creación.

Detección automática: el script no asume nada. Detecta qué motores
están en ejecución (pgrep) y si las herramientas de dump están
instaladas (command -v). Solo entonces ejecuta el volcado, sin
intervención del usuario.

Almacenamiento: los dumps se escriben en
/var/backups/pre-backup-hooks/, directorio que está incluido en el
backup (/var/backups está en INCLUDE). Borg los deduplica
automáticamente entre snapshots: solo las páginas de datos que cambian de
un día para otro ocupan espacio nuevo.

8. Casos de Uso y Escenarios

8.1 Uso diario (cron)

El caso más común: el script se ejecuta automáticamente cada día a las 3 AM
via crontab. Como los backups son incrementales, la ventana de ejecución es
corta (10-20 minutos para ~2.5M archivos), y Borg solo almacena los bloques
nuevos desde el último snapshot.

0 3 * * * /home/aor/bin/backup.sh cron

El modo cron desactiva colores, barras de progreso y prompts. Escribe al
log y devuelve código de retorno para que cron envíe alertas por correo si
algo falla:

./backup.sh doctor         # Verificar que el sistema está sano
tail -f "$BACKUP_BASE/logs/$(hostname -s)/backup.log"  # Monitorizar resultado

8.2 Backup antes de una actualización del sistema

Antes de una operación de riesgo (apt upgrade, do-release-upgrade,
cambio de kernel, etc.):

./backup.sh now            # Backup completo justo antes del cambio
sudo apt upgrade           # Aplicar la actualización

Si la actualización introduce regresiones:

./backup.sh diff <snap-pre> <snap-post>   # Ver qué archivos cambiaron
./backup.sh restore <snap-pre> etc/hostname /tmp/  # Recuperar config anterior
./backup.sh mount <snap-pre>              # Inspeccionar el sistema antes del cambio

El snapshot pre-actualización es un punto de restauración completo. No es
necesario hacer backup del sistema completo antes de cada apt install,
pero para operaciones que modifican /etc, kernels o servicios críticos,
el coste de un snapshot incremental extra (~10 minutos, ~270 MB) es mínimo
comparado con el tiempo de depuración si algo sale mal.

8.3 Cambio de disco duro

Escenario: el disco principal falla o se sustituye por uno de mayor
capacidad. El proceso completo con BorgShield:

1. Conectar disco externo con el backup al nuevo equipo.
2. Instalar Ubuntu (o Debian) desde USB. No configurar nada aún.
3. Montar disco externo y verificar accesibilidad:

sudo mount /dev/sdb1 /mnt/backup_drive
mount | grep backup_drive

1. Copiar backup.sh y ejecutar restore-full:

cp /mnt/backup_drive/Backups_linux/backup.sh ~/
./backup.sh restore-full <ultimo-snapshot>

1. El asistente guía paso a paso:
   • Instala Borg si no está presente.
   • Pregunta si restaurar fuentes APT (sources.list, GPG keys).
   • Ofrece 3 métodos de restauración de paquetes: manual, dpkg-set-selections, apt-clone.
   • Pide doble confirmación antes de extraer archivos.
   • Muestra tareas post-restauración: hostname, fstab, SSH keys, GRUB.

No es necesario reinstalar el SO desde cero configurándolo primero: los
archivos de configuración del sistema original (resolv.conf, interfaces de
red, fstab, fuentes APT, crontabs, claves SSH) se restauran desde el
backup. Solo el kernel y el cargador de arranque requieren configuración
manual post-restauración (detallada en las tareas post-restauración).

8.4 Múltiples equipos en el mismo disco

Cada equipo se identifica por su $(hostname -s). Con solo copiar backup.sh
y ajustar BACKUP_BASE al mismo disco externo, cada equipo gestiona sus
propios snapshots, metadatos y logs de forma aislada:

/mnt/backup_drive/Backups_linux/
├── borg/portatil/
├── borg/servidor/
├── meta/portatil/
├── meta/servidor/
├── logs/portatil/
└── logs/servidor/

Solo es necesario copiar backup.sh a cada equipo y ajustar
BACKUP_BASE si es necesario.

9. Limitaciones y Trabajo Futuro

9.1 Limitaciones conocidas

1. Dependencia de BorgBackup: el sistema requiere instalar borgbackup. En sistemas sin acceso a internet, esto puede ser un obstáculo.
2. Backup remoto no nativo: a diferencia de Restic, Borg no tiene soporte nativo para S3 o Backblaze. Se requiere rclone como capa adicional.
3. Rendimiento en NTFS: aunque Borg funciona sobre NTFS, el rendimiento puede ser inferior al de ext4 debido a la capa FUSE (ntfs-3g).
4. Consumo de RAM: Borg utiliza algo de RAM para los índices de chunks (~1 GB por cada TB de datos únicos). En sistemas con poca RAM, puede ser un factor.
5. Docker experimental: la detección de BBDD dentro de contenedores Docker está desactivada por defecto (DOCKER_BACKUP=false) y requiere que el contenedor tenga las herramientas de dump instaladas.

9.2 Posibles mejoras

1. Soporte para backup remoto: añadir modo rclone que sincronice el repositorio Borg a la nube.
2. Notificaciones push: integración con Telegram, Pushover o Gotify.
3. Interfaz TUI: menú interactivo para usuarios menos técnicos.
4. Pre/Post hooks: scripts personalizados que se ejecuten antes y después del backup (ej. dump de base de datos).
5. Reporte HTML: generar un reporte visual del estado del backup.
6. Soporte LXD/LXC/KVM: detección y backup de contenedores y máquinas virtuales.
7. borg export-tar: comando para exportar un snapshot como tar (para enviar a otro sistema sin Borg).

10. Conclusiones

backup.sh resuelve los cuatro problemas fundamentales del backup en
Linux para el escenario de disco externo local:

1. Eficiencia: la deduplicación y compresión de BorgBackup reducen el espacio necesario a aproximadamente la mitad del tamaño original, y el crecimiento con el tiempo es mínimo (~2-3 GB/mes).
2. Fiabilidad: los checksums SHA-256 verifican cada byte almacenado. El comando check --full garantiza que todos los datos son recuperables.
3. Restaurabilidad: tres niveles de restauración (archivo, directorio, sistema completo) cubren desde la pérdida accidental de un documento hasta un desastre total. El modo restore-full guía al usuario paso a paso.
4. Seguridad: cifrado AES-256 con frase de paso, archivo de clave con permisos 600, y disco externo desconectable (protección contra ransomware).

Frente a las alternativas (rsync, rsnapshot, restic), BorgBackup ofrece la
mejor combinación de características para backup local: madurez,
deduplicación real, compresión eficiente, cifrado sólido y verificación
criptográfica.

11. Diferenciadores Clave Respecto a Otras Soluciones

Más allá de las comparativas cuantitativas (espacio, tiempo, compresión),
backup.sh introduce cinco capacidades que no existen juntas en ninguna
otra solución del ecosistema Linux:

11.1 Restauración virtual (test-restore)

Ninguna herramienta de backup ofrece un comando que verifique la
restaurabilidad semántica de un snapshot sin extraer datos al sistema
de archivos real:

• borg check verifica integridad técnica (checksums, índices).
• backup.sh test-restore verifica restaurabilidad semántica: formato de paquetes dpkg, integridad de dumps de BBDD (gunzip -t, tar -tzf, cabeceras mágicas), presencia de rutas esenciales, legibilidad de metadatos del sistema.

Es el equivalente funcional de tar -tvf aplicado a todo el ecosistema
de backup: bases de datos, configuración del sistema, logs, paquetes y
archivos.

11.2 Dumping automático de BBDD sin configuración

Mientras que rsync, rsnapshot, timeshift y Borg puro copian archivos raw
de bases de datos (inconsistentes si el motor está en ejecución),
backup.sh detecta y ejecuta el volcado correcto para cada motor:

No requiere configurar credenciales, hooks ni scripts externos. Detecta
el motor por pgrep + command -v.

11.3 Metadatos completos del sistema en cada snapshot

Cada snapshot contiene 14 categorías de metadatos que van mucho más allá
de lo que cualquier herramienta de backup captura:

• Lista de paquetes (completa + manuales).
• Repositorios APT con GPG keys (restaurables).
• Snaps, flatpaks, servicios systemd, usuarios, discos, red.
• Colas de logs (200 últimas líneas: contexto sin peso).

Esto significa que, con un solo snapshot, se puede reconstruir el perfil
completo de software del sistema original sin necesidad de tener el
sistema funcionando.

11.4 Restauración guiada interactiva

Mientras que Borg, restic y rsync ofrecen extract/restore como
comandos planos, restore-full implementa un asistente paso a paso
que:

1. Verifica que el snapshot existe y es legible.
2. Detecta si Borg está instalado en el sistema destino.
3. Pregunta si restaurar fuentes APT (con copia real).
4. Ofrece 3 métodos distintos de restauración de paquetes.
5. Pide doble confirmación antes de extraer archivos.
6. Muestra tareas post-restauración.

Además, restore-dry-run permite ejecutar el mismo flujo en modo
simulación: muestra todos los pasos, comandos, paquetes y archivos
que se restaurarían sin modificar absolutamente nada del sistema. Incluye:

• Entornos de desarrollo: resumen por tecnología con comandos de regeneración
• Repositorios git: filtrados por /home/ y /opt/, con branch, commit y remote
• Máquinas virtuales: inventario de imágenes encontradas con nota "NO respaldada"
• Snaps y flatpaks: nombres reales con comandos de instalación (snap install, flatpak install flathub)
• Selección de snapshot: el comando lista snapshots numerados vía list_snapshots()

Es la herramienta ideal para verificar el contenido de un snapshot antes de
comprometerse con una restauración real.

11.5 Arquitectura autocontenida

A diferencia de las soluciones que requieren:

• Múltiples archivos de configuración (rsnapshot: rsnapshot.conf, scripts de pre/post-backup, etc.).
• Bases de datos de estado (Duplicity: archivos de firmas).
• Agentes en segundo plano (timeshift: daemon).

backup.sh es un único archivo bash. Se copia al equipo, se editan 3
variables, se ejecuta init, y el sistema de backup está operativo.
La configuración, los logs, los metadatos y el repositorio están en el
disco externo, no en el sistema.

11.6 Reporte de archivos excluidos

Todas las herramientas de backup tienen exclusiones, pero ninguna informa
al usuario de qué archivos ha excluido. backup.sh ejecuta, tras cada
backup exitoso, un escáner sobre los directorios incluidos que cuenta
archivos y directorios coincidentes con cada patrón de exclusión.

El resultado se muestra en pantalla y se guarda dentro del snapshot como
meta/excluded_report.txt. En restauración, el usuario puede consultar
este reporte para saber qué archivos no están en el backup y cómo
reconstruirlos.

11.7 Captura de repositorios git, entornos de desarrollo y configuración de usuario

Cada snapshot incluye, además de los archivos del sistema, metadatos
estructurados sobre el perfil de usuario:

Repositorios git (meta/git_repos.txt):
ruta, remote origin, rama activa, último commit y número de cambios sin
publicar de cada repositorio .git. Permite saber exactamente qué clonar
(o qué commit revisar) en una restauración.

Entornos de desarrollo (meta/dev_environments.txt):
manifiestos de proyectos (package.json, Cargo.toml, requirements.txt,
pyproject.toml, Gemfile, go.mod, composer.json, Mix.lock, rebar.config).
Cada entrada incluye ruta, tecnología, gestor y comando de regeneración.

Configuración de snaps (meta/snap_config.txt):
snap get ejecutado sobre cada snap instalado. La configuración de las
aplicaciones snap no reside en archivos planos del sistema de archivos,
sino en el almacenamiento interno de snapd. Sin esta captura, las
configuraciones se pierden aunque el snap se reinstale.

Flatpaks completo (meta/flatpak_full.txt):
aplicaciones, runtimes, remotes y overrides de permisos. Los overrides
(permisos por aplicación) no se almacenan en archivos del sistema de
archivos, sino en el almacén de datos de flatpak.

Configuración del escritorio (meta/dconf_dump.txt):
dconf dump / produce texto plano con toda la configuración del
entorno de escritorio (GNOME, Unity, etc.). Restaurable con
dconf load / < meta/dconf_dump.txt.

Claves GPG (meta/gpg_public_keys.asc + meta/gpg_ownertrust.txt):
exportación armored de claves públicas y marcas de confianza. Las claves
privadas ya están en ~/.gnupg/ (respaldadas dentro de /home).

Claves SSH autorizadas (meta/ssh_authorized_keys.txt):
inventario de claves públicas autorizadas por usuario. Las claves
privadas y configuraciones SSH ya están en ~/.ssh/ (respaldadas).

Conexiones NetworkManager (meta/nm_connections.txt):
resumen legible de conexiones de red configuradas. Los archivos reales
están en /etc/NetworkManager/system-connections/ (respaldados).

Imágenes de máquinas virtuales (meta/vm_images.txt):
inventario de imágenes VM encontradas en /home/, /opt/, etc. (formatos:
vdi, vmdk, qcow2, vhd, vhdx, ova, ovf). Solo inventario — no se respaldan
por su gran tamaño. En restauración se muestran con la advertencia de que
requieren un backup específico.

Esto resuelve los problemas clásicos en restauraciones:

1. "Tenía varios repositorios git ¿cuáles eran y dónde estaban?"
2. "Tengo el código, pero las dependencias se excluyeron y no recuerdo cómo reinstalarlas."
3. "Perdí la configuración de los snaps y flatpaks (no está en archivos)."
4. "No recuerdo qué claves GPG/SSH había configuradas."
5. "¿Qué conexiones de red tenía y cómo se llamaban?"
6. "¿Tenía máquinas virtuales en este equipo? ¿Qué imágenes y dónde estaban?"

Los manifiestos y configuraciones se respaldan (están dentro de rutas
incluidas), y el script registra metadatos sobre ellos para que la
restauración sea guiada.

12. Gestión de Dependencia: BorgBackup

backup.sh depende de BorgBackup. Si Borg cambia su CLI, formato de
salida o flags, el script puede fallar.

12.1 Verificación post-actualización

El script incluye check_borg_compat() que verifica automáticamente que
la versión instalada de Borg soporte todas las opciones utilizadas.
Esta función se ejecuta:

• En cmd_now() antes de cada backup (bloqueante: si falta algo, aborta).
• En cmd_doctor() como diagnóstico (informativo: muestra advertencias).

backup.sh doctor          # Diagnóstico completo (incluye compatibilidad)
backup.sh verify          # Verificar passphrase
backup.sh test-restore "$(backup.sh list | head -2 | tail -1 | awk '{print $1}')"

12.2 Puntos de fallo conocidos

12.4 Lecciones aprendidas: bugs cazados durante el desarrollo

Durante las sesiones de desarrollo y shellcheck del script, se
identificaron y corrigieron varios bugs sutiles relacionados con el uso
de set -e y operadores bash:

Lección general: set -e no es una red de seguridad fiable. Cualquier
expresión que pueda retornar no-zero —incluso como parte de un && o ||
que parece inocuo— mata el script sin mensaje de error. Siempre que sea
posible, usar if en lugar de &&/|| para dependencias críticas.

12.5 Prácticas recomendadas

1. Ejecutar backup.sh doctor tras cada apt upgrade borgbackup para verificar que check_borg_compat() no detecta incompatibilidades.
2. Mantener copia del script en el disco de backup (no solo en el sistema).
3. Si Borg cambia su formato de repo, el repo existente sigue siendo legible por versiones anteriores — no actualizar Borg sin verificar.
4. Usar backup.sh test-restore <ultimo-snapshot> tras cada actualización para verificar que la restauración sigue funcionando.

13. Borg es el Taladro, backup.sh es el Robot — El Valor del Sistema Completo

BorgBackup es el motor, pero nosotros construimos un sistema completo
orquestado alrededor. Esto es lo que aportamos:

13.1 Automatización de backup completo

• backup.sh now — un solo comando que hace backup del sistema completo, no solo archivos. Borg por sí solo no sabe qué incluir, ni organiza todo esto.
• Detección automática de qué servicios/BDD están corriendo (MySQL, PostgreSQL, MongoDB, Redis, SQLite, Docker) y volcado consistente de cada uno.

13.2 Metadatos del sistema (lo que hace restaurable el backup)

Borg solo guarda archivos. Nosotros capturamos el estado del sistema
completo en cada snapshot:

• Paquetes instalados (apt, snaps, flatpaks)
• Repositorios apt, PPAs, claves GPG
• Crontabs de todos los usuarios
• Configuración de red (NetworkManager, iptables, nftables)
• Claves SSH autorizadas, GPG, dconf
• Repositorios git y entornos de desarrollo
• Inventario de máquinas virtuales (vm_images.txt — referencia, no respaldadas)
• Servicios systemd, discos, usuarios

Sin esto, restaurar un sistema desde un backup de Borg te deja con
archivos, pero no sabes QUÉ instalar, QUÉ configurar, CÓMO reconstruir.

13.3 Cuatro niveles de restauración

• restore-dry-run — simulación completa sin modificar nada del sistema. Muestra paso a paso qué comandos se ejecutarían, qué paquetes/paquetes manuales/snaps/flatpaks/git/VMs se restaurarían. No requiere root.
• restore <ruta> — restaurar archivo/directorio específico
• test-restore — validar el backup (equivalente a tar -tvf para TODO el ecosistema: BBDD, metadatos, rutas esenciales)
• restore-full — asistente interactivo que guía al usuario paso a paso: fuentes apt, paquetes, BBDD, git, configuraciones

13.4 Seguridad y robustez

• Verificación de compatibilidad de Borg (check_borg_compat) — detecta si una opción no está disponible en la versión instalada
• Protección contra set -e — cazamos y corregimos bugs silenciosos que mataban el script
• Shellcheck limpio — 0 warnings (más de 3000 líneas de bash)
• Función list_snapshots() — lista snapshots numerados en todos los comandos interactivos (restore, mount, diff, restore-full, restore-dry-run, test-restore)
• Validación de rutas en rm -rf — todas empiezan con path literal, nunca con variable
• Dry-run mode — DRY_RUN=true verifica sin ejecutar nada

13.5 Arquitectura lista para producción

• Rotación de logs, compactación post-prune, notificaciones por correo
• Lock para evitar ejecuciones concurrentes
• Modo cron (no interactivo, sin colores, solo log)
• Configurable vía vars editables en el script

13.6 En resumen

Borg es el taladro. Nosotros construimos el robot que sabe qué agujeros
hacer, cuándo, con qué broca, y deja un informe de cada agujero. Sin
nosotros, el usuario tendría que escribir los comandos Borg manualmente,
saber qué incluir/excluir, mantener los scripts de backup de BBDD, y no
tendría metadatos para restaurar — solo archivos sueltos.

14. Consideraciones de Seguridad al Publicar Métricas

BorgShield recolecta una cantidad inusualmente alta de metadatos del
sistema. Esto es una ventaja para la restauración, pero introduce
riesgos de exposición si se publican métricas detalladas del
entorno real.

14.1 Exposición de identidad y huella del sistema

Publicar métricas exactas (kernel, número de paquetes, versiones
específicas) permite a un atacante:

• Identificar CVEs aplicables a una versión exacta de kernel o paquetes.
• Perfilar el hardware y software del sistema objetivo.
• Reducir el espacio de búsqueda de vulnerabilidades.

Mitigación: usar rangos (~360 GB, ~3200 paquetes, Kernel 5.15.x)
en lugar de valores exactos.

14.2 Metadatos fuera del repositorio

Los metadatos en meta/ (logs, paquetes, usuarios, dconf, GPG) están
en texto plano sin cifrar en el disco de backup. A diferencia del
repositorio Borg (AES-256), cualquiera con acceso físico al disco puede
leer esta carpeta.

Mitigación: usar cifrado a nivel de disco (LUKS, BitLocker) en el
disco de backup, o tratar la carpeta meta/ con la confidencialidad
de un log del sistema.

14.3 Captura de logs sin filtrar

Las 200 últimas líneas de syslog, auth.log, kern_log, etc. se capturan
sin filtrar IPs ni nombres de usuario. Si el disco no está cifrado,
estos logs son legibles en texto plano.

14.4 Dumps temporales de bases de datos

Los volcados SQL residen en /var/backups/pre-backup-hooks/ durante
la ejecución del backup. Si el script se interrumpe antes de limpiar,
los dumps quedan en disco principal en formato legible.

Mitigación: el script limpia el directorio al inicio de cada backup
(rm -rf "${pre_dir_name:?}/"*), no al final. Un fallo antes de la
limpieza deja los dumps del backup anterior intactos. Verificar el log
tras cada ejecución.

Referencias

1. BorgBackup Documentation. https://borgbackup.readthedocs.io/
2. Zstandard Compression Algorithm. https://facebook.github.io/zstd/
3. Rsync Project. https://rsync.samba.org/
4. Restic Project. https://restic.net/
5. ntfs-3g FUSE Driver. https://www.tuxera.com/community/open-source-ntfs-3g/
6. RSnapshot. https://rsnapshot.org/
7. Debian Administrator's Handbook. https://debian-handbook.info/
8. Ubuntu Server Guide - Backups. https://ubuntu.com/server/docs/backups

Apéndice A: Glosario

Apéndice B: Comandos Borg Útiles (uso avanzado)

# Ver cambios entre dos snapshots
borg diff /ruta/repo::snap1::snap2

# Exportar un snapshot a otro repositorio
borg transfer /ruta/repo1 /ruta/repo2

# Crear un repo desde cero (avanzado)
borg init --encryption=repokey-blake2 /ruta/repo

# Ver el espacio ocupado por archivos temporales
borg list /ruta/repo --format='{path}{NL}' | wc -l

# Exportar snapshot como tar (para enviar a otro sistema)
borg export-tar /ruta/repo::snapshot /tmp/backup.tar

# Recuperar una copia de la clave del repositorio
borg key export /ruta/repo backup-key.txt

Apéndice C: Crontab recomendado

# MIN HOUR DAY MONTH WEEK COMMAND
# Backup diario a las 3:00 AM
0 3 * * * /home/aor/bin/backup.sh cron >/dev/null 2>&1

# Verificación rápida semanal (domingo 5:00)
0 5 * * 0 /home/aor/bin/backup.sh check >/dev/null 2>&1

# Verificación completa mensual (1er domingo del mes 6:00)
0 6 1-7 * 0 /home/aor/bin/backup.sh check --full >/dev/null 2>&1

Salida: toda la salida se redirige a /dev/null para evitar correos
de cron innecesarios. Los resultados se registran en el log de backup.