Récupération SQL Server : bonnes pratiques en matière de restauration de bases de données

La définition d'une restauration réussie selon un administrateur de base de données

Un administrateur de base de données avec lequel j'ai travaillé m'a un jour donné sa définition d'une restauration réussie : « La base de données est opérationnelle, l'application peut l'interroger, et je n'ai pas eu besoin de faire appel au service d'assistance du fournisseur de solutions de sauvegarde pour y parvenir. » C’est un niveau d’exigence que la plupart des démonstrations des fournisseurs ne parviennent pas à atteindre.

Le fossé entre ce que les fournisseurs de solutions de sauvegarde appellent la « restauration de SQL Server » et ce dont les administrateurs de bases de données ont réellement besoin est l’un des décalages les plus anciens de notre secteur. Les fournisseurs parlent de fichiers de sauvegarde. Les administrateurs de bases de données ont besoin d’une base de données utilisable capable de répondre aux requêtes, avec l’état de récupération approprié, les métadonnées de l’application et la configuration de l’instance. Ce ne sont pas les mêmes choses, et cette différence est d’autant plus cruciale lorsque vous effectuez une restauration dans l’urgence.

Cet article présente ce que je dirais à un collègue qui me demanderait comment envisager la récupération de SQL Server en 2026, en m’appuyant sur l’expérience des équipes que j’ai vues réussir et sur les erreurs qui, d’après ce que j’ai pu constater, ont coûté des semaines de travail. 

Sauvegarde, restauration, reprise : trois termes, trois concepts

La sauvegarde consiste à capturer une copie de la base de données à un instant donné. Sauvegarde complète, différentielle, du journal des transactions ou d’un groupe de fichiers.

La restauration consiste à réécrire une sauvegarde sur une instance SQL Server, à appliquer la chaîne de sauvegardes appropriée et à remettre la base de données en ligne.

La reprise est le résultat opérationnel. La base de données est en ligne, cohérente sur le plan transactionnel et traite correctement les requêtes. La sauvegarde et la restauration sont des mécanismes. La reprise est le résultat.

Une sauvegarde qui existe mais qui ne peut pas être restaurée n’est pas une sauvegarde. Une restauration qui s’achève mais qui rend la base de données inutilisable n’est pas une reprise. Les administrateurs de bases de données SQL Server font soigneusement la distinction entre ces concepts, car cette différence correspond à celle entre un incident résolu et une interruption prolongée. 

Les modèles de récupération et ce qu’ils permettent

SQL Server dispose de trois modèles de récupération. Ce choix détermine les options de restauration disponibles. Un mauvais choix est l’une des causes les plus courantes des discussions du type « nous ne pouvons en réalité pas récupérer les données à ce moment précis ». 

Les bases de données de production présentant une activité transactionnelle importante fonctionnent généralement en mode « Full ». Les bases de données de reporting, qui peuvent tolérer des pertes de données plus importantes, fonctionnent souvent en mode « Simple ». Le modèle de récupération est défini par base de données, et non par instance. Vérifiez-le explicitement sur chaque base de données de production, car la valeur par défaut du modèle de base de données dépend de l’édition de SQL Server et des choix d’installation. 

Les quatre scénarios de restauration auxquels les administrateurs de bases de données sont réellement confrontés

La plupart des restaurations de bases de données SQL Server en production s’inscrivent dans l’un de ces quatre scénarios. Être prêt pour la restauration signifie disposer d’une procédure testée pour chacun d’entre eux.

Restauration complète de la base de données sur l’instance d’origine

Le cas le plus simple. Une base de données doit être restaurée sur la même instance que celle à partir de laquelle elle a été sauvegardée, généralement pour remédier à une corruption, à une attaque par ransomware ou à une perte importante de données. La chaîne de restauration comprend la sauvegarde complète, la sauvegarde différentielle la plus récente ainsi que toutes les sauvegardes de journaux de transactions ultérieures. Si la source est récupérable, effectuez d’abord une sauvegarde de la fin du journal (tail-log) afin de minimiser la perte de données. 

