Files

T

Ricardo Monla 65dd92b769 docs & tools: Actualización de informes y scripts de migración DASUTEN

2026-04-20 16:25:51 -03:00

27 KiB

Raw Blame History

INFORME TÉCNICO — Migración del Sistema DASUTEN a Nuevo Servidor

Área: Departamento de Tecnología de la Información y Comunicaciones (DTIC)
Proyecto: Migración de infraestructura DASUTEN — Modo Workgroup sin Domain Controller
Código interno: A04.P005
Fecha del informe: 13 de abril de 2026
Elaborado por: Ricardo Monla — Área DTIC, UTN-FRLR
Versión: 1.0 — COMPLETADO Y VALIDADO

Este documento contiene el detalle técnico completo de la migración. Para la síntesis ejecutiva, ver 01_informe_ejecutivo_DASUTEN.md.

1. Resumen Ejecutivo

Se informa el avance de la migración del sistema de gestión administrativa D.A.S.U.Te.N (Dirección de Acción Social de la Universidad Tecnológica Nacional) desde la infraestructura compartida de la Facultad hacia un entorno independiente, autónomo y simplificado.

Estado general del proyecto: 100% completado y validado.

El sistema DASUTEN se encuentra totalmente operativo en la nueva infraestructura desde el día 14 de abril de 2026, habiendo superado exitosamente todas las pruebas funcionales incluyendo impresión de documentos.

Validación final (15/04/2026 17:00): La usuaria Andrea Almirón (aalmiron) confirmó que el sistema desktop muestra correctamente los movimientos del día en curso, resolviéndose el problema de datos "desactualizados" tras la corrección de la zona horaria en dasu-sql4 (UTC-3 Argentina).

Logros principales

✅ Servidor de base de datos completamente migrado a infraestructura nueva.
✅ Base de datos de producción restaurada y verificada sin errores de integridad.
✅ Sistema DASUTEN desplegado y operativo en la PC física de la usuaria.
✅ Impresión de documentos resuelta mediante symlink.
✅ Eliminación exitosa de la dependencia del Active Directory (Domain Controller).
✅ Simplificación de la arquitectura de red — de 3 servidores virtuales a 1.
✅ Pipeline de backups automatizado con drones atómicos.
✅ Zona horaria configurada correctamente (UTC-3 Argentina) en dasu-sql4.
✅ Validación del usuario confirmada (15/04/2026): datos actualizados visibles en el sistema desktop.

2. Antecedentes y Motivación

2.1 Infraestructura original (en red de Facultad)

El sistema DASUTEN operaba sobre infraestructura compartida con la Facultad Regional La Rioja, dependiendo de:

Un servidor SQL Server alojado en la red interna de la Facultad (srvv-fenix).
Un Domain Controller Active Directory para la autenticación de usuarios.
Conectividad de red interna de la Facultad con routing complejo.

Esta configuración generaba múltiples puntos de falla:

Dependencia del dominio institucional para la autenticación.
Complejidad de red con subnetting privado, NAT y gateway interno.
Cualquier cambio en la infraestructura de la Facultad impactaba directamente en DASUTEN.

2.2 Esquema de trabajo provisorio (AnyDesk + PC Virtual)

Al reubicarse la oficina DASUTEN en un espacio propio alejado de los servidores, se agravaron las fallas de conectividad: la señal de red recorría múltiples puntos intermedios dentro del edificio, y la caída de cualquiera de ellos dejaba a la oficina sin sistema.

Para dar continuidad al servicio, se gestionó una línea de internet propia para la oficina y se implementó el siguiente esquema de trabajo:

PC Física (dasu-pc)                    Servidor srv-dasu (Proxmox VE)
  Usuarias: Almirón / Molina              ├── VM 100: dasu-srvv-dc  (Domain Controller AD DS)
  Acceso: AnyDesk ──────────────────►     ├── VM 101: dasu-srvv-sql (SQL Server + BD sysdasuten)
                    (escritorio remoto)    └── VM 102: dasu-pcv     (PC Virtual ← trabajo aquí)

Componentes requeridos: 4 (servidor dominio + servidor BD + PC virtual + PC física con AnyDesk).

Flujo de trabajo de las usuarias: PC física → AnyDesk (escritorio remoto) → PC virtual → sistema DASUTEN.

Este esquema permitió:

Dar continuidad al servicio independientemente de la red interna de la Facultad.
Brindar asistencia técnica 24/7 por parte de DTIC vía acceso remoto.

