dtic-DIIAA/docs/ambito/dtic-DASUTEN/A04.P006_Backups-DASUTEN.md

Plan: Backups y Refresco de Base de Datos DASUTEN

Ámbito: A04 — dtic-DASUTEN

Código: A04.P006
Fecha: 21 de abril de 2026
Autor: Sistema ADN
Versión: 1.4
Estado: ✅ OPERATIVO Y AUTOMATIZADO (Pipeline completo validado + fixes de bitácora aplicados)
Dependencia: A04.P005 (DASUTEN sin DC), A03.P002 (Automatización Backups)

📊 Progreso

Fase	Estado	Avance
Fase 1: Backup de VMs	✅ Completado	100%
Fase 2: Pipeline Google Drive	✅ Completado	100%
Fase 3: Pipeline Diferencial	✅ Completado	100%
Fase 4: Integración BKPs	✅ Completado	100%
Fase 5: Mejora de Latidos	✅ Completado	100%
Fase 6: Validación Pipeline FULL	✅ Completado	100%

Resumen de Validación (2026-04-15)

✅ Pipeline COMPLETO validado de principio a fin

• Backup FULL exportado, transferido, subido, bajado, restaurado y verificado
• Integridad de BD confirmada con DBCC CHECKDB: OK
• Duración total: 13m 15s (dentro de lo estimado: ~35-40 min)
• Todos los drones atómicos funcionaron correctamente en modo orquestado

✅ Migración y configuración de zona horaria validadas

• Zona horaria cambiada de "Romance Standard Time" (UTC+2) a "Argentina Standard Time" (UTC-3)
• Datos sincronizados entre FENIX y DASU-SQL4: 1,339,313 registros
• Validación del usuario (17:00): Andrea Almirón confirma que el sistema desktop muestra correctamente los movimientos del día en curso

Conclusión: El pipeline de backups funcionaba correctamente desde el inicio. La causa raíz de la "desactualización" percibida era la zona horaria incorrecta en dasu-sql4, que desplazaba las fechas ~5 horas adelante (UTC+2 en lugar de UTC-3).

---

🚀 Procedimiento de Ejecución

Leer esta sección primero. Contiene los comandos exactos para ejecutar el backup la próxima vez.

Flujo completo de una sesión de backup

1️⃣ Registrar evento de preparación en bitácora

# Reemplazar HH:MM con la hora actual
./adn/tools/run db evento:crear \
  --inicio "HH:MM" \
  --ambito "dtic-DIIAA" \
  --modo "R" \
  --estado "⏳" \
  --nodo "dtic-BKPs" \
  --ia \
  --doc "ambito/dtic-DASUTEN/A04.P006_Backups-DASUTEN.md" \
  --descripcion "[A04.P006] Preparación para ejecución pipeline backup FULL DASUTEN. Revisión del plan y confirmación de nodos previo al lanzamiento."

Anotar el ID del evento creado (aparece en la salida).

2️⃣ Cerrar el evento de preparación

# Reemplazar <ID> con el ID del evento y HH:MM con la hora actual
./adn/tools/run db evento:actualizar <ID> --fin "HH:MM" --estado "✅"

3️⃣ Lanzar el pipeline

# Pipeline FULL (semanal — ~10-15 min)
./adn/tools/run bkps run dasuten_full --batch

# Pipeline DIFERENCIAL (diario lun-vie — ~5-10 min)
./adn/tools/run bkps run dasuten_diferencial --batch

Registro en bitácora

Los drones registran sus eventos automáticamente bajo:

• Ámbito: dtic-DIIAA
• Nodo: dtic-BKPs (nodo lógico de servicio, ID: 49)

Para consultar los eventos del día:

./adn/tools/run db evento:listar --ambito dtic-DIIAA --nodo dtic-BKPs

Frecuencias recomendadas

Pipeline	Comando	Frecuencia	Horario	Duración
FULL	dasuten_full --batch	Semanal (lunes)	08:00	~10-15 min
Diferencial	dasuten_diferencial --batch	Diario (lun-vie)	08:00	~5-10 min

---

🎯 Objetivo

Establecer un sistema de backups y refrescos de la base de datos DASUTEN que permita:

