VDI pour SQL Server : sauvegarde sans fichiers .bak | Guide

## Intégration VDI : Création de sauvegardes MS SQL sans fichiers .bak

Les commandes BACKUP DATABASE standard dans MS SQL Server sont limitées au stockage sur disque local. Pour l'intégration avec des systèmes de sauvegarde externes, VDI est requis — une interface qui permet d'intercepter le flux de données directement depuis SQL Server. Nous décomposons l'implémentation du client VDI dans le projet « Beresta », qui fournit un cycle complet de sauvegarde et de restauration sans fichiers .bak intermédiaires.

Pourquoi VDI est nécessaire dans les systèmes de sauvegarde modernes

Les mécanismes de sauvegarde standard de SQL Server via TO DISK ne répondent pas aux besoins des systèmes de protection de données externes. Lorsque la gestion du cycle de vie des tâches, le routage des données, le parallélisme ou l'intégration avec un stockage objet sont requis, le besoin d'une couche intermédiaire apparaît. VDI (Virtual Device Interface) sert de pont : SQL Server continue d'exécuter les commandes BACKUP et RESTORE standard, mais au lieu de fichiers physiques, il travaille avec des périphériques virtuels gérés par une application externe.

Avantages clés de l'approche VDI :

• Contrôle total sur le flux de données — écriture directe vers le stockage cloud ou le serveur média
• Indépendance du système de fichiers de SQL Server
• Support des opérations en bandes pour booster le débit
• Point unique pour la gestion des erreurs et la journalisation
• Conformité aux exigences des systèmes de sauvegarde d'entreprise pour la gestion des politiques de stockage

Contrairement aux solutions simplifiées, le projet « Beresta » implémente VDI comme un adaptateur de transport complet entre SQL Server et le backend de stockage, en conservant la compatibilité avec les versions de 2008 à 2022.

Architecture du client VDI : De la préparation à l'exécution

L'implémentation est divisée en deux étapes logiques. Lors de l'étape de préparation, les paramètres sont validés, la connexion à SQL Server s'effectue via ODBC et un ensemble de tâches est formé. Il est crucial que le projet supporte plusieurs pilotes ODBC (y compris les pilotes actuels Driver 17/18), ce qui renforce la compatibilité dans des environnements hétérogènes.

Lors de l'exécution, le flux VDI est activé :

• Initialisation COM via CoInitializeEx
• Création de l'objet IClientVirtualDeviceSet2
• Génération de GUID pour les périphériques virtuels
• Configuration des paramètres VDConfig (taille de bloc, délai d'attente, profondeur de tampon)
• Publication du périphérique via CreateEx
• Lancement de la commande T-SQL en spécifiant VIRTUAL_DEVICE
• Traitement des données dans des threads workers

Le composant central est transferThreadProc, qui implémente la logique d'échange avec 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);
}

Cette boucle assure une interaction synchrone : SQL Server agit comme le producteur de données en blocs, tandis que le client VDI agit comme le consommateur, en redirigeant les données vers le stockage cible.

Parallélisme et gestion des performances

Le traitement mono-thread constitue un goulot d'étranglement pour les charges d'entreprise. Le projet y remédie grâce à la sauvegarde/restauration en bandes, où chaque bande est gérée par un thread séparé. L'indication du paramètre --stripes=N crée des fichiers comme :

db_full_20260412_101530_s0.bak
db_full_20260412_101530_s1.bak
...

Cette approche offre trois avantages :

• Distribution de la charge E/S sur les disques ou les canaux réseau
• Évolutivité linéaire du débit
• Alignement avec l'architecture des systèmes de sauvegarde industriels dotés de flux multiples

Paramètres clés influençant les performances :

• blockSize — taille de bloc optimale pour le stockage cible
• maxTransferSize — taille maximale du paquet transférable
• buffersPerStripe — profondeur de tampon par thread
• vdiTimeoutSec — délai d'attente pour les opérations E/S

Les expérimentations avec ces paramètres permettent d'adapter la solution aux caractéristiques spécifiques de l'infrastructure — des SSD locaux au stockage réseau lent.

Restauration des chaînes : De la complète au journal

Le projet supporte le cycle complet de restauration, y compris les différentielles et les journaux de transactions. La gestion correcte des chaînes est cruciale :

• Pour les sauvegardes différentielles, la dernière sauvegarde complète portant le même horodatage est sélectionnée automatiquement
• La restauration complète s'effectue avec WITH NORECOVERY, suivie de la différentielle avec WITH RECOVERY
• Les sauvegardes de journaux ne sont autorisées que pour les bases de données en modèles de récupération FULL/BULK_LOGGED
• La base de données master est exclue des opérations différentielles (limitation de SQL Server)

Le mécanisme de découverte des ensembles utilise la convention de nommage :

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

Les fonctions de scan de répertoire construisent les chaînes de restauration en se basant sur les horodatages. Pour une restauration complète, l'ensemble le plus récent est sélectionné ; pour une différentielle, seuls ceux avec des fichiers full et diff correspondants. Le nombre de bandes est déterminé par l'indice sN le plus élevé dans les noms de fichiers.

Avant la restauration, la base de données est obligatoirement passée en mode mono-utilisateur :

ALTER DATABASE [db] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Cela évite les conflits avec les connexions actives. Après une restauration réussie, la base de données est remise en mode MULTI_USER.

Points clés

• VDI élimine la dépendance au système de fichiers de SQL Server, en redirigeant le flux de données vers n'importe quel stockage cible
• Support des scénarios full/diff/log avec construction automatique des chaînes de restauration
• Traitement parallèle via l'architecture en bandes assure une évolutivité linéaire du débit
• Compatibilité avec SQL Server 2008-2022 sans liaison à un pilote ODBC spécifique
• L'implémentation tient compte des spécificités de SQL Server (par ex., limitations de la base master)

Le projet « Beresta » montre comment une implémentation relativement compacte de client VDI peut satisfaire les exigences clés des systèmes de sauvegarde d'entreprise. L'accent mis sur le cycle complet des opérations (y compris la gestion des erreurs et des états de base de données) le rend prêt pour la production. L'architecture est ouverte à l'intégration avec n'importe quel backend de stockage — des disques locaux au stockage objet cloud —, ce qui est particulièrement pertinent dans les environnements IT hybrides.

— Editorial Team