DEV Community: Arcadio Ortega Reinoso

BorgShield: Sistema de Backup Linux Eficiente, Fiable y Verificable

Arcadio Ortega Reinoso — Thu, 23 Jul 2026 17:51:24 +0000

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

Capacidad	rsync	rsnapshot	restic	duplicity	timeshift	Borg CLI	backup.sh
Un solo archivo	❌	❌	✅	❌	❌	❌	✅
Sin archivos de configuración externos	❌	❌	❌	❌	❌	N/A	✅
Dumps BBDD automáticos	❌	❌	❌	❌	❌	❌	✅
Test-restore virtual	❌	❌	❌	❌	❌	❌	✅
Simulación restauración	❌	❌	❌	❌	❌	❌	✅
Metadatos de paquetes	❌	❌	❌	❌	❌	❌	✅
Restauración guiada	❌	❌	❌	❌	❌	❌	✅
Reporte de exclusiones	❌	❌	❌	❌	❌	❌	✅
Mapa de repos git	❌	❌	❌	❌	❌	❌	✅
Entornos de desarrollo	❌	❌	❌	❌	❌	❌	✅
Inventario de VMs	❌	❌	❌	❌	❌	❌	✅
Crontab-ready	❌	❌	❌	❌	❌	❌	✅
Modo silencioso/sin prompts	❌	❌	❌	❌	❌	❌	✅

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

1.2 Lo que otros tienen y backup.sh no

Capacidad	Herramienta	Impacto
Backup multi-cloud nativo (S3, B2, Azure, GCP)	restic	backup.sh requiere rclone como capa adicional
Binario único sin dependencias	restic	backup.sh requiere bash + borg + rsync + python3
Archivos directamente accesibles sin extracción	rsync	backup.sh requiere borg extract o mount (FUSE)
Interfaz gráfica (GUI)	timeshift, deja-dup	backup.sh es solo CLI
Instantáneas de arranque (boot-time recovery)	timeshift	backup.sh requiere disco externo montado
Cifrado GPG interoperable	duplicity	backup.sh usa formato Borg (no portable sin Borg)
Verificación integrada post-backup	restic (restic check)	backup.sh requiere comando explícito check
Backups remotos vía SSH nativo	rsync, Borg CLI	backup.sh está diseñado para disco local

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:

Ausencia de deduplicación: los backups completos duplican datos que no han cambiado, consumiendo espacio innecesario.
Falta de verificación: sin checksums, no hay garantía de que los datos almacenados sean recuperables.
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.
Restauración compleja: recuperar un sistema completo desde cero requiere múltiples herramientas y conocimientos.
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:

Métrica	Valor
Distribución	Ubuntu 22.04.5 LTS
Kernel	5.15.x
Paquetes totales	~3200
Paquetes manuales	~460
Datos en /	~360 GB
Disco de backup	NTFS 1.9T (418 GB libres)

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 /):

Métrica	Valor
Archivos en el sistema	~2.500.000
Tamaño raw de los datos incluidos	145 GB
Tamaño comprimido (zstd,3)	100 GB
Tamaño deduplicado en repositorio	80 GB
Ratio de deduplicación	~1,8x
Duración del backup completo	3h 27m
Conexión del disco externo	USB 2.0 (480 Mbps)
Sistema de archivos destino	NTFS (ntfs-3g FUSE)

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:

Plazo	Tamaño estimado	Disco libre (418 GB)
Inicial (full)	80 GB	338 GB
+6 meses	~95 GB	~323 GB
+12 meses	~110 GB	~308 GB

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:

Tipo	USB 2.0 (actual)	USB 3.0 / SATA
Primer backup (full)	3-4 horas	30-60 min
Backup incremental diario	3-8 minutos	1-3 minutos
`borg check --verify-data`	2-3 horas	20-40 min
`borg prune` + `compact`	< 1 minuto	< 30 seg

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

Característica	rsync	rsnapshot	restic	BorgBackup
Deduplicación	No	Hardlinks	Sí (bloques)	Sí (bloques)
Compresión	No	No	Sí	Sí (zstd)
Cifrado	No	No	Sí	Sí (AES-256)
Verificación	No	No	SHA-256	SHA-256
Montaje FUSE	N/A	N/A	Sí	Sí
Restauración granular	Inmediata	Inmediata	vía mount	vía mount
Backup remoto nativo	Sí	No	Sí (multi-cloud)	No (con rclone sí)
FS subyacente	Cualquiera	Hardlinks req.	Cualquiera	Cualquiera
Dependencias	Ninguna	rsync	Binario único	python3
Madurez	25+ años	15+ años	7+ años	15+ años

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:

Por comando: borg check verifica que todos los chunks son legibles y que sus checksums coinciden.
Por snapshot: backup.sh mount <snap> y navegación manual comprueba que los archivos están accesibles.
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:

Motor	Comando de volcado	Portable entre versiones
MySQL/MariaDB	`mysqldump --all-databases --single-transaction`	Sí
PostgreSQL	`pg_dumpall`	Sí
MongoDB	`mongodump`	Sí
Redis	`SAVE` + copia de dump.rdb	Parcial (misma versión major)
SQLite	`.backup` vía sqlite3	Sí

Ventajas de los dumps frente a copia raw:

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.
Consistencia transaccional: mysqldump --single-transaction garantiza una instantánea consistente del momento en que comenzó el dump.
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.
Restauración selectiva: un dump SQL se puede editar con un editor de texto para restaurar solo una tabla o una fila.
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:

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

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

Copiar backup.sh y ejecutar restore-full:

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

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

Dependencia de BorgBackup: el sistema requiere instalar borgbackup. En sistemas sin acceso a internet, esto puede ser un obstáculo.
Backup remoto no nativo: a diferencia de Restic, Borg no tiene soporte nativo para S3 o Backblaze. Se requiere rclone como capa adicional.
Rendimiento en NTFS: aunque Borg funciona sobre NTFS, el rendimiento puede ser inferior al de ext4 debido a la capa FUSE (ntfs-3g).
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.
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