1. Resguardar VMs del ámbito mediante vzdump (Proxmox)
2. Refrescar la BD desde el servidor original (srvv-fenix) hacia dasu-sql4
3. Automatizar el pipeline mediante drones atómicos integrados en bkps.rb
4. Soportar modos completo y diferencial según frecuencia requerida

🌐 Arquitectura del Pipeline

Flujo Completo (Semanal/Mensual)

srvv-fenix (SQL Server)
    ↓ BACKUP DATABASE TO DISK = 'X:\' WITH COMPRESSION
X:\sysdasuten_FULL_YYYYMMDD_HHMMSS.bak (~1.3 GB)
    ↓ Copy local (share → /var/tmp)
srv-ns8 (/var/tmp/)
    ↓ rclone upload
Google Drive (drive_bkps-dasu)
    ↓ HTTP Download (Invoke-WebRequest)
dasu-sql4 (F:\BACKUP\)
    ↓ RESTORE DATABASE WITH REPLACE
sysdasuten ONLINE

Duración estimada: ~35-40 minutos total

Flujo Diferencial (Diario)

srvv-fenix (SQL Server)
    ↓ BACKUP DATABASE TO DISK = 'X:\' WITH DIFFERENTIAL
X:\sysdasuten_DIF_YYYYMMDD_HHMMSS.bak (~0.4-10 MB)
    ↓ Copy local (share → /var/tmp)
srv-ns8 (/var/tmp/)
    ↓ rclone upload
Google Drive (drive_bkps-dasu)
    ↓ HTTP Download (Invoke-WebRequest)
dasu-sql4 (F:\BACKUP\)
    ↓ RESTORE DATABASE WITH DIFFERENTIAL
sysdasuten ONLINE

Duración estimada: ~5-10 minutos total

Nota de Arquitectura

Un solo destino: Los backups se generan directamente en X:\ (share de srv-ns8), eliminando pasos intermedios innecesarios.

• Antes: E:\BK_SQL\sysdasuten\ → X:\ → /var/tmp/ (3 ubicaciones)
• Ahora: X:\ → /var/tmp/ (2 ubicaciones, 1 copia)

Esto simplifica el flujo y reduce puntos de falla.

📋 Tareas Configuradas (bkps.yml)

Tareas Individuales

ID	Descripción	Tipo	Nodo
dasuten_export_full	📤 Exportar backup COMPLETO DASUTEN	dasuten	srvv-fenix
dasuten_export_dif	📤 Exportar backup DIFERENCIAL DASUTEN	dasuten	srvv-fenix
dasuten_transferir	🔄 Transferir SMB (fenix → ns8)	dasuten	srv-ns8
dasuten_upload	☁️ Upload a Google Drive	dasuten	srv-ns8
dasuten_download	📥 Download desde Google Drive	dasuten	dasu-sql4
dasuten_restaurar_full	💾 Restaurar backup COMPLETO	dasuten	dasu-sql4
dasuten_restaurar_dif	💾 Restaurar backup DIFERENCIAL	dasuten	dasu-sql4
dasuten_verificar	✅ Verificar integridad BD	dasuten	dasu-sql4

Comandos Compuestos

ID	Descripción	Tareas	Frecuencia
dasuten_full	🔄 Pipeline COMPLETO DASUTEN	export_full → transferir → upload → download → restaurar_full → verificar	Semanal
dasuten_diferencial	🔄 Pipeline DIFERENCIAL DASUTEN	export_dif → transferir → upload → download → restaurar_dif → verificar	Diario (lun-vie)

🛸 Drones Atómicos Implementados