Restauration à un instant donné (PITR)

Une commande TRUNCATE TABLE accidentelle sur la mauvaise base de données, un déploiement défectueux ayant exécuté un script destructeur ou un événement de chiffrement par ransomware. Ces situations nécessitent une restauration à un moment précis, et non simplement à la dernière sauvegarde complète. La PITR nécessite un modèle de récupération « complet » ou « avec journalisation en bloc » et une chaîne de journaux de transactions intacte remontant jusqu’au point de récupération. La raison pour laquelle la plupart des organisations ne parviennent pas à se restaurer au moment souhaité n’est pas due à une lacune dans les sauvegardes. Il s’agit d’une chaîne de journaux rompue ou d’une base de données laissée accidentellement en mode de récupération « Simple ».

Restauration vers une autre instance SQL Server

Nécessaire lorsque l’instance d’origine est indisponible en raison d’une panne matérielle ou d’une compromission de l’infrastructure, ou lorsque les administrateurs de bases de données doivent restaurer une base de données dans un environnement parallèle sans perturber la production. La cible peut être une autre instance sur le même serveur (DEV, UAT, PROD) ou un autre serveur physique. Les identifiants de connexion, les tâches et les objets au niveau de l’instance ne font pas partie des sauvegardes de base de données et doivent être traités séparément.

Restauration vers un environnement différent à des fins de développement, de test ou d’analyse forensic

Les données de production doivent être transférées vers des environnements de niveau inférieur à des fins de développement, de test ou d’analyse forensic après un incident. La destination est délibérément séparée de l’environnement de production : serveur différent, réseau différent, avec souvent un masquage des données à caractère personnel appliqué après la restauration. Les fonctionnalités de clonage qui créent des copies cohérentes au niveau de l’application des données de production sans perturber la source constituent la bonne approche.

Pourquoi la sauvegarde au niveau de la machine virtuelle n’équivaut pas à une restauration de base de données

La plupart des outils génériques de sauvegarde de machines virtuelles vantent la protection de SQL Server. Ce qu’ils fournissent en réalité, c’est une sauvegarde au niveau de la machine virtuelle avec des instantanés cohérents en cas de panne ou coordonnés par VSS, ainsi qu’un ensemble de solutions de contournement pour la restauration. Les plus courantes sont les suivantes :

« Nous proposons une restauration instantanée de la machine virtuelle à partir des données de sauvegarde ; il vous suffit de démarrer votre machine virtuelle SQL et d’utiliser les données comme bon vous semble. » 

« Nous pouvons partager vos fichiers de base de données via SMB à partir de la cible de sauvegarde ; vous pouvez ainsi les monter et les utiliser comme bon vous semble. »

Ces deux solutions vous donnent accès aux données. Aucune ne permet de restaurer une base de données. Le montage d’une paire de fichiers .mdf et .ldf sur une instance SQL Server peut fonctionner dans certains cas de figure, mais cela n’équivaut pas à une restauration correcte de la base de données avec la chaîne de sauvegarde, l’état de récupération et les métadonnées d’application appropriés. Il existe une distinction utile : c’est la différence entre trouver les données et les sauvegarder. Entre rendre les fichiers accessibles et ramener la base de données intacte pour qu’elle puisse répondre aux requêtes.

La sauvegarde « application-aware » comprend SQL Server. Elle sait quelles bases de données résident sur quelle machine virtuelle, quel modèle de récupération chacune utilise, comment se coordonner avec le VSS Writer de SQL Server pour obtenir des instantanés cohérents avec l’application, et comment restaurer sur la bonne instance avec l’état correct de la base de données. La différence architecturale se manifeste dans la complexité de la restauration. Les outils adaptés aux applications vous fournissent une base de données. Les outils adaptés aux machines virtuelles vous fournissent des fichiers.