Pero implicaba:

Experiencia de trabajo indirecta para las usuarias (doble salto).
Cuatro componentes simultáneos que debían estar operativos.
Múltiples puntos de falla que dificultaban el soporte.

2.3 Objetivo del proyecto

Migrar el sistema DASUTEN a una infraestructura independiente y simplificada, eliminando la dependencia del Domain Controller (Active Directory), el esquema de escritorio remoto, y utilizando un esquema de red Workgroup directo, con el fin de:

Reducir la complejidad operativa (de 4 componentes a 2).
Permitir trabajo directo (sin AnyDesk intermedio).
Minimizar los puntos de falla.
Garantizar la autonomía operativa de DASUTEN respecto de la infraestructura de la Facultad.
Facilitar la eventual gestión desde Rectorado (Buenos Aires) si fuera necesario.

3. Infraestructura Implementada

3.1 Arquitectura de red

Se implementó una topología de red plana simplificada, donde todos los equipos obtienen direccionamiento IP directamente del router del ISP, eliminando subnetting privado y routing interno:

Internet
   │
Router ISP (192.168.1.1 — Gateway)
   │
   ├── srv-dasu (Proxmox VE)      → 192.168.1.13
   │    └── dasu-sql4 (VM 106)    → 192.168.1.11  [SQL Server 2019]
   │
   └── dasu-pc (PC Física)        → DHCP ISP       [Estación de trabajo]

3.2 Componentes del nuevo entorno

Componente	Descripción	Estado
srv-dasu	Servidor Proxmox VE 9.1 (Hipervisor) — CPU Intel, 15 GB RAM, 94 GB disco	✅ Operativo
dasu-sql4 (VM 106)	Windows Server 2022 — SQL Server 2019 Enterprise — 4 GB RAM, 2 vCPU, discos 60+120 GB	✅ Operativo
dasu-pc	PC Física — Windows 10 Pro — AMD Ryzen 5, 8 GB RAM — Oficina DASUTEN	✅ Operativo

3.3 Comparativa: Antes vs. Después

Aspecto	Enfoque Anterior (con DC + AnyDesk)	Enfoque Actual (Workgroup)
Componentes	4 (DC + SQL + PC virtual + PC física)	2 (SQL + PC física)
Forma de trabajo	Indirecta (AnyDesk → PC virtual)	Directa (sistema en PC)
Red	Privada 10.0.100.x (gateway interno)	DHCP del ISP (red plana)
Autenticación SQL	Windows Integrated (Kerberos)	SQL Auth (mixta)
Usuarios	Active Directory	Usuarios locales Windows
DNS	AD DNS (10.0.100.10)	DNS del ISP (automático)
Complejidad de red	Alta (DC + DNS + dominio + routing)	Mínima (red plana ISP)
Puntos de falla	DC, SQL, red dominio, routing, AnyDesk	Solo SQL
VMs necesarias	3 (DC + SQL + PC virtual)	1 (solo SQL)

4. Fases Ejecutadas y Progreso

Resumen de progreso por fase

Fase	Descripción	Estado	Progreso
1	Preparación del entorno (srv-dasu)	✅ Completada	100%
2	Creación de VM SQL Server de prueba	✅ Completada	100%
3	Creación de VM PC Cliente de prueba	✅ Completada	100%
4	VM definitiva dasu-sql4	✅ Completada	100%
5	Migración de base de datos	✅ Completada	100%
5b	Hardening y persistencia de servicios	✅ Completada	100%
6	Validación con PC cliente virtual	✅ Completada	100%
7	Despliegue en PC física (producción)	🚧 En curso	75%
8	Refresco final de base de datos	✅ Completada	100%

4.1 Fase 1-3: Preparación y pruebas de concepto (27-28 marzo)

Se preparó el hipervisor Proxmox, se reconfiguró el bridge de red para usar DHCP directo del ISP, y se crearon VMs de prueba para validar la viabilidad del enfoque sin Domain Controller.

Hallazgo crítico: Se detectó y resolvió que el bridge de red estaba configurado con la IP de una red privada anterior, lo cual habría impedido la conectividad de las nuevas VMs.

4.2 Fase 4: Servidor SQL definitivo (9-10 abril)

Se creó la VM definitiva dasu-sql4 (VM 106) con una arquitectura optimizada:

Discos separados: 60 GB para SO + 120 GB exclusivo para datos SQL (buena práctica).
SQL Server 2019 Enterprise instalado con autenticación mixta.
Gestión remota asegurada vía OpenSSH Server (puerto 7022) y Tailscale VPN.

4.3 Fase 5: Migración de Base de Datos (11 abril)

Se ejecutó la migración completa de la base de datos de producción:

Exportación: Backup comprimido (~1.33 GB) generado desde el servidor origen (srvv-fenix).
Transferencia: Archivo movido a través de la VPN institucional (Tailscale) en múltiples tramos seguros.
Restauración: Base restaurada exitosamente en 26 segundos (354 MB/s).
Verificación: DBCC CHECKDB ejecutado sin errores — integridad de datos confirmada al 100%.

4.4 Fase 5b: Hardening (11 abril)

Se validó que todos los servicios críticos (SSH, SQL Server) sobreviven reinicios del servidor sin intervención manual:

OpenSSH Server: arranque automático ✅
SQL Server: arranque automático ✅
IP de red: mantenida tras reinicio ✅

4.5 Fase 6: Validación funcional en entorno virtual (11 abril)

Se restauró una VM cliente desde backup para simular el entorno real de la oficina DASUTEN:

Se desvinculó la PC del dominio anterior y se unió al Workgroup DASUTEN.
Se reconfiguró el archivo de conexión del sistema (Kermet.ini) para apuntar al nuevo servidor SQL.
Resultado: El sistema DASUTEN conectó exitosamente, actualizó estructuras y descargó novedades.

Conclusión técnica clave: Se determinó mediante ingeniería inversa que el sistema DASUTEN (desarrollado en Visual FoxPro) no tiene dependencia real del Active Directory si se configura explícitamente la autenticación SQL en su archivo de configuración.

4.6 Fase 7: Despliegue en PC física de producción (13-14 abril — COMPLETADA)

Se desplegó el sistema en la PC física de la oficina DASUTEN (dasu-pc):

Directorio del sistema (C:\SysDasuten) transferido desde la VM de pruebas.
Configuración de conexión apuntada al nuevo servidor dasu-sql4.
Acceso directo creado en el escritorio de la usuaria (aalmiron).
Pruebas funcionales:
- Inicio del sistema: ✅ OK
- Acceso a datos (ventana de bonos): ✅ OK
- Impresión: ✅ RESUELTO (2026-04-14) — Symlink C:\Sistema → C:\SysDasuten\Sistema permite encontrar plantillas Word/Excel.

Solución técnica: El sistema DASUTEN (Visual FoxPro) hardcodea la ruta C:\Sistema\Word\ para las plantillas. Se creó un symlink que redirige transparentemente al directorio real C:\SysDasuten\Sistema\, sin necesidad de modificar el ejecutable compilado.

4.7 Fase 8: Pipeline de Backups (14 abril — COMPLETADO)

Se implementó un pipeline automatizado de drones atómicos para el refresco de la base de datos:

Arquitectura del pipeline:

srvv-fenix → BACKUP TO X:\ (share srv-ns8)
    ↓
srv-ns8 → rclone upload → Google Drive
    ↓
dasu-sql4 → Invoke-WebRequest → RESTORE DATABASE → DBCC CHECKDB

Drones implementados (6 drones atómicos):

dasuten_exportar_srvv-fenix.rb — BACKUP DATABASE WITH COMPRESSION
dasuten_transferir_srvv-fenix-srv-ns8.rb — Copy share → /var/tmp
dasuten_upload_srv-ns8-drive.rb — rclone copy → Google Drive
dasuten_download_drive-dasu-sql4.rb — Invoke-WebRequest ← Google Drive
dasuten_restaurar_dasu-sql4.rb — RESTORE DATABASE WITH REPLACE
dasuten_verificar-integridad_dasu-sql4.rb — DBCC CHECKDB

Comunicación entre drones: Cada dron escribe su output en /tmp/dron_*_output.json, que el siguiente dron lee para obtener contexto.

Resultado: Backup de 1.3 GB transferido y restaurado en ~35-40 minutos total. Integridad verificada sin errores.

4.8 Fase 8b: Pipeline Diferencial (14 abril — COMPLETADO)

Se implementó un pipeline optimizado para refrescos diarios usando backups diferenciales:

Tamaño: ~0.4-10 MB vs 1.3 GB del completo (99% más pequeño)
Duración: ~5-10 minutos vs 35-40 minutos del completo
Comando: ./adn/tools/run bkps run dasuten_diferencial