Soporte para backup remoto: añadir modo rclone que sincronice el repositorio Borg a la nube.
Notificaciones push: integración con Telegram, Pushover o Gotify.
Interfaz TUI: menú interactivo para usuarios menos técnicos.
Pre/Post hooks: scripts personalizados que se ejecuten antes y después del backup (ej. dump de base de datos).
Reporte HTML: generar un reporte visual del estado del backup.
Soporte LXD/LXC/KVM: detección y backup de contenedores y máquinas virtuales.
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:

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).
Fiabilidad: los checksums SHA-256 verifican cada byte almacenado. El comando check --full garantiza que todos los datos son recuperables.
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.
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:

Motor	backup.sh	rsync/rsnapshot/timeshift	Borg puro
MySQL	`mysqldump` automático	Copia raw (dañada si mysqld activo)	Copia raw (dañada)
PostgreSQL	`pg_dumpall` automático	Copia raw (dañada)	Copia raw (dañada)
MongoDB	`mongodump` automático	Copia raw (dañada)	Copia raw (dañada)
Redis	`SAVE` + RDB	Copia raw	Copia raw

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:

Verifica que el snapshot existe y es legible.
Detecta si Borg está instalado en el sistema destino.
Pregunta si restaurar fuentes APT (con copia real).
Ofrece 3 métodos distintos de restauración de paquetes.
Pide doble confirmación antes de extraer archivos.
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:

"Tenía varios repositorios git ¿cuáles eran y dónde estaban?"
"Tengo el código, pero las dependencias se excluyeron y no recuerdo cómo reinstalarlas."
"Perdí la configuración de los snaps y flatpaks (no está en archivos)."
"No recuerdo qué claves GPG/SSH había configuradas."
"¿Qué conexiones de red tenía y cómo se llamaban?"
"¿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

Componente	Dependencia Borg	Verificado por	Riesgo
`borg create`	`--one-file-system`, `--numeric-ids`, `--exclude-nobackups`, `--exclude-caches`, `--compression`, `--stats`, `--progress`	`check_borg_compat`	Bajo
`borg info --json`	Estructura JSON de salida	`check_borg_compat`	Medio
`borg list --format="..."`	Placeholders de formato ({archive}, {time}, {size})	`check_borg_compat`	Medio
`borg check --verify-data`	Flag disponible desde Borg 1.2	`check_borg_compat`	Medio
`borg compact`	Comando disponible desde Borg 1.2	`check_borg_compat`	Bajo
`borg prune`	`--keep-daily`, `--keep-weekly`, `--keep-monthly`, `--keep-yearly`	`check_borg_compat`	Bajo
`borg init --encryption`	Flag `--encryption`	`check_borg_compat`	Bajo
`borg extract`	Comportamiento de rutas	Verificación manual	Bajo

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:

Bug	Síntoma	Causa	Fix
`load_passphrase` mata el script	El script termina silenciosamente sin error aparente	`[ -z "$var" ] && error` retorna 1 cuando `$var` no está vacía (cortocircuito `&&`), y `set -e` propaga el exit code no-zero	`if [ -z "$var" ]; then error; fi` — `if` no propaga exit code
`rotate_log` mata el script en 1ª ejecución	El script muere al hacer el primer backup (log no existe)	`[ -f "$log" ] \	\
{% raw %}`DRY_RUN=true` por env no funciona	Dry-run se ignora aunque se pase como variable de entorno	`DRY_RUN=false` en el script es asignación directa, no condicional, y sobrescribe el env	`DRY_RUN="${DRY_RUN:-false}"` — solo usa el default si env no está definido
`DRY_RUN` imprime pero ejecuta igual	El mensaje "MODO SIMULACIÓN" se muestra, pero el backup real se ejecuta	El bloque dry-run no tenía `return 0`, por lo que el flujo caía en `borg create`	Añadir `return 0`
`tr -d ' '` no elimina newlines	`[: entero esperado]` en conteos de líneas de git, flatpak, etc.	`tr -d ' '` solo elimina espacios, no newlines, carriage returns, etc.	`tr -d '[:space:]'`
`PASSPHRASE_FILE` ignorado con sudo	`sudo ./backup.sh now` busca passphrase en `/root/` en vez de `/home/user/`	`$HOME` cambia a `/root` con sudo, pero la passphrase está en el home del usuario real	Detectar `SUDO_USER` y usar su home; `mkdir` con fallback a `sudo mkdir`
`borg extract -C` no existe en Borg 1.2.0	`backup.sh restore` falla: flag `--destination`/`-C` no soportado	Borg 1.2.0 no implementa `-C`; apareció en Borg 1.4	Reemplazar por `pushd "$dir" && borg extract && popd`
`borg list REPO::ARCHIVE` extremadamente lento	El script tardaba minutos en verificar si un snapshot existe	`borg list` recorre los 2.5M de archivos; `borg info` es O(1)	Reemplazar `borg list REPO::ARCHIVE` por `borg info REPO::ARCHIVE`
`{NL}` vs `\n` en format string de Borg	`borg list --format` no interpretaba `\n`	Borg 1.2.0 usa `{NL}` como placeholder de nueva línea, no `\n`	Usar `{NL}` en lugar de `\n` en format strings
`\033` entre comillas simples no es escape	Los colores ANSI no se mostraban	`'\033'` en bash es literal `\033` (tres caracteres), no el byte escape	Usar `$'\033'` (ANSI-C quoting) para que bash interprete el escape
`grep -c		echo "0"` produce doble salida	Cuando grep encuentra 0 coincidencias, imprime "0" en stdout pero retorna 1. `\
{% raw %}`${manual_pkgs - 10}` no es aritmética bash	Error de sintaxis: "entero esperado"	En bash la resta aritmética requiere `$(( ... ))`, los espacios alrededor del operador no bastan	Usar `$(( manual_pkgs - 10 ))`

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