Dron	Script	Nodo	Función	Output JSON
exportar	dasuten_exportar_srvv-fenix.rb	srvv-fenix	BACKUP DIRECTO A X: COMPRESSION	backup_ruta_unix, backup_tipo
exportar_dif	dasuten_exportar_diferencial_srvv-fenix.rb	srvv-fenix	BACKUP DIRECTO A X: DIFFERENTIAL	backup_ruta_unix, backup_tipo
transferir	dasuten_transferir_srvv-fenix-srv-ns8.rb	srv-ns8	Copy share → /var/tmp	backup_local, backup_origen
upload	dasuten_upload_srv-ns8-drive.rb	srv-ns8	rclone copy	drive_ruta, drive_url
download	dasuten_download_drive-dasu-sql4.rb	dasu-sql4	Invoke-WebRequest	backup_local, duracion
restaurar	dasuten_restaurar_dasu-sql4.rb	dasu-sql4	RESTORE DATABASE	estado_integridad
restaurar_dif	dasuten_restaurar_diferencial_dasu-sql4.rb	dasu-sql4	RESTORE DATABASE DIFFERENTIAL	estado_integridad
verificar	dasuten_verificar-integridad_dasu-sql4.rb	dasu-sql4	DBCC CHECKDB	estado_integridad

Orquestadores

Script	Función	Uso
orquestador_pipeline.rb	Pipeline completo	ruby orquestador_pipeline.rb
orquestador_pipeline_diferencial.rb	Pipeline diferencial	ruby orquestador_pipeline_diferencial.rb --paso upload

🔧 Integración con BKPs (IMPLEMENTADO)

Procesador: adn/tools/bkps/lib/proc_dasuten.rb

El procesador Dasuten fue integrado en bkps.rb como un nuevo tipo de tarea:

'dasuten' => -> (log) { BKPs::Procesador::Dasuten.new(log) }

Funcionamiento:

1. Cada tarea DASUTEN se mapea a un script de dron atómico
2. El dron se lanza vía ./adn/tools/run dron lanzar
3. La bitácora se registra automáticamente con el nodo y ámbito correspondiente
4. El output de cada dron se guarda en /tmp/dron_*_output.json para el siguiente paso

Comandos disponibles (vía bkps.rb)

# Pipeline completo (semanal - ~35-40 min)
./adn/tools/run bkps run dasuten_full

# Pipeline diferencial (diario - ~5-10 min)
./adn/tools/run bkps run dasuten_diferencial

# Tareas individuales
./adn/tools/run bkps run dasuten_export_full    # Solo exportar completo
./adn/tools/run bkps run dasuten_export_dif     # Solo exportar diferencial
./adn/tools/run bkps run dasuten_transferir     # Solo transferir SMB
./adn/tools/run bkps run dasuten_upload         # Solo upload Drive
./adn/tools/run bkps run dasuten_download       # Solo download Drive
./adn/tools/run bkps run dasuten_restaurar_full # Solo restore completo
./adn/tools/run bkps run dasuten_restaurar_dif  # Solo restore diferencial
./adn/tools/run bkps run dasuten_verificar      # Solo verificar integridad

# Con dry-run (simulación)
./adn/tools/run bkps run dasuten_full --dry-run

# Con modo batch (sin interacción, para cron)
./adn/tools/run bkps run dasuten_diferencial --batch

Frecuencias recomendadas

Comando	Frecuencia	Horario	Duración
dasuten_full	Semanal (lunes 08:00)	Inicio jornada	~35-40 min
dasuten_diferencial	Diario (lun-vie 08:00)	Inicio jornada	~5-10 min

📅 Frecuencia de Backups

Tipo	Frecuencia	Retención	Horario
VMs (vzdump)	Semanal (domingo 03:00)	4 semanas	Madrugada
BD Completo	Semanal (lunes 08:00)	4 semanas	Inicio jornada
BD Diferencial	Diario (lun-vie 08:00)	5 días	Inicio jornada

📊 Resultados Históricos

Fecha	Tipo	Duración	Tamaño	Estado
2026-04-14 15:54	Completo	44.8s	1.33 GB	✅
2026-04-14 16:03	Diferencial	2.44s	0.39 MB	✅
2026-04-14 16:35	Upload Drive	23.79s	0.39 MB	✅
2026-04-15 11:01	Pipeline FULL	13m 15s	~1.3 GB	✅ COMPLETO
2026-04-15 16:30	Migración + TZ	~30 min	~1.3 GB	✅ COMPLETO
2026-04-15 17:00	Validación Usuario	—	—	✅ VALIDADO (Andrea Almirón)
2026-04-21 07:21	Pipeline FULL	10m 50s	~1.3 GB	✅ COMPLETO + fixes bitácora