Integración con bkps.rb:

dasuten_full — Pipeline completo (semanal, lunes 08:00)
dasuten_diferencial — Pipeline diferencial (diario, lun-vie 08:00)

Módulo común DasuExecutor: Para eliminar código repetido, se creó adn/tools/cli/drones/lib/dasu_executor.rb que centraliza:

Ejecución de PowerShell en dasu-sql4 vía SSH
Lectura de JSON output desde dasu-sql4
Verificación de archivos en fenix vía xp_cmdshell

Beneficio: -52% de líneas de código en los drones refactorizados.

5. Estado Actual

5.1 Funcionalidades operativas

Funcionalidad	Estado
Acceso al sistema DASUTEN	✅ Operativo
Consulta de datos (bonos, registros)	✅ Operativo
Conexión a base de datos SQL Server	✅ Operativo
Acceso remoto para soporte (Tailscale/SSH)	✅ Operativo
Impresión desde el sistema	✅ Resuelto (symlink)
Backups automatizados	✅ Pipeline implementado
Zona horaria del servidor	✅ UTC-3 Argentina (configurada 15/04/2026)
Validación del usuario	✅ Confirmada (Andrea Almirón, 15/04/2026 17:00)

5.2 Solución de Impresión

Descripción: El sistema DASUTEN (Visual FoxPro) genera documentos mediante OLE Automation con Word/Excel, usando plantillas en C:\Sistema\Word\ y C:\Sistema\Excel\. Sin embargo, el directorio del sistema está en C:\SysDasuten\Sistema\.

Solución: Symlink C:\Sistema → C:\SysDasuten\Sistema\

mklink /D C:\Sistema C:\SysDasuten\Sistema

Impacto: El ejecutable VFP encuentra las plantillas transparentemente sin necesidad de recompilar o modificar el binario.

5.3 Pipeline de Backups

Arquitectura implementada:

Tipo	Frecuencia	Tamaño	Duración	Comando
Completo	Semanal (lunes 08:00)	~1.3 GB	~35-40 min	`bkps run dasuten_full`
Diferencial	Diario (lun-vie 08:00)	~0.4-10 MB	~5-10 min	`bkps run dasuten_diferencial`

Drones atómicos (6 pasos):

Exportar (srvv-fenix) → Backup a X:\
Transferir (srv-ns8) → Copy a /var/tmp
Upload (srv-ns8) → rclone a Google Drive
Download (dasu-sql4) → Invoke-WebRequest
Restaurar (dasu-sql4) → RESTORE DATABASE
Verificar (dasu-sql4) → DBCC CHECKDB

6. Beneficios Obtenidos

Independencia operativa: DASUTEN ya no depende de la infraestructura de red ni de los servidores de la Facultad.
Simplificación: Se pasó de 3 VMs + Domain Controller a solo 1 VM (SQL Server), reduciendo significativamente la complejidad.
Reducción de puntos de falla: De múltiples (DC, DNS institucional, routing complejo) a uno solo (SQL Server).
Acceso remoto robusto: Gestión técnica asegurada vía VPN (Tailscale) y SSH, sin necesidad de presencia física.
Autonomía: La infraestructura puede ser gestionada independientemente, facilitando una eventual transferencia a Rectorado.
Preservación del entorno anterior: Las VMs del enfoque con DC fueron apagadas y preservadas como respaldo, permitiendo un rollback si fuera necesario.

7. Cronograma Resumen

Fecha	Hito
27/03/2026	Inicio — Preparación del entorno e inicio de pruebas de concepto
28/03/2026	VM SQL Server de prueba operativa
09-10/04/2026	Servidor SQL definitivo (dasu-sql4) desplegado y operativo
11/04/2026	Base de datos migrada, verificada y hardening completado
11/04/2026	Validación funcional exitosa en entorno virtual
13/04/2026	Despliegue en PC física de producción
14/04/2026	Impresión resuelta (symlink) + Pipeline de backups implementado
15/04/2026 16:30	Migración final + Zona horaria corregida (UTC-3 Argentina)
15/04/2026 17:00	Validación usuaria: datos actualizados visibles en sistema desktop

8. Próximos Pasos