Six pratiques qui distinguent une restauration fiable de la simple détection d’incidents

Après avoir observé suffisamment de restaurations SQL Server, on constate que ces six mêmes pratiques reviennent systématiquement dans toutes les équipes qui parviennent à effectuer des restaurations sans faille, même sous pression. Elles n’ont rien d’exceptionnel. Elles sont simplement appliquées de manière cohérente.

Configurez chaque base de données de production sur le modèle de récupération « complet », sauf si vous avez une raison spécifique de ne pas le faire. Le modèle de récupération « simple » exclut la récupération à un instant donné (PITR). Si une base de données n’a véritablement pas besoin de la PITR, documentez cette décision. Ne laissez pas cela être le fruit du hasard.

Effectuez des sauvegardes du journal des transactions à la fréquence réellement requise par votre RPO. Des sauvegardes toutes les 15 minutes sont courantes pour les systèmes de niveau 1. Une heure constitue le minimum pour la plupart des bases de données de production. C’est la chaîne de journaux qui permet la restauration à un instant donné (PITR).

Vérifiez les sauvegardes à l’aide de la commande RESTORE VERIFYONLY ou d’une vérification équivalente sur votre plateforme. Une sauvegarde qui ne peut pas être restaurée n’offre aucune protection. La vérification permet de détecter les corruptions, les fichiers manquants et les chaînes brisées avant qu’ils n’entraînent des échecs de restauration. 

Effectuez une sauvegarde de la fin du journal avant la restauration lorsque la source est accessible. Si les fichiers de base de données d’origine sont encore lisibles, la capture de la fin du journal avant la restauration réduit la perte de données à quelques secondes.

Utilisez des instantanés cohérents au niveau de l’application, et non des instantanés cohérents en cas de panne. Les sauvegardes cohérentes au niveau de l’application s’effectuent en coordination avec le VSS Writer de SQL Server, mettent correctement la base de données en état de repos et garantissent que l’instantané est pris à un moment cohérent au niveau des transactions. Les sauvegardes cohérentes en cas de panne nécessitent un effort de récupération après la restauration et peuvent échouer purement et simplement pour les bases de données actives.

Testez les restaurations tous les trimestres sur une instance ou un serveur différent. Tester l’intégrité d’une sauvegarde n’est pas la même chose que tester la restauration. La seule façon de savoir si la récupération fonctionne est de la mettre en œuvre, idéalement en restaurant une base de données de production dans un environnement hors production selon un calendrier défini. Suivez le temps de restauration comme indicateur clé.

Avec ou sans agent : le compromis architectural

Les architectures de sauvegarde SQL Server traditionnelles installaient un agent sur chaque serveur protégé. L’agent gérait la sauvegarde spécifique à SQL, la coordination VSS et l’orchestration de la restauration. Cela fonctionnait, mais cela représentait une charge opérationnelle. Les agents devaient être installés, mis à jour, corrigés et dépannés sur chaque serveur protégé. Dans les environnements comptant des centaines de machines virtuelles SQL, la maintenance des agents devient un véritable coût récurrent. Un agent obsolète constitue une faille dont personne n’a connaissance. 

Les architectures sans agent gèrent la sauvegarde et la restauration de SQL Server via des API au niveau de l’hyperviseur et l’intégration à la plateforme, sans qu’aucun logiciel ne soit installé sur les machines virtuelles protégées. L’avantage réside dans la simplicité opérationnelle à grande échelle. Rien à installer, rien à mettre à jour, rien qui puisse tomber en panne lors d’un « Patch Tuesday ». Le défi des approches sans agent a toujours été la prise en compte des applications. Une sauvegarde pure au niveau de la machine virtuelle ne tient pas compte des applications et se rabat sur les solutions de contournement que j’ai décrites précédemment.