Detalle Pipeline 2026-04-15 (Test Completo)

Paso	Tarea	Nodo	Duración	Estado
1	dasuten_export_full	srvv-fenix	46s	✅
2	dasuten_transferir	srv-ns8	2s	✅
3	dasuten_upload	srv-ns8	7m 9s	✅
4	dasuten_download	dasu-sql4	52s	✅
5	dasuten_restaurar_full	dasu-sql4	13s	✅
6	dasuten_verificar	dasu-sql4	4m 11s	✅

Migración y Corrección de Zona Horaria (2026-04-15 16:30)

Problema identificado: El usuario reportó que el sistema DASUTEN desktop mostraba datos desactualizados (solo hasta el 13 de abril).

Causas raíz:

1. Los backups se exportaban y subían a Drive correctamente, pero el paso de restore no se ejecutaba automáticamente
2. Zona horaria incorrecta en dasu-sql4: estaba configurada como "Romance Standard Time" (UTC+2, Europa/París) en lugar de "Argentina Standard Time" (UTC-3)

Solución aplicada:

1. Saneamiento de backups viejos en dasu-sql4 (4 archivos eliminados, ~4 GB liberados)
2. Restauración completa desde F:\BACKUP\sysdasuten_FULL_20260415_130531.bak
3. Configuración de zona horaria Argentina (UTC-3) en dasu-sql4

Acción	Detalle	Resultado
Limpieza F:\BACKUP\	5 archivos → 1 archivo	~4 GB liberados
Restore completo	sysdasuten_FULL_20260415_130531.bak	1,339,313 registros
Zona horaria	Romance ST → Argentina ST	UTC+2 → UTC-3 ✅

Verificación post-migración:

Métrica	FENIX	DASU-SQL4	Estado
Última fecha	2026-04-15	2026-04-15	✅
Registros 15/04	84	84	✅
Registros 14/04	370	370	✅
Registros 13/04	603	603	✅
Total BonosAfiliado	-	1,339,313	✅
Zona horaria	UTC-3	UTC-3	✅

Nota técnica: La columna idsolicitud muestra valor 0 para los registros nuevos (desde ~2026). Esto es un problema heredado de FENIX (no del restore) y no es crítico porque:

• idsolicitud NO es la clave primaria (la PK es PK_BONOSAFILIADO)
• La tabla funciona correctamente con los datos actuales
• No hay duplicados problemáticos

Validación del usuario (2026-04-15 17:00):

La usuaria Andrea Almirón (aalmiron) confirmó que el sistema DASUTEN desktop ahora muestra correctamente los movimientos del día en curso, resolviéndose el problema que se presentaba anteriormente donde los datos no se veían actualizados.

Conclusión: El problema de la zona horaria era la causa principal de la discrepancia percibida. Los backups se realizaban correctamente, pero la configuración UTC+2 (Europa) en lugar de UTC-3 (Argentina) provocaba que las fechas se interpretaran con un desplazamiento de ~5 horas, afectando la visualización de los datos en el sistema desktop.

Throughput:

• Upload a Drive: ~3 MB/s (limitado por ancho de banda de subida)
• Download desde Drive: ~25 MB/s (HTTP directo)
• Restore SQL: instantáneo (MOVE de archivos)
• DBCC CHECKDB: ~1.2M páginas verificadas en 4m 11s

🧪 Sesión de Test Completa (2026-04-15)

Objetivo: Validar el pipeline completo de backup/restore usando backup FULL (no diferencial).

Ejecución Orquestada (REINICIADA)

Se utiliza el comando orquestado dasuten_full que ejecuta los 6 pasos en secuencia automáticamente.

Paso	ID Tarea	Dron	Nodo	Estado	Duración
1	dasuten_export_full	dasuten_exportar_srvv-fenix.rb	srvv-fenix	⏳ Pendiente	—
2	dasuten_transferir	dasuten_transferir_srvv-fenix-srv-ns8.rb	srv-ns8	⏳ Pendiente	—
3	dasuten_upload	dasuten_upload_srv-ns8-drive.rb	srv-ns8	⏳ Pendiente	—
4	dasuten_download	dasuten_download_drive-dasu-sql4.rb	dasu-sql4	⏳ Pendiente	—
5	dasuten_restaurar_full	dasuten_restaurar_dasu-sql4.rb	dasu-sql4	⏳ Pendiente	—
6	dasuten_verificar	dasuten_verificar-integridad_dasu-sql4.rb	dasu-sql4	⏳ Pendiente	—