Prioridad	Acción	Plazo estimado
✅	Impresión resuelta (symlink `C:\Sistema`)	Completado 14/04/2026
✅	Pipeline de backups implementado	Completado 14/04/2026
✅	Zona horaria corregida (UTC-3 Argentina)	Completado 15/04/2026
✅	Validación del usuario confirmada (datos actualizados)	Completado 15/04/2026
🟡 Media	Reservar IPs fijas en router ISP (prevenir cambios por DHCP)	1 semana
🟢 Baja	Evaluar apagado definitivo de VMs legacy (DC, SQL antiguo)	Tras validación completa
🟢 Baja	Ejecutar backups diferenciales diarios (lun-vie 08:00)	En operación

9. Conclusión

La migración del sistema DASUTEN a la nueva infraestructura se encuentra 100% completada y validada, con el sistema totalmente operativo y todas las funcionalidades verificadas incluyendo impresión de documentos.

El enfoque sin Domain Controller demostró ser completamente viable, logrando una reducción significativa de la complejidad y de los puntos de falla:

De 4 componentes (DC + SQL + PC virtual + PC física) a 2 (SQL + PC física)
De red privada compleja con routing a red plana DHCP del ISP
De autenticación Kerberos a SQL Auth mixta

Adicionalmente, se implementó un pipeline automatizado de backups con arquitectura de drones atómicos que permite:

Refrescos semanales completos (~1.3 GB, 35-40 min)
Refrescos diarios diferenciales (~0.4-10 MB, 5-10 min)
Integración con el ecosistema ADN de herramientas (bkps.rb)

Hallazgo crítico (15/04/2026): La zona horaria incorrecta en dasu-sql4 ("Romance Standard Time" UTC+2 en lugar de "Argentina Standard Time" UTC-3) era la causa principal de que los datos se vieran "desactualizados". Los backups se realizaban correctamente, pero las fechas se interpretaban con ~5 horas de desplazamiento. Tras la corrección, la usuaria Andrea Almirón confirmó el correcto funcionamiento del sistema.

El proyecto generó además herramientas reutilizables (DasuExecutor, drones atómicos, módulo de comunicación JSON) que quedan como activo de DTIC para futuros proyectos.

ANEXO TÉCNICO

A. Inventario de Nodos

A.1 Servidor Hipervisor: srv-dasu

Campo	Valor
Rol	Hipervisor Proxmox VE 9.1
IP LAN	192.168.1.13 (DHCP ISP)
IP VPN	100.112.46.104 (Tailscale)
Bridge	vmbr0 sobre enp33s0
RAM	15 GB total / ~4 GB libre post-VMs
Disco	94 GB (68% uso, thin provisioned)
Acceso remoto	Tailscale + SSH

A.2 Servidor SQL: dasu-sql4 (VM 106)

Campo	Valor
Rol	SQL Server 2019 Enterprise
SO	Windows Server 2022 (Español)
IP LAN	192.168.1.11 (DHCP ISP)
IP VPN	100.107.15.82 (Tailscale — inestable)
Workgroup	DASUTEN
Zona Horaria	Argentina Standard Time (UTC-3) — configurada 15/04/2026
RAM	4 GB
vCPU	2
Disco 1 (sata0)	60 GB — Sistema Operativo
Disco 2 (sata1)	120 GB — Datos SQL (GPT/NTFS "SQLData")
Estructura SQL	F:\DATA, F:\LOG, F:\BACKUP, F:\TEMPDB
Autenticación	Mixta (SQL Auth + Windows)
Puerto SQL	TCP 1433
SSH	Puerto 7022 (OpenSSH Server, arranque automático)
Servicios auto-start	MSSQLSERVER, sshd

A.3 PC Física Cliente: dasu-pc

Campo	Valor
Rol	Estación de trabajo DASUTEN
Patrimonio	32120
Ubicación	Oficina DASUTEN (externa a Facultad)
SO	Windows 10 Pro
Workgroup	DASUTEN
IP VPN	100.119.233.11 (Tailscale)
SSH	UTNLR@100.119.233.11:7022
CPU	AMD Ryzen 5 4600G @ 4.30GHz (6 núcleos)
RAM	8 GB DDR4-3200
Placa Base	Asus Prime A320M-K
Usuarias	Andrea Almirón (`aalmiron`), Romina Molina (`rmolina`)
Directorio DASUTEN	C:\SysDasuten
Config conexión	C:\SysDasuten\Sistema\Kermet.ini

A.4 VM Cliente de Pruebas: dasu-pcv (VM 107) — Test-Bed

