VDI para SQL Server: copia de seguridad sin archivos .bak | Guía

Integración VDI: Copias de seguridad de MS SQL sin archivos .bak

Los comandos estándar BACKUP DATABASE en MS SQL Server están limitados al almacenamiento en disco local. Para la integración con sistemas de copia de seguridad externos, se requiere VDI: una interfaz que permite interceptar el flujo de datos directamente desde SQL Server. Desglosamos la implementación del cliente VDI en el proyecto «Beresta», que proporciona un ciclo completo de copia de seguridad y restauración sin archivos .bak intermedios.

Por qué se necesita VDI en los sistemas de copia de seguridad modernos

Los mecanismos de copia de seguridad estándar de SQL Server mediante TO DISK no satisfacen las necesidades de los sistemas externos de protección de datos. Cuando se requiere gestión del ciclo de vida de trabajos, enrutamiento de datos, paralelismo o integración con almacenamiento de objetos, surge la necesidad de una capa intermedia. VDI (Virtual Device Interface) actúa como tal puente: SQL Server continúa ejecutando comandos estándar BACKUP y RESTORE, pero en lugar de archivos físicos, trabaja con dispositivos virtuales gestionados por una aplicación externa.

Ventajas clave del enfoque VDI:

• Control total sobre el flujo de datos: escritura directa a almacenamiento en la nube o servidor de medios
• Independencia del sistema de archivos de SQL Server
• Soporte para operaciones estriadas para aumentar el rendimiento
• Punto único para el manejo de errores y registro
• Cumplimiento de los requisitos de los sistemas de copia de seguridad empresariales para la gestión de políticas de almacenamiento

A diferencia de soluciones simplificadas, el proyecto «Beresta» implementa VDI como un adaptador de transporte completo entre SQL Server y el backend de almacenamiento, manteniendo compatibilidad con versiones desde 2008 hasta 2022.

Arquitectura del cliente VDI: De la preparación a la ejecución

La implementación se divide en dos etapas lógicas. En la etapa de preparación se validan los parámetros, se establece la conexión a SQL Server mediante ODBC y se forma un conjunto de tareas. Es críticamente importante que el proyecto soporte múltiples controladores ODBC (incluidos los actuales Driver 17/18), lo que aumenta la compatibilidad en entornos heterogéneos.

Durante la ejecución, se activa el flujo VDI:

• Inicialización COM mediante CoInitializeEx
• Creación del objeto IClientVirtualDeviceSet2
• Generación de GUID para dispositivos virtuales
• Configuración de parámetros VDConfig (tamaño de bloque, tiempo de espera, profundidad de búfer)
• Publicación del dispositivo mediante CreateEx
• Ejecución del comando T-SQL especificando VIRTUAL_DEVICE
• Procesamiento de datos en hilos de trabajo

El componente central es transferThreadProc, que implementa la lógica de intercambio con SQL Server:

while (true) {
    VDC_Command* command;
    device->GetCommand(&command);
    
    switch (command->dwCommandCode) {
        case VDC_Write:
            WriteToFile(command->pvBuffer, command->dwByteCount);
            break;
        case VDC_Read:
            ReadFromFile(command->pvBuffer, command->dwByteCount);
            break;
        case VDC_Flush:
            FlushBuffer();
            break;
    }
    device->CompleteCommand(command, S_OK);
}

Este bucle asegura una interacción síncrona: SQL Server actúa como productor de datos en bloques, mientras que el cliente VDI actúa como consumidor, redirigiendo los datos al almacenamiento de destino.

Paralelismo y gestión del rendimiento

El procesamiento monohilo es un cuello de botella para cargas empresariales. El proyecto aborda esto mediante copia de seguridad/restauración estriada, donde cada estría es manejada por un hilo separado. Especificar el parámetro --stripes=N crea archivos como:

db_full_20260412_101530_s0.bak
db_full_20260412_101530_s1.bak
...

Esta aproximación ofrece tres beneficios:

• Distribución de la carga E/S a través de discos o canales de red
• Escalabilidad lineal del rendimiento
• Alineación con la arquitectura de sistemas de copia de seguridad industriales con múltiples flujos

Parámetros clave que afectan el rendimiento:

• blockSize: tamaño de bloque óptimo para el almacenamiento de destino
• maxTransferSize: tamaño máximo del paquete transferible
• buffersPerStripe: profundidad de búfer por hilo
• vdiTimeoutSec: tiempo de espera para operaciones E/S

Experimentos con estos parámetros permiten adaptar la solución a las características específicas de la infraestructura, desde SSD locales hasta almacenamiento en red lento.

Cadenas de restauración: De completa a registro

El proyecto soporta el ciclo completo de restauración, incluyendo diferenciales y registros de transacciones. El manejo correcto de la cadena es críticamente importante:

• Para copias de seguridad diferenciales, se selecciona automáticamente la última copia completa con la misma marca de tiempo
• La restauración completa se realiza con WITH NORECOVERY, seguida de diferencial con WITH RECOVERY
• Las copias de seguridad de registro solo se permiten para bases de datos en modelos de recuperación FULL/BULK_LOGGED
• La base de datos master está excluida de operaciones diferenciales (limitación de SQL Server)

El mecanismo de descubrimiento de conjuntos usa la convención de nomenclatura:

{db}_{type}_{timestamp}_s{n}.bak

Las funciones de escaneo de directorios construyen cadenas de restauración basadas en marcas de tiempo. Para restauración completa, se selecciona el conjunto más reciente; para diferencial, solo aquellos con archivos full y diff coincidentes. El número de estrías se determina por el índice sN más alto en los nombres de archivos.

Antes de la restauración, la base de datos se cambia obligatoriamente a modo de usuario único:

ALTER DATABASE [db] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Esto previene conflictos con conexiones activas. Tras una restauración exitosa, la base de datos se devuelve al modo MULTI_USER.

Puntos clave

• VDI elimina la dependencia del sistema de archivos de SQL Server, redirigiendo el flujo de datos a cualquier almacenamiento de destino
• Soporte para escenarios full/diff/log con construcción automática de cadenas de restauración
• Procesamiento paralelo mediante arquitectura estriada asegura escalabilidad lineal del rendimiento
• Compatibilidad con SQL Server 2008-2022 sin vinculación a un controlador ODBC específico
• La implementación tiene en cuenta particularidades de SQL Server (p. ej., limitaciones de la base de datos master)

El proyecto «Beresta» muestra cómo incluso una implementación relativamente compacta de un cliente VDI puede cumplir los requisitos clave de sistemas de copia de seguridad empresariales. El enfoque en el ciclo completo de operaciones (incluido el manejo de errores y la gestión del estado de la base de datos) lo hace apto para producción. La arquitectura está abierta a la integración con cualquier backend de almacenamiento, desde discos locales hasta almacenamiento de objetos en la nube, lo cual es especialmente relevante en entornos IT híbridos.

— Editorial Team