Ejecutar backup.sh doctor tras cada apt upgrade borgbackup para verificar que check_borg_compat() no detecta incompatibilidades.
Mantener copia del script en el disco de backup (no solo en el sistema).
Si Borg cambia su formato de repo, el repo existente sigue siendo legible por versiones anteriores — no actualizar Borg sin verificar.
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

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

Apéndice A: Glosario

Término	Definición
BorgBackup	Software de backup con deduplicación, compresión y cifrado
Chunk	Bloque de datos de tamaño variable (64 KiB-1 MiB) en que Borg divide los archivos
Deduplicación	Almacenamiento de un solo bloque idéntico aunque aparezca en múltiples archivos
FUSE	Filesystem in Userspace — permite montar un snapshot como directorio
Hardlink	Múltiples entradas de directorio apuntando al mismo inodo (datos)
HMAC	Hash-based Message Authentication Code
NTFS-3G	Controlador NTFS en espacio de usuario (FUSE)
PBKDF2	Password-Based Key Derivation Function — función lenta para derivar clave de una frase
Prune	Eliminación automática de snapshots según política de retención
repokey	Modo de cifrado donde la clave se almacena dentro del repositorio
Snapshot	Instantánea del sistema en un momento dado
Zstandard	Algoritmo de compresión moderno con niveles de 1 a 22

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.

Generar epub desde una lista de ficheros html

Arcadio Ortega Reinoso — Wed, 15 Jul 2026 08:59:30 +0000

Desde html hasta epub

Ejemplos de libros que he generado desde mis páginas html

En https://github.com/aortrei469/epubDesdeHTML se encuentra el software al que se hace referencia en el artículo

Generar epub desde una relación de ficheros html

HACER COPIA DE SEGURIDAD DE TODO ANTES DE EMPEZAR

Cambiamos el contenido del <head> de todos los ficheros html que formarán parte del epub

Dejamos, como ejemplo:

<head>
    <title>XXXXX</title>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta name="author" content="XXXXXXXXXXXXXXX" />
    <meta name="robots" content="noindex, nofollow" />
    <link rel="stylesheet" href="css/manual.css" type="text/css" media="all" />
</head>

Purgar todo aquello que no se pueda encontrar en el epub, por ejemplo en mi caso tengo que Eliminar todos los <a> que engloban a las <img> en las <figure>

Utilidad:

aor@aorsrv:~/proyectos/opencode/epubHtmlToEpub$ ls *.sh
eliminaTagASobreTagImg.sh

Ejemplo:

aor@aorsrv:~/proyectos/opencode/epubHtmlToEpub/libro$ ../eliminaTagASobreTagImg.sh 
Procesando: 0_Infraestructura.html
Procesando: 1_srv01.html
Procesando: 2_srv01_maquinas_virtuales.html
Procesando: 3_SRV01_mv_database.html
Procesando: 4_SRV01_mv_grafana_loki.html
Procesando: 5_SRV01_mv_openproject.html
Procesando: 6_srv01_n8n.html
Procesando: 7_wordpress.html
Hecho. Backups creados como *.bak

También tendré problemas con los grafos. Buscamos los <div class="mermaid">

Eliminamos del lo siguiente

    <script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
    <script>
        mermaid.initialize({
            startOnLoad: true,
            theme: 'default',
            securityLevel: 'loose',
            flowchart: { useMaxWidth: true, htmlLabels: true },
            sequence: { useMaxWidth: true }
        });
    </script>

Así como todos los scripts que estemos usando. Es mejor no usarlos, es sólo
documentación.

Para mermaid generamos también la imagen y según sea para html o epub lo
seleccionaremos mediante estilo

Ejemplo:

.mermaid {
    display: none !important;
}

.img-mermaid {
    display: block !important;
}

Cambiarle el css para que corte tablas, código etc.

Usamos el css que tenemos preparado para los ebooks. Esto es,
resultadoBaseEpubEnMIsDocumentos.css

...
...

/* ==========================================================================
   8. PAGINACIÓN Y CONTROL DE SALTOS (Reglas Kindle)
   ========================================================================== */
h1, h2, h3 {
    page-break-after: avoid;
}
figure, .diagram-container, table, pre {
    page-break-inside: avoid;
}

En epub por ejemplo no se pueden usar atributos como align , por lo que lo
trabajamos mediante clases

/*
ya no se puede usar align
*/
.texto-centrado {
    text-align: center;
}
.texto-derecha {
    text-align: right;
}

Limpiar metadatas

sudo apt install mat2
find ./libro/images/ -type f -exec mat2 --inplace {} +
Vemos los errores obtenidos, y los solucionamos

Verificar que no quedan metadatos

sudo apt install libimage-exiftool-perl
find ./libro/images/ -type f $ -iname "*.jpg" -o -iname "*.jpeg" -o -iname "*.png" $ -exec sh -c 'echo "=== Examinando: $1 ==="; exiftool "$1" | grep -E "Camera|Date|Software|Modify|Create|Artist|Copyright"' _ {} \;
(En una sola imagen: exiftool imagen.jpg.)

Verificamos que no tengamos espacios en blanco en nombres de ficheros

Para saber si hay ficheros que no cumplen ejecutamos:

aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ cat verificar_epub.sh 
#!/bin/bash

# Comprobar si se ha pasado un directorio como argumento
if [ -z "$1" ]; then
    echo "Uso: $0 /ruta/al/directorio/del/epub"
    exit 1
fi

TARGET_DIR="$1"

# Verificar si el directorio existe
if [ ! -d "$TARGET_DIR" ]; then
    echo "Error: El directorio '$TARGET_DIR' no existe."
    exit 1
fi

echo "Iniciando verificación de nombres de archivo en: $TARGET_DIR"
echo "--------------------------------------------------------"

ALERTA=0