Les plateformes modernes sans agent résolvent ce problème en s’intégrant directement aux API de l’hyperviseur et du stockage, en se coordonnant avec le VSS Writer de SQL Server pour assurer la cohérence des applications, et en conservant une prise en charge au niveau de la base de données sans aucun logiciel sur la machine virtuelle SQL Server elle-même. Il en résulte une sauvegarde et une restauration tenant compte de SQL, avec une restauration à un instant donné, une restauration vers une autre instance et une restauration vers un autre serveur, sans aucun agent à gérer.

Tester vos procédures de restauration

La cause la plus fréquente d’échec de la restauration de SQL Server n’est pas une défaillance de la sauvegarde. Il s’agit d’une défaillance de la procédure. La tâche de sauvegarde s’était exécutée avec succès chaque nuit pendant deux ans, mais personne n’avait en réalité exécuté la procédure de restauration documentée de bout en bout. Lorsque l’incident s’est produit, les étapes étaient erronées, les dépendances faisaient défaut ou la cible de restauration n’était pas dimensionnée pour la charge de travail.

Un programme de test de restauration de SQL Server efficace comporte trois éléments. Des tests de restauration planifiés des bases de données de production vers un environnement hors production, au moins une fois par trimestre et une fois par mois pour les systèmes de niveau 1. Des indicateurs de temps de restauration suivis de près, qui alimentent la planification du RTO. Et des exercices sur table ou en conditions réelles incluant les étapes humaines : voies d’escalade, communication, prise de décision. Pas seulement la restauration technique.

Si votre équipe ne peut pas vous indiquer avec certitude combien de temps prend la restauration complète de votre plus grande base de données de production, votre RTO reste théorique. Le moyen le plus rapide de le savoir est de le faire.

Questions courantes sur la reprise après sinistre de SQL Server

Quelle est la différence entre la sauvegarde SQL Server et la reprise après sinistre SQL Server ?

La sauvegarde consiste à capturer une copie. La restauration consiste à réécrire cette copie. La récupération correspond à l’état final où la base de données est utilisable et interrogeable. Une sauvegarde réussie qui ne peut pas être restaurée en une base de données utilisable ne constitue pas une protection.

Puis-je effectuer une récupération à un instant donné avec n’importe quel outil de sauvegarde ? 

Non. La restauration à un instant donné (PITR) nécessite que la base de données soit en mode de récupération « Full » ou « Bulk-Logged », une chaîne intacte de sauvegardes du journal des transactions couvrant la fenêtre de récupération souhaitée, ainsi qu’un outil de sauvegarde capable d’appliquer cette chaîne. Les instantanés de machine virtuelle cohérents en cas de panne vous fournissent l’état au moment de l’instantané, et non à des moments arbitraires entre deux instantanés. 

Dois-je installer un agent sur chaque serveur SQL Server pour le sauvegarder ?

Non, pas avec les plateformes modernes sans agent. Les architectures sans agent communiquent avec le VSS Writer de SQL Server via les API de l’hyperviseur et du stockage, offrant ainsi une sauvegarde tenant compte des applications et une restauration au niveau de la base de données sans logiciel sur les machines virtuelles protégées. 

Puis-je restaurer une base de données SQL Server sur un autre serveur ou une autre instance ?

Oui, avec l’outil adapté. Les sauvegardes de bases de données sont portables d’une instance à l’autre et d’un serveur à l’autre. Les objets au niveau de l’instance (identifiants de connexion, tâches, serveurs liés) ne font pas partie des sauvegardes de bases de données et doivent être migrés séparément. 

Essayez-le dans votre environnement

HYCU propose une sauvegarde SQL Server sans agent et adaptée aux applications sur Nutanix AHV, VMware ESXi et Nutanix-on-VMware. Restauration à un instant donné, restauration vers d’autres instances ou serveurs, et clonage à des fins de développement ou de test, le tout sans agent sur les machines virtuelles protégées. La version d'essai est disponible à l'adresse hycu.com/trial.