Comando orquestado:

# Ejecución completa (6 pasos en secuencia)
./adn/tools/run bkps run dasuten_full --batch

Notas de la sesión:

• Tipo de backup: FULL/COMPLETO (~1.3 GB esperado)
• Ejecución: Orquestada (un solo comando, 6 pasos automáticos)
• Heartbeats acumulados: Se prueba la nueva mejora de latidos que muestra las últimas 15 líneas del progreso en Bitácora Web

---

Registro de Ejecución — Test 2026-04-15

Hora	Paso	Resultado	Duración	Observaciones
11:01	🚩 TEST INICIADO	—	—	Pipeline FULL orquestado (dasuten_full --batch)
11:01	1. Exportar	✅ Completado	46s	Backup FULL en X:\ (srvv-fenix)
11:02	2. Transferir	✅ Completado	2s	SMB: fenix → ns8 (/var/tmp/)
11:02	3. Upload	✅ Completado	7m 9s	rclone: ns8 → Google Drive (~1.3 GB)
11:09	4. Download	✅ Completado	52s	HTTP: Drive → dasu-sql4 (F:\BACKUP\)
11:10	5. Restore	✅ Completado	13s	RESTORE DATABASE WITH REPLACE + MOVE
11:10	6. Verificar	✅ Completado	4m 11s	DBCC CHECKDB — Integridad: OK
11:14	🏁 PIPELINE COMPLETADO	✅	13m 15s	Todos los pasos exitosos

Resultados clave:

• ✅ Backup FULL de ~1.3 GB transferido correctamente
• ✅ Google Drive como intermediario (sin dependencia de Tailscale)
• ✅ Restore completado con MOVE a F:\DATA y F:\LOG
• ✅ DBCC CHECKDB: Integridad OK (base de datos consistente)

---

Ejecuciones anteriores (descartadas):

• Paso 4 (Restore diferencial): ✅ 14.7s — ejecutado de forma aislada, no corresponde a esta sesión FULL

⚠️ Consideraciones Técnicas

Google Drive Download

• Virus confirmation page: Archivos >100MB requieren confirmación. Se maneja extrayendo parámetros id, uuid, confirm del HTML.
• URL confirmada: https://drive.usercontent.google.com/download?id=...&confirm=...&uuid=...

dasu-sql4 Sleep Mode

• La VM entra en suspensión cuando no se usa.
• Solución: Acceso vía relay SSH desde srv-dasu con sshpass + ProxyCommand.

Base64 Encoding

• Scripts PowerShell se codifican en base64 para transporte sobre SSH.
• Evita problemas de escaping UTF-8 en Windows Core.

Comunicación entre Drones

• Cada dron escribe output en /tmp/dron_*_output.json
• El siguiente dron lee el JSON del anterior para obtener contexto
• Formato: {"paso": "...", "backup_local": "...", "duracion": N, ...}

Módulo Común: dasu_executor.rb

Para evitar código repetido, los drones que se comunican con dasu-sql4 o srvv-fenix usan el módulo DasuExecutor:

require_relative 'lib/dasu_executor'

# Ejecutar PowerShell en dasu-sql4 vía srv-dasu
DasuExecutor.execute_ps_on_dasu(ps_script, output_path: 'C:\temp\output.json')

# Leer JSON desde dasu-sql4
resultado = DasuExecutor.read_json_from_dasu('C:\temp\output.json')

# Verificar archivo en fenix (share X:)
file_info = DasuExecutor.get_file_info_on_fenix(client, 'X:\backup.bak')

Funciones disponibles:

Función	Propósito
execute_ps_on_dasu(ps_script, output_path:)	Ejecuta PowerShell en dasu-sql4 vía SSH
read_json_from_dasu(output_path)	Lee y parsea JSON desde dasu-sql4
execute_ps_on_fenix(client, ps_script)	Ejecuta PowerShell en fenix vía xp_cmdshell
file_exists_on_fenix?(client, path)	Verifica si existe archivo en fenix
get_file_info_on_fenix(client, path)	Obtiene tamaño y existencia de archivo

Beneficio: El patrón SSH/PowerShell se define en un solo lugar. Si cambia, se actualiza solo el módulo.

🔗 Referencias

• Ámbito A03: A03_dtic-BKPs.md
• Ámbito A04: A04_dtic-DASUTEN.md
• Pipeline Diferencial: A04.P005_DASUTEN-sin-DC.md
• Drones: adn/tools/cli/drones/
• Bitácoras: ./adn/tools/run db evento:listar --ambito dtic-DASUTEN
• Evolución Dron ADN: A01.P009_Evolucion-Dron-ADN.md — Heartbeat acumulado

📝 Lecciones Aprendidas

Fecha	Lección	Impacto
2026-04-14	SMB password con $ requiere escape (\\$)	Transferencia fallida sin escape
2026-04-14	Upload dron debe leer backup_local desde transfer output	Timeout por archivo incorrecto
2026-04-14	Download dron requiere --file-id o leer desde upload output	Error por falta de parámetro
2026-04-14	Pipeline diferencial: 0.39 MB vs 1.3 GB completo	90% más rápido para refrescos diarios
2026-04-14	Un solo destino (X:) vs 3 directorios	Menos puntos de falla, más simple
2026-04-14	Módulo común DasuExecutor: 6 drones, 1 solo patrón	-52% código, mantenibilidad
2026-04-15	Heartbeat con output acumulado en Bitácora Web	Visibilidad completa del progreso de drones multi-paso
2026-04-15	Zona horaria incorrecta pasa desapercibida	Datos "actualizados" pero invisibles para el usuario — validar TZ en todo restore
2026-04-15	Validación usuario es crítica	El pipeline técnicamente exitoso necesita confirmación del usuario final
2026-04-21	create_entrada no aceptaba ambito_id	Eventos de drones no se registraban en bitácora — fix: agregar kwarg a firma y SQL
2026-04-21	detectar_nodo_id ignoraba el parámetro nodo	Siempre usaba hostname local — fix: lookup por nombre pasado, fallback a hostname
2026-04-21	Separar nodo operacional de nodo de bitácora	El nodo del yml (srvv-fenix, etc.) es interno al dron; bitácora debe usar dtic-BKPs
2026-04-21	Registrar evento de preparación antes del pipeline	El procedimiento debe iniciar creando un evento ⏳ en bitácora y cerrarlo antes de lanzar

📈 Mejora de Latidos/Acumulados (2026-04-15)

Problema: Los drones de pipeline (ej: download, restaurar, verificar) muestran progreso tipo [1/3], [2/3], [3/3], pero la bitácora web solo mostraba la última línea, perdiendo el contexto del progreso.

Solución: Modificar Ejecutor#ejecutar_comando en adn/tools/cli/dron/ejecutor.rb para acumular todo el output y mostrar las últimas 15 líneas en el heartbeat web.

Resultado: La Bitácora Web ahora muestra el progreso completo acumulado:

🛸 Download desde Google Drive (`dron_152045_789`)
├─ Comando: `ruby dasuten_download_drive-dasu-sql4.rb`
└─ ❤️ 2m 30s — heartbeat #5

```text
[*] Dron: Download desde Google Drive
    Nodo: dasu-sql4
    Drive ruta: rmonla-GDrive:drive_bkps-dasu/sysdasuten.bak
    File ID: 1P0ci...
    Destino: F:\BACKUP\sysdasuten.bak

[1/3] Iniciando descarga con Rclone Nativo...
[2/3] Descargando...
[+] Descarga en 45.2s
[3/3] Verificando...
    Tamano: 1.33 MB

**Impacto:** Visibilidad en tiempo real del progreso de cada paso del pipeline, no solo la última línea.

**Documentación:** La mejora se documentó en [A01.P009_Evolucion-Dron-ADN.md](../dtic-ADN/A01.P009_Evolucion-Dron-ADN.md) como Fase F1.5b.