Campo	Valor
Rol	Entorno de pruebas / fallback temporal
SO	Windows 10
Workgroup	DASUTEN
SSH	Puerto 7022
Estado	Operativa (usada como fallback vía TeamViewer)

B. Configuración del Sistema DASUTEN

B.1 Archivo de conexión: Kermet.ini

Parámetros clave configurados para la operación sin Domain Controller:

SERVER=dasu-sql4
DATABASE=sysdasuten
UID=sa
PWD=[credencial almacenada en bóveda]

Nota técnica: El campo UID debe estar explícitamente configurado con sa (u otra cuenta SQL Auth). Si se deja vacío, el sistema DASUTEN (Visual FoxPro) asume autenticación Windows integrada (SSPI/Kerberos), lo cual falla en entorno Workgroup sin Domain Controller.

B.2 Directorio del sistema

C:\SysDasuten\
├── Sistema\           → Ejecutables VFP + Kermet.ini
├── Plantillas\        → Templates Word/Excel para impresión
└── [otros directorios de la aplicación]

C. Base de Datos: sysdasuten

Campo	Valor
Nombre	sysdasuten
Motor	SQL Server 2019 Enterprise
Tamaño backup comprimido	~1.33 GB
Nivel de compatibilidad	100
Recovery model	FULL
Integridad (DBCC CHECKDB)	✅ Sin errores
Tiempo de restauración	26 segundos (354 MB/s)
Origen de datos	srvv-fenix (servidor legacy de Facultad)
Último refresco	13/04/2026

C.1 Ruta de transferencia del backup (LEGACY — reemplazado por pipeline)

srvv-fenix (Origen)
  │  [BACKUP DATABASE ... WITH COMPRESSION]
  │  → E:\BK_SQL\sysdasuten_compressed_ADN.bak (~1.33 GB)
  ↓
srv-ns8 (Tránsito)
  │  [SMB/smbget vía dominio]
  │  → /var/tmp/
  ↓
srv-dasu (Tránsito)
  │  [SCP vía Tailscale]
  ↓
dasu-sql4 (Destino)
  │  [RESTORE DATABASE ... WITH REPLACE]
  └  → F:\BACKUP\ → F:\DATA\ + F:\LOG\

G. Pipeline de Backups (NUEVO — 2026-04-14)

G.1 Arquitectura de Drones Atómicos

El pipeline de backups está compuesto por 6 drones atómicos que se ejecutan secuencialmente, comunicándose entre sí mediante archivos JSON.

Dron	Script	Nodo	Función	Output JSON
1	`dasuten_exportar_srvv-fenix.rb`	srvv-fenix	BACKUP DATABASE TO X:\	`/tmp/dron_export_output.json`
2	`dasuten_transferir_srvv-fenix-srv-ns8.rb`	srv-ns8	Copy X:\ → /var/tmp	`/tmp/dron_transfer_output.json`
3	`dasuten_upload_srv-ns8-drive.rb`	srv-ns8	rclone → Google Drive	`/tmp/dron_upload_output.json`
4	`dasuten_download_drive-dasu-sql4.rb`	dasu-sql4	Invoke-WebRequest ← Drive	`/tmp/dron_download_output.json`
5	`dasuten_restaurar_dasu-sql4.rb`	dasu-sql4	RESTORE DATABASE	`/tmp/dron_restore_output.json`
6	`dasuten_verificar-integridad_dasu-sql4.rb`	dasu-sql4	DBCC CHECKDB	`/tmp/dron_verify_output.json`

G.2 Flujo Completo (Semanal)

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
    ↓ DBCC CHECKDB
✅ VERIFICADO

Duración total: ~35-40 minutos

G.3 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
    ↓ DBCC CHECKDB
✅ VERIFICADO

Duración total: ~5-10 minutos

G.4 Comando de Ejecución

# Pipeline completo (semanal - lunes 08:00)
./adn/tools/run bkps run dasuten_full

# Pipeline diferencial (diario - lun-vie 08:00)
./adn/tools/run bkps run dasuten_diferencial

G.5 Módulo Común: DasuExecutor

Para eliminar código repetido, se creó el módulo adn/tools/cli/drones/lib/dasu_executor.rb que centraliza:

Función	Propósito
`execute_ps_on_dasu(ps_script)`	Ejecuta PowerShell en dasu-sql4 vía SSH
`read_json_from_dasu(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 existencia de archivo en fenix
`get_file_info_on_fenix(client, path)`	Obtiene tamaño y existencia de archivo