# Buscar todos los archivos de forma recursiva
while IFS= read -r -d '' archivo; do
    # Obtener solo el nombre del archivo (sin la ruta)
    nombre=$(basename "$archivo")
    # Obtener la ruta relativa desde el directorio objetivo
    ruta_relativa="${archivo#$TARGET_DIR/}"

    # 1. Exclusión del archivo mimetype en la raíz (es una excepción válida)
    if [ "$ruta_relativa" == "mimetype" ]; then
        continue
    fi

    # 2. Verificar caracteres no permitidos (solo permite A-Z, a-z, 0-9, ., _, -)
    if [[ ! "$nombre" =~ ^[A-Za-z0-9._-]+$ ]]; then
        echo "[ERROR] Caracteres inválidos o espacios en: $ruta_relativa"
        ALERTA=1
    fi

    # 3. Verificar longitud del nombre del archivo (máximo 255 bytes)
    if [ ${#nombre} -gt 255 ]; then
        echo "[ERROR] Nombre demasiado largo (>255 caracteres): $ruta_relativa"
        ALERTA=1
    fi

done < <(find "$TARGET_DIR" -type f -print0)

echo "--------------------------------------------------------"
if [ $ALERTA -eq 0 ]; then
    echo "¡Éxito! Todos los archivos cumplen con las restricciones de EPUB."
else
    echo "Se han encontrado errores. Corrige los nombres antes de compilar el EPUB."
fi

Ejemplo:

aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ ./verificar_epub.sh libro
Iniciando verificación de nombres de archivo en: libro
--------------------------------------------------------
[ERROR] Caracteres inválidos o espacios en: images/wordpress/Captura de pantalla_2025-11-21_19-06-12.jpg
[ERROR] Caracteres inválidos o espacios en: images/wordpress/Captura de pantalla_2025-11-21_19-05-41.jpg
[ERROR] Caracteres inválidos o espacios en: images/wordpress/Captura de pantalla_2025-11-21_19-02-49.jpg
[ERROR] Caracteres inválidos o espacios en: images/wordpress/Captura de pantalla_2025-11-21_19-04-55.jpg
[ERROR] Caracteres inválidos o espacios en: images/wordpress/Captura de pantalla_2025-11-21_19-04-41.jpg
[ERROR] Caracteres inválidos o espacios en: images/wordpress/Captura de pantalla_2025-11-21_19-03-30.jpg
[ERROR] Caracteres inválidos o espacios en: images/wordpress/Captura de pantalla_2025-11-21_19-04-26.jpg
--------------------------------------------------------
Se han encontrado errores. Corrige los nombres antes de compilar el EPUB.

Generamos el libro

source env/bin/activate
./env/bin/python generar_epub.py

Chequeamos el libro generado

sudo apt install epubcheck

epubcheck libro.epub

Una vez que lo tenemos (hasta entonces: eliminar epub, regenerar, volver a
chequear

Actualizamos los errores encontrados en nuestro ficheros htm originales

Si los hemos conservado. HACER COPIA DE SEGURIDAD ANTES DE EMPEZAR

Vamos a minificar nuestros documentos

sudo apt install -y minify

minify -r --html-keep-conditional-comments --match=".*\.(html|xhtml|css)$" -o libro/ libro_min/

Ejemplo:

(env) aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ mkdir libro_min
(env) aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ minify -r --html-keep-conditional-comments --match=".*\.(html|xhtml|css)$" -o libro_min libro
(env) aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ ls libro
0_Infraestructura.html  2_srv01_maquinas_virtuales.html  4_SRV01_mv_grafana_loki.html  6_srv01_n8n.html  css
1_srv01.html            3_SRV01_mv_database.html         5_SRV01_mv_openproject.html   7_wordpress.html  images
(env) aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ ls libro_min/
libro
(env) aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ ls libro_min/libro/
0_Infraestructura.html  2_srv01_maquinas_virtuales.html  4_SRV01_mv_grafana_loki.html  6_srv01_n8n.html  css
1_srv01.html            3_SRV01_mv_database.html         5_SRV01_mv_openproject.html   7_wordpress.html

Verificamos el resultado Y volvemos a generar el libro minimizado

(env) aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ rm -f libro.epub 
(env) aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ ./env/bin/python generar_epub.py
Páginas HTML: 8
CSS:          1
Imágenes:     42
  ✓ 0_Infraestructura.html → 0_Infraestructura.xhtml  (NUBE PRIVADA INTEGRAL)
  ✓ 1_srv01.html → 1_srv01.xhtml  (Server01)
  ✓ 2_srv01_maquinas_virtuales.html → 2_srv01_maquinas_virtuales.xhtml  (Server01. MVs)
  ✓ 3_SRV01_mv_database.html → 3_SRV01_mv_database.xhtml  (database)
  ✓ 4_SRV01_mv_grafana_loki.html → 4_SRV01_mv_grafana_loki.xhtml  (observability)
  ✓ 5_SRV01_mv_openproject.html → 5_SRV01_mv_openproject.xhtml  (OpenProject)
  ✓ 6_srv01_n8n.html → 6_srv01_n8n.xhtml  (n8n)
  ✓ 7_wordpress.html → 7_wordpress.xhtml  (wordpress)

 EPUB generado: libro.epub
    ID: xxxxxxxxxxxx
(env) aor@aorsrv:~/proyectos/opencode/epubDesdeHtml$ epubcheck libro.epub
Validación usando la versión de reglas epub 3.2.
No se han detectado errores o advertencias.
Mensajes: 0 errores fatales / 0 errores / 0 advertencias / 0 indicaciones

EPUBCheck completado

Cargamos en Sigil

~/Descargas$ ./Sigil-2.7.6-x86_64.AppImage

Y hacemos:

Herramientas

MUY IMPORTANTE HAY QUE HACER TODOS LOS PASOS

Editar metadatos
Añadir portada
Reformatear HTML
Comprobar epub F7

Complementos

Edición -> Baka-jpeg

El plugin Baka-Jpeg para Sigil tiene como objetivo comprimir y reducir el
tamaño de las imágenes en tu archivo ePub, tomando decisiones inteligentes.

El plugin procesa formatos como JPG, BMP y PNG, y en el caso de los PNG, los
convierte a JPEG si determina que esto reducirá significativamente el tamaño
del archivo (por ejemplo, en fotografías o imágenes complejas).

Recomendación: tener solo jpg en las páginas html antes de iniciar el
proceso

Tener en cuenta:

Para textos o dibujos: El plugin es "inteligente" e intenta evitar comprimir archivos PNG que contienen texto nítido, ya que pasarlos a JPEG puede hacer que se vean borrosos.
Conversión: Sí, puede transformar imágenes PNG a JPG para optimizar el peso total del libro electrónico.
Recomendación: Como este tipo de plugins modifica los archivos de forma permanente, siempre se aconseja hacer una copia de seguridad o guardar tu archivo ePub antes de ejecutarlo.

El plugin realiza todo el proceso en tres pasos internos:

Conversión: Transforma el archivo físico de la imagen de .png a .jpeg.
Actualización del código: Busca todas las etiquetas <img src="..."> en tus archivos HTML y cambia la extensión .png por .jpeg para que sigan apuntando al archivo correcto.
Actualización del Manifiesto: Modifica el archivo de control del ePub (content.opf) para registrar el nuevo formato de imagen.

Tras usarlo verificar que todo queda correcto, hacer una búsqueda por
ejemplo de todos los .png

pensamiento computacional

Arcadio Ortega Reinoso — Thu, 02 Jul 2026 17:08:18 +0000

Pensamiento Computacional: Una Herramienta Mental para el Siglo XXI

Arcadio Ortega Reinoso — Thu, 02 Jul 2026 17:02:23 +0000

El Pensamiento Computacional (PC) ha emergido no solo como una disciplina técnica, sino como un proceso mental humano fundamental para resolver problemas, diseñar sistemas y comprender el comportamiento humano a través de los conceptos de la informática. Lejos de limitarse al aprendizaje de la programación, se considera hoy una habilidad analítica básica, tan crucial como la lectura, la escritura o la aritmética.

Los Cuatro Pilares del Pensamiento Computacional

El núcleo del PC se sostiene sobre cuatro capacidades cognitivas esenciales que permiten abordar la complejidad de manera estructurada:

Descomposición: Consiste en la habilidad de fragmentar un problema complejo en partes más pequeñas y manejables, facilitando que cada pieza sea comprendida y solucionada de forma independiente.
Reconocimiento de Patrones: Es el proceso de identificar tendencias o regularidades dentro de los problemas, lo que permite aplicar soluciones ya conocidas a nuevos subproblemas similares.
Abstracción: Considerada la esencia del PC, implica centrarse exclusivamente en la información relevante, ignorando los detalles innecesarios para crear modelos simplificados de la realidad.
Pensamiento Algorítmico: La capacidad de diseñar una serie de pasos ordenados e instrucciones precisas para alcanzar una solución ejecutable por un humano o una máquina.

La Dimensión Cognitiva: Pensar Rápido y Despacio

La integración de la psicología cognitiva en el PC, basada en el modelo de Daniel Kahneman, revela que esta disciplina requiere un esfuerzo consciente del Sistema 2 (Pensamiento Lento). Mientras que el Sistema 1 opera de forma intuitiva y rápida, el PC exige actividades deliberadas para decomponer programas grandes o analizar la complejidad de los datos, evitando así los sesgos y errores del pensamiento automático.

Para estructurar este pensamiento, se recurre a menudo al Método de Pólya, una secuencia lógica de cuatro pasos: comprender el problema, elaborar un plan, ejecutarlo y, finalmente, realizar una revisión retrospectiva y metacognitiva de la solución.

Debates y Paradigmas Educativos

A pesar de su expansión, el campo del PC enfrenta desacuerdos fundamentales sobre su naturaleza y enseñanza:

¿Proceso Mental o Práctica Social? Algunos expertos definen el PC puramente como una capacidad cognitiva individual. Otros proponen la "Acción Computacional", argumentando que el aprendizaje es más efectivo cuando los estudiantes crean proyectos con un impacto real en su comunidad.
¿Independiente de la Programación? Existe un debate sobre si la programación es el vehículo indispensable o si el PC puede desarrollarse como un proceso de pensamiento independiente de la tecnología específica.
Implementación Curricular: Las estrategias oscilan entre la integración transversal en materias como ciencias o matemáticas y la creación de una materia específica de informática para asegurar el rigor.

Del Entendimiento Profundo a la Creación Empoderada

Para distinguir entre un estudiante que ha memorizado definiciones y uno que posee un entendimiento profundo, es necesario evaluar la aplicación de conceptos en contextos nuevos. Un experto en PC no solo sabe que un algoritmo "funciona", sino que evalúa su eficiencia y es capaz de realizar una transferencia de conceptos a tareas cotidianas no tecnológicas. En última instancia, el objetivo es transformar al individuo de un consumidor pasivo a un creador empoderado que utiliza la tecnología para generar cambios significativos en el mundo.

Bibliografía de Referencia

Bordignon, F., & Iglesias, A. A. (2020). Introducción al pensamiento computacional. Ciudad Autónoma de Buenos Aires: UNIPE; Editorial Universitaria; EDUCAR S.E..
Chun, B., & Piotrowski, T. (2023). Pensamiento computacional ilustrado: Una guía de dibujos animados para solucionar problemas, diseñar sistemas y comprender el comportamiento humano. Eduteka / ctiillustrated.com.
Kiwelekar, A. W., Navandar, S., & Yadav, D. K. (2020). A Two-Systems Perspective for Computational Thinking. Proceedings of 12th International Conference on Intelligent Human Interaction (IHCI 2020). Springer.
Kong, S. C., & Abelson, H. (Eds.). (2019). Computational Thinking Education. Springer Nature Singapore Pte Ltd..
Al-Fedaghi, S., & Alkhaldi, A. A. (2019). Thinging for Computational Thinking. Kuwait University, Computer Engineering Department. Vol. 10, No. 2.

Actuando sobre la Seguridad Perimetral: Cómo Implementar un Cortafuegos Dinámico basado en el Comportamiento DNS

Arcadio Ortega Reinoso — Fri, 12 Jun 2026 11:33:22 +0000

En el panorama actual de la ciberseguridad, los métodos tradicionales de filtrado a menudo se quedan cortos ante usuarios que utilizan VPNs, túneles o servidores DNS externos para evadir políticas corporativas. Para abordar este reto, he desarrollado un ecosistema de dos herramientas complementarias: Network Sniffer y DNS Traffic Controller, diseñadas para transformar la navegación de los usuarios en reglas de firewall inteligentes y en tiempo real.

El Concepto: "Si no hay consulta DNS, no hay tráfico"

La filosofía central de esta solución es la visibilidad total. La idea base consiste en capturar todas las peticiones DNS de la red y actuar sobre cualquier dirección IP que no haya sido obtenida mediante una resolución previa. Este enfoque de "lista blanca dinámica" asegura que los dispositivos no puedan conectarse a IPs "hardcodeadas" o servidores maliciosos que intenten saltarse la resolución estándar del sistema.

1. Fase de Análisis: Network Sniffer

Antes de bloquear, es vital entender el tráfico. Network Sniffer es una herramienta para Ubuntu que permite capturar y clasificar las conexiones entrantes y salientes.

Captura Inteligente: Utiliza tcpdump para monitorizar consultas DNS y Scapy para el análisis de paquetes, extrayendo metadatos clave como el SNI (Server Name Indication) incluso en tráfico cifrado TLS.
Clasificación de Riesgo Offline: Una de sus mayores ventajas es que realiza un análisis 100% offline de amenazas utilizando bases de datos como Spamhaus DROP y MaxMind GeoLite2.
Generación de Blocklists: Tras el análisis (ya sea en tiempo real o mediante consulta posterior a logs JSON/TXT), la herramienta puede exportar listas de bloqueo automáticas en formatos compatibles con MikroTik, iptables, DNSMasq y BIND.

2. Fase de Control: DNS Traffic Controller

Una vez definido el comportamiento deseado, DNS Traffic Controller se encarga de la ejecución de las reglas. Esta herramienta ofrece dos modos de operación según la infraestructura necesaria.

Modo Router (Filtro Perimetral)

Es la solución ideal para una empresa. Actúa como un gateway/router usando ipset e iptables para una eficiencia máxima.

Proxy DNS Transparente: Intercepta todas las queries DNS (puerto 53) y las redirige a un proxy local.
Autorización Dinámica: Cuando un usuario consulta un dominio legítimo, el sistema obtiene las IPs resueltas y las añade automáticamente al conjunto dns_allowed de ipset.
Filtrado Estricto: El firewall permite el tráfico solo hacia las IPs presentes en ese conjunto, bloqueando todo lo demás de forma predeterminada.

Bloqueos Avanzados y Evasión

Para evitar que los usuarios salten el muro, el sistema incluye reglas específicas para denegar:

DNS Externos y Cifrados: Bloquea DNS sobre TLS (puerto 853), DoH (DoH-block) y el uso de QUIC/HTTP3 (puerto 443 UDP).
VPNs y Túneles: Detecta y bloquea protocolos de VPN conocidos (OpenVPN, WireGuard, IPsec) y herramientas de tunelización como ngrok o Cloudflare Tunnel.
Contenido No Deseado: Incluye soporte para listas negras de control parental, educativo y dominios sospechosos.

Integración en el Flujo de Trabajo Empresarial

Este conjunto de herramientas permite establecer un ciclo de seguridad cerrado:

Monitorización con Network Sniffer: Se analizan los patrones de navegación para identificar qué dominios son necesarios para la actividad empresarial.
Establecimiento de la Entrada del Firewall: Con los datos capturados, se configura el DNS Traffic Controller para que actúe como la barrera de entrada, permitiendo solo lo estrictamente resuelto mediante el DNS corporativo.
Auditoría y Refinamiento: Se generan informes periódicos (en HTML o JSON) para ajustar las listas negras y blancas, detectando posibles intentos de conexión a países de alto riesgo (como KP, IR o SY) o puertos sospechosos de troyanos.

Fortalezas técnicas para destacar en el artículo

Eficiencia con ipset: En el modo Router Controller, el uso de ipset es un factor diferencial. Permite manejar grandes listas de IPs permitidas o bloqueadas sin degradar el rendimiento del firewall, algo crucial para entornos empresariales con mucho tráfico.
Análisis 100% Offline: Es un gran argumento de venta para la privacidad. Network Sniffer realiza geolocalización (MaxMind) y detección de amenazas (Spamhaus DROP) de forma local, evitando que los metadatos de la empresa salgan a APIs externas durante el análisis.
Detección de Evasión Avanzada: Tus herramientas no solo filtran por IP/Dominio; también están preparadas para bloquear DNS sobre TLS (puerto 853), QUIC/HTTP3 (puerto 443 UDP) y herramientas de tunelización como ngrok o Cloudflare Tunnel, que son los métodos habituales para saltarse firewalls tradicionales.
Modo "Deep" para Auditoría: El Network Sniffer en su modo profundo aporta un valor forense importante al incluir resolución PTR, WHOIS y detección de proveedores de Cloud/Hosting, lo que permite a un administrador saber exactamente quién es el dueño de la infraestructura a la que se conectan sus usuarios.
Versatilidad de Exportación e Integración: Una de las mayores ventajas de este ecosistema es su capacidad para convertir el análisis de red en reglas ejecutables de forma casi instantánea. Network Sniffer no solo identifica amenazas, sino que permite exportar automáticamente listas de bloqueo (blocklists) en formatos nativos para las infraestructuras más comunes. Esto incluye scripts .rsc para MikroTik, configuraciones de zona para BIND y Unbound, directivas para DNSMasq, así como reglas de filtrado para iptables o formatos universales como archivos Hosts y CSV. Esta interoperabilidad garantiza que la inteligencia de seguridad generada pueda integrarse sin fricciones en firewalls y servidores DNS ya existentes, permitiendo a los administradores ajustar el nivel de restricción según un umbral de riesgo personalizado.

Conclusión

Al combinar la capacidad de análisis profundo de Network Sniffer con el control dinámico de DNS Traffic Controller, las organizaciones pueden pasar de un modelo de seguridad pasivo a uno proactivo. Ya no se trata solo de bloquear lo conocido como malo, sino de permitir únicamente lo que el sistema ha validado previamente a través de una consulta legítima.

Si quieres explorar el código o contribuir al proyecto, ambos repositorios están disponibles en mi perfil de GitHub:

dns-traffic-controller
network-sniffer

La Nueva Abstracción de la Ingeniería de Software y la Crisis Educativa de la Sintaxis

Arcadio Ortega Reinoso — Wed, 10 Jun 2026 10:24:11 +0000

La Nueva Abstracción: El Programador como Arquitecto en la Era de la IA

La historia de la ingeniería de software es una crónica de la huida constante hacia niveles superiores de abstracción. Así como en décadas pasadas el programador dejó de preocuparse por el lenguaje máquina o el ensamblador para enfocarse en lenguajes de alto nivel, hoy asistimos a un nuevo desplazamiento de la "caja negra". La Inteligencia Artificial actúa ahora como un "lubricante" que traduce la lógica conceptual directamente en código ejecutable, permitiendo que el profesional se sitúe mucho más cerca de los requerimientos que de la sintaxis. Sin embargo, a pesar de este "superpoder" de implementación, los cimientos de los problemas clásicos de la disciplina permanecen inalterados.

La Crisis Permanente y el "Qué" sobre el "Cómo"

A pesar de las herramientas modernas, el fracaso en los proyectos suele tener una raíz sociotécnica más que técnica. Los problemas clásicos de definición —donde el cliente rara vez sabe lo que quiere con precisión— siguen siendo el principal obstáculo. La IA puede generar código de manera impecable, pero si el análisis de requisitos es vago o erróneo, la máquina construirá a la perfección el producto equivocado. Este dilema subraya la persistencia de la Validación (¿estamos construyendo lo que el usuario realmente necesita?) como un desafío puramente humano.

La IA como Lubricante de la Implementación

En la fase de construcción, la IA ha venido a mitigar fricciones históricas que consumían gran parte del tiempo del desarrollador:

Fin del "Infierno de la Sintaxis": Reduce el tiempo perdido buscando documentación o resolviendo problemas de sintaxis triviales.
Explicación de Código Ajeno: Facilita la comprensión de "código espagueti" o sistemas heredados, eliminando el miedo a tocar módulos antiguos (el síndrome del código huérfano).
Automatización de Pruebas: Al generar suites de pruebas unitarias con rapidez, ayuda a combatir el síndrome de "en mi máquina funciona" y reduce los fallos de integración.
Refactorización: Permite limpiar estructuras rígidas y reducir la deuda técnica en segundos, algo que tradicionalmente tomaba horas de rediseño.

Los Nuevos Riesgos: Código Zombi y Deuda Técnica

No obstante, esta facilidad conlleva peligros. La capacidad de generar código masivo sin un entendimiento profundo puede derivar en "código zombi": sistemas que funcionan pero cuya lógica interna nadie comprende realmente. Esto no elimina la deuda técnica, sino que la transforma en una forma más insidiosa de complejidad que puede superar la capacidad cognitiva humana a medida que el sistema crece.

El Cambio de Paradigma en la Enseñanza y el Rol Profesional

Bajo este escenario, el programador deja de ser un "escribano" para convertirse en un revisor y arquitecto. La enseñanza de la informática debe evolucionar desde la enseñanza de la sintaxis hacia la gestión de la complejidad y la comunicación. Los objetivos pedagógicos actuales deben centrarse en:

Ingeniería de Requisitos y Contexto: Aprender a alimentar a los modelos con la información correcta (Ingeniería del Contexto) para obtener resultados precisos.
Verificación y Validación (V&V): Priorizar la capacidad de supervisar si el producto cumple con las especificaciones y satisface al usuario.
Metodologías Híbridas: Implementar flujos de trabajo donde humanos y agentes colaboren bajo marcos ágiles como Scrumban. El uso de agentes (como CrewAI) permite automatizar la implementación mientras el humano se centra en la dirección estratégica y el flujo de valor.

Concluyendo: Aunque la "caja negra" de la implementación sea ahora más grande y eficiente, la esencia de la ingeniería de software sigue siendo la traducción de ideas abstractas en productos funcionales. El éxito en este nuevo paradigma no depende de la velocidad de codificación, sino de la precisión en la definición y la rigurosidad en la validación del sistema resultante.

¿Qué opinas? Si eres docente o estudiante, ¿crees que los centros educativos están reaccionando a tiempo a este cambio de paradigma? ¿Estamos preparados para evaluar a "arquitectos" en lugar de a "escribanos" de código? Espero leer tu perspectiva en los comentarios.

Aula Informática compartida, eficiente y centralizada con Linux

Arcadio Ortega Reinoso — Wed, 03 Sep 2025 15:21:11 +0000

Cómo Construir un Aula Informática Eficiente y Centralizada con Linux
La gestión de un aula informática con múltiples estaciones de trabajo puede ser una tarea desafiante. Mantener la consistencia del sistema, gestionar las cuentas de usuario, y asegurar el espacio en disco son solo algunas de las preocupaciones comunes. Afortunadamente, con herramientas de código abierto como NIS, LDAP, NFS y Autofs, podemos construir una solución robusta y fácil de administrar.
Recientemente he consolidado una guía detallada para configurar un entorno de aula informática centralizado en un repositorio de GitHub, donde los estudiantes pueden iniciar sesión en cualquier máquina cliente con sus cuentas y directorios personales gestionados desde un servidor central
. El objetivo es mantener una configuración consistente en las máquinas cliente y gestionar eficazmente el uso de recursos

Las tecnologías clave empleadas en esta configuración para lograr un entorno gestionado centralmente incluyen:
• Servicio de Información de Red (NIS) o Protocolo Ligero de Acceso a Directorios (LDAP): Estos servicios son fundamentales para centralizar la gestión de cuentas de usuario y grupo. Permiten que los usuarios se autentiquen en cualquier máquina cliente, facilitando el inicio de sesión único y la administración de credenciales

• Sistema de Archivos de Red (NFS): Utilizado para compartir los directorios personales de los usuarios (/home) desde el servidor central. De esta manera, los datos de los estudiantes están siempre accesibles, sin importar en qué estación de trabajo inicien sesión

• Autofs: Complementa a NFS al montar automáticamente los directorios personales de los usuarios solo cuando se accede a ellos, optimizando el uso de recursos al evitar montar todos los directorios al inicio del sistema

• Cuotas de Disco: Implementadas para limitar el espacio en disco y la cantidad de archivos que cada usuario puede utilizar en su directorio personal, gestionado en el servidor NFS. Esto es crucial para un uso equitativo de los recursos

• Congelación del Sistema (bilibop-lockfs): Una característica poderosa para mantener el sistema operativo de las máquinas cliente en un estado inmutable. Cualquier cambio realizado durante una sesión se descarta al reiniciar, lo que asegura una configuración limpia y consistente en cada uso

• Scripts y Programación (Cron): Para automatizar la creación de usuarios y facilitar el proceso de actualización de los sistemas congelados, minimizando la intervención manual

El resultado es un aula informática donde los usuarios disfrutan de una experiencia consistente en cualquier estación de trabajo, sus datos se guardan de forma centralizada y los recursos se gestionan eficientemente, mientras que el estado base de las estaciones de trabajo se mantiene siempre idéntico

Si estás interesado en implementar una configuración similar o simplemente quieres profundizar en los pasos de instalación y configuración de cada uno de estos componentes, he detallado todo el proceso en mi repositorio de GitHub. Allí encontrarás las instrucciones paso a paso para servidores y clientes, así como scripts de ejemplo y verificaciones esenciales

aula-compartida

Este artículo se basa en la documentación "Aula de informática" de Arcadio Ortega Reinoso, bajo licencia CC BY-NC-SA 4.0

DEV Community: Arcadio Ortega Reinoso

BorgShield: Sistema de Backup Linux Eficiente, Fiable y Verificable

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

Fortalezas Diferenciales

Resumen

1. Ventaja Diferencial

1.1 Matriz de diferenciación

1.2 Lo que otros tienen y backup.sh no

2. Introducción y Planteamiento del Problema

2.1 El problema del backup en Linux

2.2 Requisitos del sistema

3. Soluciones Existentes y sus Limitaciones

3.1 rsync con hardlinks (rsnapshot)

3.2 Restic

3.3 Timeshift (modo rsync)

3.4 BorgBackup

4. Arquitectura Propuesta

4.1 Visión general del sistema

4.2 Flujo de ejecución de backup.sh now

4.3 Estructura de un snapshot Borg

4.4 Gestión de metadatos fuera del repositorio

5. Evaluación Comparativa

5.1 Métricas del sistema real

5.2 Proyección de espacio en disco

5.3 Proyección de tiempo de ejecución

5.4 Matriz de características

6. Garantías de Restauración

6.1 Nivel 1: Restauración por archivo

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

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

6.4 Verificación de restaurabilidad

7. Decisiones de Diseño

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

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

7.3 ¿Por qué metadatos fuera del repositorio?

7.4 ¿Por qué repokey y no keyfile?

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

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

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

8. Casos de Uso y Escenarios

8.1 Uso diario (cron)

8.2 Backup antes de una actualización del sistema

8.3 Cambio de disco duro

8.4 Múltiples equipos en el mismo disco

9. Limitaciones y Trabajo Futuro

9.1 Limitaciones conocidas

9.2 Posibles mejoras

10. Conclusiones

11. Diferenciadores Clave Respecto a Otras Soluciones

11.1 Restauración virtual (test-restore)

11.2 Dumping automático de BBDD sin configuración

11.3 Metadatos completos del sistema en cada snapshot

11.4 Restauración guiada interactiva

11.5 Arquitectura autocontenida

11.6 Reporte de archivos excluidos

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

12. Gestión de Dependencia: BorgBackup

12.1 Verificación post-actualización

12.2 Puntos de fallo conocidos

12.4 Lecciones aprendidas: bugs cazados durante el desarrollo

12.5 Prácticas recomendadas

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

13.1 Automatización de backup completo

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

13.3 Cuatro niveles de restauración

13.4 Seguridad y robustez

13.5 Arquitectura lista para producción

13.6 En resumen

14. Consideraciones de Seguridad al Publicar Métricas

14.1 Exposición de identidad y huella del sistema

14.2 Metadatos fuera del repositorio

14.3 Captura de logs sin filtrar

14.4 Dumps temporales de bases de datos

Referencias

Apéndice A: Glosario

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

Apéndice C: Crontab recomendado

Generar epub desde una lista de ficheros html

Desde html hasta epub

Ejemplos de libros que he generado desde mis páginas html

4.2 Flujo de ejecución de `backup.sh now`

7.4 ¿Por qué `repokey` y no `keyfile`?

11.1 Restauración virtual (`test-restore`)