Applications de sauvegarde SQL Server - Service VSS (Volume Shadow Copy Service) et Sql Writer

S’applique à :SQL Server sur Windows

SQL Server assure une prise en charge du service de cliché instantané (VSS, Volume Shadow Copy Service) en fournissant un enregistreur (SQL Writer) afin qu’une application de sauvegarde tierce puisse utiliser le framework VSS pour sauvegarder des fichiers de base de données. Ce document décrit le composant SQL Writer et son rôle dans le processus de création et de restauration des instantanés VSS pour les bases de données SQL Server. Il contient également des détails sur la configuration et l’utilisation de l’enregistreur SQL pour interagir avec des applications de sauvegarde dans le framework VSS.

Infrastructure de VSS

VSS fournit l’infrastructure système permettant d’exécuter des applications VSS sur des systèmes Windows. Bien qu’il soit largement transparent pour les utilisateurs et les développeurs, VSS effectue les opérations suivantes :

• Il coordonne les activités des fournisseurs, des enregistreurs et des demandeurs lors de la création et de l’utilisation des clichés instantanés.
• Il apporte le fournisseur système par défaut.
• Il implémente la fonctionnalité de pilote de bas niveau nécessaire au fonctionnement des fournisseurs.

Le service VSS démarre à la demande, ce service doit donc être activé pour que les opérations VSS réussissent.

Composants VSS

VSS coordonne les activités des composants coopérants suivants :

• Les fournisseurs sont propriétaires des données de cliché instantané et instancient les clichés instantanés.

• Les enregistreurs sont des applications qui modifient les données et qui participent au processus de synchronisation des clichés instantanés.

• Les demandeurs lancent la création et la destruction des clichés instantanés. La conception est axée sur le scénario dans lequel le demandeur est une application de sauvegarde.

VSS fournit la coordination entre ces parties :

Ce diagramme montre tous les composants qui participent à une activité de capture instantanée VSS classique. Dans ce scénario, SQL Server (y compris l’enregistreur SQL) agit comme un enregistreur dans une des zones de l’enregistreur. Exchange Server ou d’autres produits peuvent être des enregistreurs de ce type.

• Interface d’appareil virtuel : SQL Server fournit une interface de programmation d’application appelée Virtual Device Interface (VDI), qui aide les fournisseurs de logiciels indépendants à intégrer SQL Server dans leurs produits en fournissant la prise en charge des opérations de sauvegarde et de restauration. Conçues pour fournir une fiabilité et des performances optimales, ces API prennent en charge l'éventail complet de fonctions de sauvegarde et de restauration de SQL Server , y compris la gamme totale des sauvegardes à chaud et instantanées. Pour plus d’informations, consultez SQL Server 2005 Virtual Backup Device Interface Specification.

• Demandeur : processus (automatisé ou avec une interface graphique utilisateur) qui demande qu’un ou plusieurs jeux d’instantanés soient pris sur un ou plusieurs volumes d’origine. Dans cet article, un requérant est également utilisé pour désigner une application de sauvegarde qui effectue un instantané des bases de données SQL Server.

Pour plus d’informations, consultez Service VSS ( sur TechNet.

Écrivain SQL

L’enregistreur SQL est un enregistreur VSS fourni par l’instance SQL Server. Il gère l’interaction de VSS avec SQL Server. L’enregistreur SQL est fourni avec SQL Server en tant que service autonome et il est installé dans le cadre de l’installation de SQL Server.

Rôle de l’enregistreur SQL dans une opération de sauvegarde d’instantané VSS :

Configurer l’enregistreur SQL

Le service SQL Writer est installé dans le système dans le cadre de l’installation de SQL Server et il est configuré pour démarrer automatiquement au démarrage de Windows.

Compte de service du service SQL Writer

Pendant l’installation, le compte d’enregistreur SQL est installé pour utiliser le compte système local. Comme l’enregistreur SQL doit communiquer avec SQL Server en utilisant des API VDI exclusives, le compte SQL Writer doit disposer de droits d’accès suffisants à la fois pour SQL Server et pour VSS. La configuration du service en tant que compte système local fournit des droits suffisants pour que le service s’exécute correctement.

Réactiver et démarrer l’enregistreur SQL

Par défaut, le service enregistreur SQL est activé et démarre automatiquement. Si cette configuration a été modifiée, les étapes suivantes doivent être effectuées pour rétablir les paramètres par défaut :

Le service enregistreur SQL peut être activé en marquant ce service comme automatique. Pour ouvrir les services via le panneau de configuration, sélectionnez Démarrer, sélectionnez Panneau de configuration, double-cliquez sur Outils d’administration, puis double-cliquez sur Services. Dans le volet Services , double-cliquez sur le service enregistreur SQL et modifiez la propriété Type de démarrage sur Automatique.

Le service doit ensuite être démarré en sélectionnant le bouton Démarrer sous la propriété État du service dans l’écran de propriété de service mentionné précédemment.

Fonctionnalités prises en charge par l’enregistreur SQL

• Texte intégral : l’enregistreur SQL signale des conteneurs de catalogue de texte intégral avec des spécifications de fichier récursives sous les composants de base de données du document de métadonnées de l’enregistreur. Ils sont automatiquement inclus dans la sauvegarde lorsque le composant de base de données est sélectionné.

• Sauvegarde et restauration différentielles : l’enregistreur SQL prend en charge la sauvegarde différentielle et la restauration via deux mécanismes différentiels VSS :

  • Fichier partiel : l’enregistreur SQL utilise le mécanisme de fichier partiel VSS pour signaler des plages d’octets modifiées au sein de ses fichiers de base de données.

  • Fichier différentiel par heure de dernière modification : l’enregistreur SQL utilise le mécanisme VsS Differenced File by Last Modify Time pour signaler les fichiers modifiés dans les catalogues de texte intégral.

• Restauration avec déplacement : le module SQL prend en charge la spécification nouvelle destination de VSS lors de la restauration. La spécification New Target permet à un conteneur de catalogue de base de données/journal ou de catalogue de texte intégral d’être déplacé dans le cadre de l’opération de restauration.

• Renommage de la base de données : un demandeur peut avoir besoin de restaurer une base de données SQL Server avec un nouveau nom, en particulier si la base de données doit être restaurée côte à côte avec la base de données d’origine. L’enregistreur SQL prend en charge le renommage d’une base de données lors de l’opération de restauration, à condition que la base de données reste dans l’instance SQL d’origine.

• Sauvegarde de copie uniquement : il est parfois nécessaire d’effectuer une sauvegarde destinée à un usage particulier, par exemple lorsque vous devez effectuer une copie d’une base de données à des fins de test. Cette sauvegarde ne doit pas affecter les procédures globales de sauvegarde et de restauration de la base de données. L’utilisation de l’option COPY_ONLY spécifie que la sauvegarde est effectuée hors bande et ne doit pas affecter la séquence normale de sauvegardes. L’enregistreur SQL prend en charge le type de sauvegarde de copie uniquement avec les instances SQL Server.

• Récupération automatique de l’instantané de base de données : généralement un instantané d’une base de données SQL Server obtenue à l’aide de l’infrastructure VSS est dans un état non récupéré. Les données de l'image instantanée ne peuvent pas être accessibles en toute sécurité avant qu'elles ne passent par la phase de récupération pour annuler les transactions en cours et placer la base de données dans un état cohérent. Il est possible qu’une application de sauvegarde VSS demande la récupération automatique des instantanés, dans le cadre du processus de création d’instantanés.

Ces nouvelles fonctionnalités et leur utilisation sont décrites plus en détail dans les détails de l’option de sauvegarde et de restauration dans cet article.

Ce qui n’est pas pris en charge

• Les sauvegardes de journaux ne sont pas prises en charge par l’enregistreur SQL.
• La sauvegarde de fichier et de groupe de fichiers n’est pas prise en charge.
• La restauration de page n’est pas prise en charge.
• Les instantanés de base de données ne sont pas pris en charge et sont ignorés lors de la création de captures instantanées VSS de composant et non composant.
• Les bases de données avec fermeture automatique ou les bases de données avec arrêt activé.
• Linux ne fournit pas d’infrastructure VSS et par conséquent, l’enregistreur SQL n’est pas disponible sur Linux.

Le tableau suivant répertorie les types de sauvegardes de snapshots pris en charge par le SQL Writer/SQL Server, fonctionnant avec l’infrastructure VSS pour toutes les éditions de SQL Server sur Windows.

Opérations de sauvegarde

SQL Server (à l’aide de l’enregistreur SQL) prend en charge les modes suivants d’opérations de sauvegarde basées sur VSS :

• Non basé sur des composants
• Basé sur les composants

Support de version

L’enregistreur SQL est fourni avec SQL Server et prend en charge seulement les instances SQL Server. L’enregistreur SQL énumère également les instances SQL Server Express, y compris les instances utilisateur lancées par l’édition SQL Server Express.

Opérations de sauvegarde non basées sur des composants

Les sauvegardes ne reposant pas sur des composants sélectionnent implicitement les bases de données en utilisant la liste des volumes du jeu d’instantanés. L’enregistreur SQL vérifie si des bases de données sont endommagées, générant une erreur s’il en trouve. Une base de données endommagée est une base de données dans laquelle un sous-ensemble de fichiers est sélectionné par la liste des volumes.

Dans le modèle non basé sur les composants, seules les bases de données avec le modèle de récupération simple sont prises en charge. La réexécution après une restauration n'est pas prise en charge.

Opérations de sauvegarde basées sur les composants

Les sauvegardes basées sur les composants sont préférées et recommandées avec l’enregistreur SQL, car l’application (application de sauvegarde VSS) sélectionne explicitement les bases de données à partir des métadonnées retournées par l’enregistreur SQL. Le jeu d’instantanés doit inclure tous les volumes nécessaires à la sauvegarde de ces bases de données. L’infrastructure VSS n’ajoute pas automatiquement les volumes requis pour l’ensemble de bases de données sélectionné. Tous les volumes de stockage doivent être inclus dans le jeu d’instantanés de volume. Il incombe à l’application de sauvegarde de s’assurer que tous les volumes de sauvegarde sont inclus dans l’ensemble d’instantanés. L’enregistreur SQL détecte les bases de données endommagées (avec des volumes de stockage en dehors du jeu d’instantanés) et échoue la sauvegarde.

Le reste de cette section suppose que les sauvegardes basées sur les composants sont utilisées dans le cadre du processus de création d’instantané VSS pour SQL Server.

Processus de création d’instantanés

L’infrastructure VSS coordonne les activités d’un demandeur (application de sauvegarde) et de l’enregistreur SQL lors de la création d’instantanés SQL Server. Pour activer cette coordination, l’infrastructure VSS définit les interfaces de demandeur et d’enregistreur. Ces interfaces doivent être implémentées par les applications des demandeurs et les enregistreurs participants. SQL Writer implémente les interfaces d’enregistreur nécessaires. Dans le cadre du processus de création des instantanés, les interfaces de l’enregistreur SQL sont appelées par le framework VSS. L’enregistreur SQL interagit avec les instances SQL Server sur le système pour faciliter la création des instantanés.

Le framework VSS définit un ensemble d’API destinées à être utilisées par un demandeur ou une application de sauvegarde. Un développeur d’applications de sauvegarde doit suivre ces modèles d’appel d’API pour travailler avec le processus de création d’instantanés du framework VSS. Les sections suivantes décrivent le processus de création d’instantané du point de vue de l’enregistreur SQL. Elles détaillent également certaines interactions internes entre le demandeur, le framework VSS, l’enregistreur SQL et les instances SQL Server.

Pour plus d’informations sur ces étapes et pour plus d’informations sur les interfaces d’infrastructure VSS, consultez Le service VSS (Volume Shadow Copy Service).

Flux de travail de création d’instantanés

L’image suivante montre le diagramme de flux de données lors d’une opération de création/sauvegarde de capture instantanée basée sur les composants.

Pour mieux comprendre les tâches de base impliquées dans l’exécution d’une sauvegarde, il est utile de décomposer cette vue d’ensemble en phases suivantes :

• Initialisation de sauvegarde
• Phase de découverte de sauvegarde
• Tâches de prébackup
• Sauvegarde réelle des fichiers
• Arrêt de la sauvegarde

Initialisation de la sauvegarde

Pendant cette phase de sauvegarde, le requérant (application de sauvegarde) se lie à l’interface IvssBackupComponents, et l'initialise pour préparer la sauvegarde. Il appelle également l’API VSS IVssGatherWriterMetadata pour indiquer à l’infrastructure VSS de collecter les métadonnées auprès de tous les enregistreurs.

Le framework VSS appelle chacun des enregistreurs inscrits, y compris l’enregistreur SQL, pour obtenir les métadonnées des enregistreurs à l’aide de l’événement OnIdentify. L'écrivain SQL interroge les instances SQL Server pour obtenir les métadonnées de sauvegarde de chaque base de données et élaborer le document de métadonnées de l'écrivain. Cette phase est également appelée énumération de métadonnées.

Le document de métadonnées de l’enregistreur est un document qui contient des informations transmises de l’enregistreur au demandeur (application de sauvegarde). Le document de métadonnées de l'auteur contient les informations suivantes :

• ID d’application et nom convivial
• Emplacement des fichiers et des composants
• Quels fichiers doivent être inclus et exclus dans une sauvegarde
• Quelles options doivent être utilisées au moment de la restauration

Ces informations sont repassées au demandeur via l’infrastructure VSS.

Découverte de sauvegarde

Dans cette phase, un demandeur examine le document de métadonnées de l'auteur puis crée un document de composant de sauvegarde qu'il remplit avec chaque composant qui doit être sauvegardé. Il spécifie également les options et les paramètres de sauvegarde nécessaires dans le cadre de ce document. Pour l’enregistreur SQL, chaque instance de base de données qui doit être sauvegardée est un composant distinct.

Document des composants de sauvegarde

Il s’agit d’un document XML créé par un demandeur (en utilisant l’interface IVssBackupComponents) au cours de la configuration d’une opération de restauration ou de sauvegarde. Le document des composants de sauvegarde contient une liste de ces composants inclus explicitement, d’un ou plusieurs enregistreurs, participant à une opération de sauvegarde ou de restauration. Il ne contient pas d’informations de composant implicitement incluses. En revanche, un document de métadonnées d’enregistreur contient uniquement des composants d’enregistreur qui peuvent participer à une sauvegarde. Les détails de la structure d’un document des composants de la sauvegarde sont décrits dans la documentation de l’API VSS.

Tâches de présauvegarde

Les tâches de présauvegarde sous VSS sont axées sur la création d’un cliché instantané des volumes contenant des données pour la sauvegarde. L'application de sauvegarde enregistre les données à partir de la copie de l'ombre, et non du volume réel.

Les demandeurs attendent généralement les enregistreurs pendant la préparation de la sauvegarde et pendant la création du cliché instantané. Si l’enregistreur SQL participe à l’opération de sauvegarde, il doit configurer ses fichiers, et être prêt pour la sauvegarde et pour le cliché instantané.

Préparer la sauvegarde

Le demandeur doit définir le type d’opération de sauvegarde à effectuer (IVssBackupComponents::SetBackupState) puis prévenir les enregistreurs via VSS afin qu'ils se préparent pour une opération de sauvegarde à l’aide de IVssBackupComponents::PrepareForBackup.

L’enregistreur SQL a accès au document du composant de sauvegarde, qui détaille les bases de données à sauvegarder. Tous les volumes de stockage doivent être inclus dans le jeu d’instantanés de volume. L’enregistreur SQL détecte les bases de données déchirées (avec des volumes de stockage en dehors du jeu d’instantanés) et interrompt le processus de sauvegarde pendant l’événement PostSnapshot.

Sauvegarde réelle des fichiers

Dans cette phase, le demandeur peut déplacer si nécessaire les données vers un support de sauvegarde. Dans cette étape, les interactions sont entre le demandeur et le framework VSS. L’enregistreur SQL n’est pas impliqué.

1. Obtenir l’état de l’enregistreur. Retourne l’état des enregistreurs. Le demandeur peut avoir besoin de gérer les défaillances ici.
2. Effectuez la sauvegarde.

Le demandeur peut déplacer si nécessaire les données vers un support de sauvegarde.

Sauvegarde terminée

Cet événement indique que la sauvegarde a été effectuée correctement.

C’est aussi le moment où l’enregistreur SQL peut valider la sauvegarde en tant que base différentielle, si la sauvegarde actuelle est une sauvegarde complète de la base de données (et non pas une sauvegarde de copie uniquement).

Enregistrer les métadonnées de l’enregistreur

Le demandeur doit enregistrer le document du composant de sauvegarde, ainsi que chaque métadonnée de sauvegarde de composant et les données sauvegardées à partir de l’instantané. Ces métadonnées de l’enregistreur sont nécessaires à l’enregistreur SQL/SQL Server pour les opérations de restauration.

Fin de la sauvegarde

Le demandeur met fin à la copie de l'ombre en libérant l’interface IVssBackupComponents ou en appelant IVssBackupComponents::DeleteSnapshots.

Document de métadonnées du générateur SQL

Il s’agit d’un document XML créé par un enregistreur (dans le cas présent, l’enregistreur SQL) en utilisant l’interface IVssCreateWriterMetadata, et qui contient des informations sur l’état et les composants de l’enregistreur. Les aspects structurels d'un document de métadonnées d'auteur sont décrits dans la documentation de l'API VSS. Voici quelques-uns des détails du document de métadonnées de l’enregistreur SQL.

• Informations d’identification de l’auteur

  • Writer name (Nom de l’enregistreur) - L"SqlServerWriter"
  • Writer class ID (ID de classe de l’enregistreur) - 0xa65faa63, 0x5ea8, 0x4ebc, 0x9d, 0xbd, 0xa0, 0xc4, 0xdb, 0x26, 0x91, 0x2a
  • Writer instance ID (ID d’instance de l’enregistreur) - L"SQL Server:SQLWriter"
  • VSSUsageType - VSS_UT_USERDATA
  • VSSSourceType - VSS_ST_TRANSACTEDDB

• Writer Level Information (Informations au niveau de l’enregistreur) - VSS_APP_BACK_END

• Restore Method Specification (Spécification de la méthode de restauration) – VSS_RME_RESTORE_IF_CAN_REPLACE.

• Schéma de sauvegarde pris en charge (IVssCreateWriterMetadata ::SetBackupSchema API)

  • VSS_BS_DIFFERENTIAL – Sauvegarde différentielle
  • VSS_BS_TIMESTAMPED – Basée sur l’horodatage – pour les fichiers de catalogue de texte intégral.
  • VSS_BS_LAST_MODIFY – Sauvegarde différentielle basée sur la date/heure de dernière modification.
  • VSS_BS_WRITER_SUPPORTS_NEW_TARGET – Prend en charge l’option Nouvel emplacement cible.
  • VSS_BS_WRITER_SUPPORTS_RESTORE_WITH_MOVE – Prend en charge la restauration « avec déplacement »
  • VSS_BS_COPY – Prend en charge l’option de sauvegarde « Copie uniquement ».

• Informations au niveau du composant (contient des informations spécifiques au niveau du composant fournies par l’enregistreur SQL)

  • Type - VSS_CT_FILEGROUP
  • Name (Nom) - Nom du composant (nom de la base de données)
  • Chemin logique : de l’instance de serveur (sous la forme de « server\instance-name » pour les instances nommées et « serveur » pour l’instance par défaut.)
  • Component Flags (Indicateurs de composant)
  • VSS_CF_APP_ROLLBACK_RECOVERY – Indique que les instantanés SQL Server nécessitent toujours une phase de « récupération » pour rendre les fichiers cohérents et utilisables pour les scénarios de non-sauvegarde (c’est-à-dire les annulations d’application).
  • Selectionnable (Sélectionnable) - True
  • Selectable for Restore (Sélectionnable pour la restauration) - True
  • Restore Method supported (Méthodes de restauration prises en charge) – VSS_RME_RESTORE_IF_CAN_REPLACE

La seule extension de la structure du jeu de composants dans SQL Server est l’introduction de catalogues de texte intégral. Les catalogues de texte intégral sont des répertoires de conteneurs, qui ne peuvent pas être exprimés en tant que fichiers journaux ou de base de données VSS, étant donné que la base de données VSS et les fichiers journaux n’ont pas de spécification récursive. Par conséquent, l'écrivain SQL utilise un composant de groupes de fichiers VSS (VSS_CT_FILEGROUP) pour représenter le composant au niveau de la base de données, et des fichiers de groupes de fichiers pour représenter la base de données, le journal et les fichiers de catalogue de texte intégral.

Un exemple de document de métadonnées d’auteur est fourni à la fin de ce document.

Lancer un instantané

Le demandeur lance le processus d’instantané en appelant l’interface de l’infrastructure DoSnapshotSetVSS.

Créer instantané

Cette phase implique une série d’interactions entre l’infrastructure VSS et l’enregistreur SQL.

1. Préparer la capture instantanée. L’enregistreur SQL appelle SQL Server pour préparer la prise d’instantané.

2. Freeze (Figer). L'enregistreur SQL appelle SQL Server pour figer toutes les E/S de base de données pour chacune des bases de données sauvegardées dans la capture instantanée. Une fois l’événement de gel retourné à l’infrastructure VSS, VSS crée l’instantané.

3. Thaw (Libérer). Sur cet événement, l’enregistreur SQL appelle les instances SQL Server pour dégeler ou reprendre les opérations d’E/S normales.

La phase de création d’instantané prend moins de 60 secondes pour empêcher le blocage de toutes les écritures dans la base de données.

Post-instantané

Si la récupération automatique est nécessaire pour l’instantané, l’enregistreur SQL effectue la récupération automatique pour chaque base de données sélectionnée pour être dans l’instantané. Pour obtenir une explication détaillée, consultez captures instantanées récupérées automatiquement.

Processus de restauration

Cette section décrit le workflow de l’opération de restauration et les différentes étapes impliquées.

Workflow de l’opération de restauration

L’illustration suivante montre le diagramme des flux de données lors d’une opération de restauration VSS.

Pour mieux comprendre les tâches de base impliquées dans l’exécution d’une restauration, il est utile de décomposer cette vue d’ensemble dans les sections suivantes :

• Restauration de l'initialisation
• Préparation de la restauration
• Restauration réelle des fichiers
• Restaurer le nettoyage du système et l’arrêt

Dans tous les scénarios de restauration basée sur les composants VSS, la restauration de base de données est gérée par l’enregistreur SQL selon deux phases distinctes.

• Prérestauration : l'écrivain SQL effectue les validations, la fermeture des handles de fichiers, etc.
• Après la restauration : le SQL writer attache la base de données et réalise une récupération après incident si nécessaire.

Entre ces deux phases, l’application de sauvegarde est chargée de déplacer les données pertinentes sous SQL.

Réinitialiser l'initialisation

Pendant la phase d’initialisation d’une restauration, le demandeur doit avoir accès aux documents des composants de sauvegarde stockés.

Le document du composant de sauvegarde généré pendant l’opération de sauvegarde est stocké dans le cadre des données de sauvegarde. L’application de sauvegarde doit passer ces données au framework VSS. L’enregistreur SQL obtient l’accès à ces données au début du processus de restauration.

Préparer la restauration

Lorsque le demandeur se prépare pour une restauration, il utilise le document des composants de sauvegarde stockés pour déterminer ce qui doit être restauré et comment procéder. Le demandeur sélectionne les composants à restaurer et définit les options de restauration appropriées si nécessaire.

Si une application de sauvegarde a l’intention d’appliquer des sauvegardes différentielles ou de journaux au-dessus de l’opération de restauration actuelle (autrement dit, la restauration sans récupération est nécessaire), l’option suivante doit être définie dans le cadre de la création de composants pour chaque base de données en cours de restauration.

IVssBackupComponents::SetAdditionalRestores(true)

Une fois que tous les détails nécessaires sont définis dans le document du composant de sauvegarde, le demandeur initie l'appel IVssBackupComponents::PreRestore pour générer un événement de pré-restauration via VSS qui est géré par les enregistreurs.

L’enregistreur SQL examine le document du composant de sauvegarde fourni pour identifier les bases de données appropriées, en supprimant les fichiers supplémentaires créés depuis le temps de sauvegarde. Il vérifie également les espaces disque et ferme tous les descripteurs de fichiers de base de données ouverts, pour que le demandeur puisse copier les données nécessaires au cours de la phase de restauration. Cette phase permet la détection de toutes les conditions d’erreur préalables avant que le demandeur ne copie réellement le fichier. SQL Server place également la base de données dans l’état de restauration. À partir de ce stade, la base de données ne peut pas être démarrée tant qu’une restauration réussie n’est pas terminée.

Restaurer des fichiers

Il s’agit d’une action spécifique au demandeur. Il incombe au demandeur (application de sauvegarde) de copier les fichiers de base de données nécessaires (ou de copier les plages de données appropriées pour les restaurations différentielles) aux emplacements appropriés. L’enregistreur SQL n’est pas impliqué dans cette opération.

Nettoyage et arrêt

Une fois que toutes les données sont restaurées sur les bons emplacements, un appel d’un demandeur indiquant que l’opération de restauration a été terminée IvssBackupComponents::PostRestore, permet au writer SQL de savoir que les actions postérieures à la restauration peuvent être démarrées. À ce stade, l’enregistreur SQL effectue la phase de redo de la récupération après incident. Si la récupération n’est pas demandée (autrement dit, SetAdditionalRestores(true) n’est pas spécifiée par le demandeur), la phase d’annulation de l’étape de récupération est également effectuée pendant cette phase.

Détails de l’option de sauvegarde et de restauration

Cette section décrit en détail toutes les options de sauvegarde et de restauration prises en charge par l’enregistreur SQL.

Le demandeur crée une copie de l'ombre de volume

L’enregistreur SQL peut être impliqué dans le processus de création de cliché instantané de volume (en dehors du contexte de sauvegarde et de restauration), car les volumes de stockage des fichiers de base de données ont été ajoutés dans le jeu d’instantanés de volume. Dans ce cas, l’enregistreur SQL participe uniquement à l’énumération des métadonnées, à la coordination Freeze, Thaw, PrepareForSnapshot et PostSnapshot (consultez le diagramme de flux de données pour plus de détails).

Sauvegarde et restauration complètes

L’enregistreur SQL prend en charge les opérations de sauvegarde et de restauration complètes en mode non basé sur les composants et en mode basé sur les composants.

Sauvegarde et restauration non basées sur les composants

Dans une sauvegarde et une restauration non basées sur des composants, le demandeur spécifie un volume ou une arborescence de dossiers à sauvegarder et restaurer. Toutes les données du volume et du dossier spécifiés sont sauvegardées et restaurées.

Sauvegarde

Dans une sauvegarde non basée sur des composants, l’enregistreur SQL sélectionne implicitement les bases de données à l’aide de la liste des volumes dans l’ensemble d’instantanés. L’enregistreur vérifie si des bases de données sont endommagées, générant une erreur s’il en trouve. Une base de données endommagée est une base de données dans laquelle un sous-ensemble de fichiers est sélectionné par la liste des volumes. La progression (restaurations différentielles ou de journaux) après une restauration n'est pas prise en charge par SQL Writer.

Restaurer

Le demandeur restaure les bases de données qui ont été sauvegardées en mode non basé sur les composants. Ces restaurations ne peuvent pas être suivies par une restauration progressive, telle qu'une restauration différentielle ou de journal.

Pour les opérations de restauration non basées sur les composants, la restauration doit être effectuée avec l’instance SQL Server hors connexion ou les bases de données cibles sont supprimées/détachées pour s’assurer que les fichiers sont hors connexion. Les fichiers sont copiés en place, puis les bases de données attachées. Tout cela se produit en dehors de l’étendue de l’enregistreur SQL.

Sauvegarde et restauration basées sur les composants

Dans une sauvegarde basée sur les composants, le demandeur sélectionne explicitement les composants de base de données (à partir des métadonnées retournées par l’enregistreur SQL au client) à sauvegarder/restaurer.

Sauvegarde

Dans une sauvegarde basée sur les composants, tous les volumes de stockage des bases de données sélectionnées doivent être inclus dans le jeu d’instantanés de volume. Sinon, l’enregistreur SQL détecte les bases de données endommagées (avec des volumes de stockage en dehors du jeu d’instantanés) et échoue la sauvegarde. Une sauvegarde complète sauvegarde les données de la base de données et tous les fichiers journaux nécessaires pour ramener la base de données à un état cohérent au niveau transactionnel au moment de la restauration.

Restauration complète sans reprise en avant

Une restauration complète de la sauvegarde de la base de données est parfois accomplie sans procéder à une opération de rattrapage supplémentaire. Cela peut être dû au fait qu’il n’existe pas de métadonnées pour faciliter la restauration automatique ou, dans certains cas, la restauration n’est pas nécessaire. Cette section aborde brièvement ces deux situations.

Aucune métadonnée/aucune avance rapide

Si aucune métadonnée de l’enregistreur (métadonnées de sauvegarde basée sur les composants) n’est enregistrée au cours de l’opération de sauvegarde, la restauration doit être effectuée avec l’instance SQL Server hors connexion ou avec les bases de données cibles supprimées/détachées, de façon à garantir que les fichiers sont hors connexion. Les fichiers sont copiés en place, puis les bases de données rattachées. Tout cela se produit en dehors de l’étendue de l’enregistreur SQL.

Les métadonnées existent, mais aucun avancement supplémentaire n’est nécessaire

Le demandeur restaure les bases de données qui ont été sauvegardées en mode composant, mais aucune avancée n'est demandée. Dans ce cas, SQL Server effectue une récupération sur incident sur la base de données dans le cadre de la restauration.

Restauration complète avec avance incrémentielle supplémentaire

Le demandeur peut émettre une restauration spécifiant l’option SetAdditionalRestores(true) . Cette option indique que le requérant va effectuer d’autres restaurations par avance (telles que la restauration de journal, la restauration différentielle, etc.). Ceci indique à SQL Server de ne pas effectuer l’étape de récupération à la fin de l’opération de restauration.

Ceci est possible seulement si les métadonnées de l’enregistreur ont été enregistrées lors de la sauvegarde et sont disponibles pour l’enregistreur SQL au moment de la restauration. Le service SQL Server doit être en cours d’exécution avant que le demandeur indique à VSS d’effectuer l’activité de restauration.

L’enregistreur SQL attend la séquence suivante :

1. Préparation de la restauration de chaque base de données. Cette activité implique la fermeture de tous les descripteurs de fichiers afin de permettre la copie/le montage des fichiers de base de données par l’application du demandeur.

2. Les fichiers sont copiés/montés par l’application du demandeur.

3. Finalisez la restauration (avec NORECOVERY). Les bases de données sont mises en ligne, mais dans un état de restauration .

Les sauvegardes sql Server conventionnelles, différentielles ou journaux d’activité peuvent ensuite être utilisées pour transférer la base de données via l’infrastructure VDI ou Transact-SQL, ou en appliquant la restauration différentielle à l’aide de l’infrastructure VSS.

Support du texte intégral

L’enregistreur SQL signale des conteneurs de catalogue de texte intégral avec des spécifications de fichier récursives sous les sous-composants de base de données du document de métadonnées de l’enregistreur. Ils sont automatiquement inclus dans la sauvegarde lorsque le composant de base de données est sélectionné.

Sauvegarde et restauration différentielle

Une opération de sauvegarde différentielle sauvegarde seulement les données qui ont été modifiées depuis la sauvegarde complète de base la plus récente. Une sauvegarde différentielle contient seulement les parties des fichiers de base de données qui ont changé. Pour effectuer une telle sauvegarde, le demandeur (application de sauvegarde) aurait besoin d’informations sur l’emplacement des modifications dans les fichiers de base de données, afin que les sections appropriées des fichiers puissent être sauvegardées. Pendant une opération de sauvegarde différentielle, l’enregistreur SQL fournit ces informations au format spécifié par les informations de fichier partiel VSS. Ces informations peuvent être utilisées pour sauvegarder uniquement la partie modifiée des fichiers de base de données.

Sauvegarde

Le demandeur peut émettre une sauvegarde différentielle en définissant l’option DIFFERENTIALVSS_BT_DIFFERENTIAL dans le document IVssBackupComponents::SetBackupStatedu composant de sauvegarde, lors du lancement d’une opération de sauvegarde avec VSS. L’enregistreur SQL transmet les informations partielles du fichier (retournées par SQL Server) à VSS. Le demandeur peut obtenir ces informations de fichier en appelant l’API VSS IVssComponent::GetPartialFile. Ces informations sur les fichiers partiels permettent au demandeur de choisir seulement les plages d’octets modifiées à sauvegarder pour les fichiers de base de données.

Pendant la phase de tâches de pré-sauvegarde, l’enregistreur SQL s’assure qu’une base différentielle unique pour chaque base de données sélectionnée existe.

Pendant l’événement PostSnapshot, l’enregistreur SQL obtient les informations de fichier partielles de SQL Server et les ajoute au document du composant de sauvegarde à l’aide de l’appel IVssComponent::AddPartialFile.

Format des informations des fichiers partiels

Pour chaque base de données sauvegardée lors d’une sauvegarde différentielle, l’enregistreur SQL stocke les informations partielles de fichier pour chaque fichier de base de données. Ces informations sont utilisées par le demandeur ou par l’application de sauvegarde pour copier seulement les parties pertinentes du fichier sur le support de sauvegarde lors de la sauvegarde réelle des fichiers.

Pour plus d’informations sur le format de ces informations partielles de fichier, consultez Le service VSS (Volume Shadow Copy Service).

Un demandeur peut déterminer ces fichiers en appelant IVssComponent::GetPartialFileCount et IVssComponent::GetPartialFile. IVssComponent::GetPartialFile retourne un chemin d’accès et un nom de fichier pointant vers le fichier, et une chaîne de plages indiquant ce qui doit être sauvegardé dans le fichier.

Pour plus d’informations sur la récupération des informations des fichiers partiels, consultez la documentation de VSS.

Sauvegarder les fichiers

Pendant cette phase, l’application de sauvegarde doit examiner les métadonnées de l’enregistreur stockées dans le document du composant de sauvegarde et sauvegarder uniquement les parties pertinentes des fichiers. (Pour les fichiers catalogue de texte intégral, cette sauvegarde doit être effectuée en fonction des horodatages des fichiers. Cette procédure est décrite plus loin dans cet article.

Une sauvegarde différentielle est toujours liée à la dernière sauvegarde de base qui existe pour la base de données. Au moment de la restauration, SQL Server détecte les sauvegardes de base et différentielles incompatibles. Par conséquent, il incombe à l’application de sauvegarde ou à l’administrateur système de s’assurer que le différentiel est relatif à la sauvegarde complète attendue. Si une procédure hors bande a effectué une autre sauvegarde complète, l’application de sauvegarde peut ne pas être en mesure de restaurer le différentiel, car elle ne possède pas la sauvegarde de base.

Actuellement, si les informations de plage d’octets (informations partielles sur le fichier) sont trop volumineuses (dépassant 64 Ko de taille de mémoire tampon), SQL Server génère une erreur indiquant à l’utilisateur d’effectuer une sauvegarde complète.

Dépannage

Ajouter/supprimer/réduire/accroître/changement de nom logique/changement de nom physique créent des cas intéressants dans la résolution des problèmes de sauvegarde.

Fichiers nouvellement ajoutés après l’établissement de la base

Ces fichiers sont inclus dans la spécification partielle, car chaque en-tête du fichier de base de données doit figurer dans la spécification partielle. Outre la page d’en-tête, toutes les pages allouées doivent être incluses dans la spécification partielle.

Fichiers supprimés après la prise en charge de la base

Une fois la sauvegarde de base effectuée, des fichiers de données peuvent être supprimés. Ces fichiers ne sont pas inclus dans le document de métadonnées de l'auteur pendant la sauvegarde différentielle. En outre, aucune information partielle n’est associée au fichier supprimé.

Fichiers réduits après la prise de la base

Les informations partielles ne sont pas collectées à partir des fichiers tant que les réductions de fichiers n’ont pas été désactivées sur le serveur. Cela garantit que VSS n’inclut jamais d’informations partielles qui correspondent à la région réduite d’un fichier de données.

Fichiers augmentés après la création de la base

Si la croissance a eu lieu avant que la collecte des informations partielles, ces informations doivent avoir inclus les pages allouées dans la région d’extension. Si la croissance a eu lieu après la collecte des informations partielles, les informations partielles n’incluent pas les changements dans la région cultivée. Dans les sections suivantes, vous verrez que ces modifications sont restaurées par le rétablissement du journal.

Fichier renommé logiquement après la prise de la base

Un renommage logique du fichier n’affecte pas la sauvegarde ou la restauration, car le nom logique du fichier n’est pas référencé n’importe où dans le document de métadonnées de l’enregistreur ou dans le document du composant de sauvegarde.

Pour plus d’informations, consultez le document de métadonnées writer : exemple plus loin dans cet article.

Fichier physiquement renommé après la prise de la base

Un changement de nom de fichier de base de données physique n’est pas pris en compte tant que la base de données ne redémarre pas. Par conséquent, les informations de configuration de la base de données ou les informations du chemin de fichier dans la mémoire tampon des informations partielles sont toujours basées sur les anciens chemins physiques, qui sont les seuls chemins valides vers ces fichiers de base de données sur l’instantané.

Restaurer

Lors d’une restauration différentielle, les métadonnées de sauvegarde renvoyées par le demandeur à l’enregistreur SQL contiennent les informations sur le type de sauvegarde. Par conséquent, aucun traitement spécial de l’enregistreur SQL n’est nécessaire. SQL Server indique qu’il s’agit d’une restauration différentielle par lui-même. SQL Server gère une telle restauration différentielle de la même façon que par rapport à une restauration différentielle native qui n’est pas effectuée via VSS.

Phase de prérestauration

Pendant cette phase, SQL Server redimensionne tous les fichiers à la taille appropriée en fonction des métadonnées de fichier de la sauvegarde différentielle. Si le fichier est agrandi, SQL Server remplit de zéros la partie augmentée. Si un nouveau fichier doit être créé (il a été créé après la création de la sauvegarde de base), SQL Server initialise à zéro le nouveau fichier. Il ferme également tous les descripteurs de fichiers afin que l’application de sauvegarde puisse remplacer les fichiers par les données restaurées à partir du support de sauvegarde.

Restaurer des fichiers

Le client doit restaurer les fichiers en fonction de la spécification des fichiers partiels. Les données doivent être restaurées sur le même décalage/la même plage du fichier de base de données que ce qui est spécifié dans la spécification des fichiers partiels stockée dans les métadonnées de l’enregistreur.

Le fichier de base de données ajout/suppression/croissance/réduction/renommage logique/renommage physique crée à nouveau des cas intéressants pour le dépannage au moment de la restauration.

Si un fichier de base de données a été ajouté après la prise en charge complète de la base

Ces fichiers doivent avoir été précréés par SQL Server pendant la phase de préparation de la restauration. Ils doivent avoir été étendus à la taille appropriée et mis à zéro. Le client doit seulement étendre les données en fonction de la spécification partielle (la spécification partielle inclut toutes les extensions allouées).

Si un fichier de base de données a été supprimé après avoir effectué la sauvegarde complète

Les informations partielles fournies par SQL Server n’incluent aucune information de suivi pour ces suppressions de fichiers. SQL Server est responsable de la détection des fichiers à supprimer, en comparant les métadonnées des fichiers restaurés aux conteneurs existants et en les supprimant. Cette opération est effectuée avant la restauration en tant qu’étape de préparation.

Si un fichier de base de données a augmenté depuis que la base complète a été prise

Ces fichiers doivent être étendus à la taille appropriée par SQL Server pendant la phase de préparation de la restauration. La région étendue doit également être supprimée par SQL Server. Par conséquent, le client peut sans problème étendre les données même dans la région agrandie, en fonction de la spécification partielle. Si le fichier a été agrandi après que les informations partielles ont été prises, les modifications apportées à la région étendue sont restaurées en rejouant le journal qui a été sauvegardé avec la sauvegarde différentielle.

Si un fichier de base de données a été réduit depuis que la base complète a été prise

SQL Server est chargé de tronquer le fichier à la taille nécessaire en fonction des métadonnées. Cette opération est effectuée avant la restauration en tant qu’étape de préparation.

Si un fichier de base de données a été renommé logiquement depuis que la base complète a été prise

Cela n’affecte pas la restauration, car le nom logique n’apparaît pas dans le document de métadonnées de l’enregistreur ou dans le document du composant de sauvegarde. La modification du nom logique est restaurée lorsque le client applique la modification au fichier de base de données primaire, qui contient les informations du catalogue système.

Si un fichier de base de données a été physiquement renommé depuis que la base complète a été prise

Si, au moment de la sauvegarde différentielle, le renommage n’a pas pris effet, le client restaure toujours les données à l’ancien emplacement. Un redémarrage de la base de données après la restauration entraîne le changement de nom physique. Si, au moment de la sauvegarde différentielle, le renommage du fichier physique avait déjà pris effet, les données partielles, le cas échéant, sont sauvegardées à partir du nouveau chemin d’accès physique.

Après la restauration

Pendant les événements de post-restauration, l'enregistreur SQL effectue l'opération de redo normal et la récupération (si SetAdditionalRestores() est défini à False) de la base de données.

Sauvegarde et restauration différentielles pour les catalogues de texte intégral

Les catalogues de texte intégral SQL Server font partie des ressources de base de données qui doivent être sauvegardées ou restaurées avec le reste des fichiers de base de données. Une sauvegarde différentielle est basée sur un horodatage pour le catalogue de texte intégral. L’opération de sauvegarde et de restauration différentielle VSS de SQL Server a une seule sauvegarde de base. En d’autres termes, il n’existe pas de bases différentes pour différents conteneurs. Pour la sauvegarde de catalogue de texte intégral VSS, cela signifie que pour tous les conteneurs de catalogue de texte intégral, la sauvegarde différentielle est basée sur un horodatage unique, contrairement au cas d’une sauvegarde différentielle SQL Server native, dans laquelle il existe une base d’horodatage par conteneur de catalogue de texte intégral.

Dans VSS, cet horodatage est exprimé sous la forme d’une propriété à l’échelle du composant, définie lors de la sauvegarde complète et utilisée lors d’une sauvegarde différentielle suivante.

OnIdentify

Dans OnIdentify, l’enregistreur SQL appelle IVssCreateWriterMetadata::SetBackupSchema() pour définir la valeur VSS_BS_TIMESTAMPED. Ceci indique à l’application de sauvegarde que l’enregistreur SQL est propriétaire de la gestion de la base différentielle.

Définir l’horodatage de base

L’horodateur de base est défini lors d’une sauvegarde complète. Dans OnPostSnapshot(), l’enregistreur appelle IVssComponent::SetBackupStamp() pour stocker l’horodatage avec le composant dans le document de la sauvegarde.

Sauvegarde différentielle

L’application de sauvegarde récupère cet horodatage à partir de la sauvegarde complète de base et rend l’horodatage disponible pour l’enregistreur en appelant IVssComponent::GetBackupStamp() pour récupérer l’horodatage de base de la sauvegarde de base précédente. Ensuite, il le rend disponible pour l’enregistreur en appelant IVssBackupComponent::SetPreviousBackupStamp(). L’enregistreur récupère ensuite le datage en appelant IVssComponent::GetPreviousBackupStamp() et le convertit en un horodatage utilisé pour IVssComponent::AddDifferencedFilesByLastModifyTime().

Responsabilité de l’application de sauvegarde pendant la sauvegarde différentielle

Pendant une sauvegarde différentielle, l’application de sauvegarde est responsable des éléments suivants :

• Sauvegarde d’un fichier (le fichier entier) dont le dernier horodatage modifié est supérieur à l’horodatage spécifié par l’heure de dernière modification du fichier défini dans le composant.

• Suivi et détection des fichiers supprimés.

Responsabilités de l’application de sauvegarde pendant une restauration différentielle

Pendant une restauration différentielle, l’application de sauvegarde est responsable des éléments suivants :

• Restauration de tous les fichiers sauvegardés, soit en créant un fichier s’il n’existe pas déjà, soit en remplaçant un fichier existant s’il existe déjà.

• Agrandissement du fichier avant d’étendre le contenu si le fichier restauré est plus grand que le fichier existant.

• Troncation du fichier à la même taille que celle du fichier restauré si le fichier restauré est plus petit que le fichier existant.

• Suppression de tous les fichiers qui doivent être supprimés ; autrement dit, ces fichiers qui ne doivent pas exister à partir du point dans le temps de la sauvegarde différentielle.

Sauvegarde de copie seule

Il est parfois nécessaire d’effectuer une sauvegarde destinée à un usage particulier. Par exemple, il peut être nécessaire de faire une copie d’une base de données à des fins de test. Cette sauvegarde ne doit pas affecter les procédures globales de sauvegarde et de restauration de la base de données. L’utilisation de l’option COPY_ONLY spécifie que la sauvegarde est effectuée hors bande et ne doit pas affecter la séquence normale de sauvegardes. L’enregistreur SQL prend en charge le type de sauvegarde de copie uniquement avec les instances SQL Server.

Pendant la phase de découverte de sauvegarde, l’enregistreur SQL indique sa capacité à effectuer une sauvegarde de copie uniquement en définissant l’option VSS_BS_COPY de schéma de sauvegarde prise en charge à l’aide de l’appel IVssCreateWriterMetadata::SetBackupSchema . Le demandeur peut définir le type de sauvegarde comme sauvegarde de copie uniquement en définissant l’option VSS_BACKUP_TYPE comme VSS_BT_COPY avec l’appel IVssBackupComponents::SetBackupState.

Lorsqu’une sauvegarde en copie seule est sélectionnée, il est supposé que les fichiers sur disque sont copiés vers un support de sauvegarde (par le demandeur) quel que soit l’état de l’historique de sauvegarde de chaque fichier. SQL Server ne met pas à jour l’historique des sauvegardes. Ce type de sauvegarde ne constitue pas une sauvegarde de base pour d’autres opérations de sauvegarde différentielles, et il ne dérange pas non plus l’historique des sauvegardes différentielles précédentes.

Restauration avec déplacement

VSS permet au demandeur (application de sauvegarde) de spécifier une nouvelle cible de restauration à l’aide de l’appel IVssComponent::SetNewTarget . Dans les deux PreRestore() et PostRestore(), l’enregistreur SQL vérifie s’il existe au moins une nouvelle cible spécifiée. Il incombe à l’application de sauvegarde de copier physiquement les fichiers vers le nouvel emplacement pendant la restauration/la copie des fichiers réels.

L’application de sauvegarde est autorisée à spécifier seulement de nouvelles cibles pour le chemin physique, mais pas la spécification du fichier lui-même. Par exemple, pour un fichier de base de données situé à l’emplacement c:\data\test.mdf, le nom test.mdf de fichier réel ne peut pas être modifié. Seul le chemin d’accès c:\data peut être modifié. Pour un conteneur de catalogue de texte intégral situé à l’emplacement c:\ftdata\foo, étant donné que la spécification de fichier dans VSS est "*" et que la spécification du chemin d’accès dans VSS est c:\ftdata\foo, le chemin d’accès entier peut être modifié.

Modification du nom d'une base de données

Un demandeur peut avoir besoin de restaurer une base de données SQL Server avec un nouveau nom, en particulier si la base de données doit être restaurée côte à côte avec la base de données d’origine. Cette option peut être spécifiée par le demandeur pendant l’opération de restauration en définissant une option de restauration personnalisée en tant que « Nouveau nom du composant » = <« Nouveau nom »> à l’aide de l’appel IVssBackupComponents::SetRestoreOptions() VSS (dans le wszRestoreOptions paramètre).

L’enregistreur SQL prend tout le contenu de la valeur du nouveau nom du composant et l’utilise comme nouveau nom pour la base de données restaurée. Si aucune option n’est spécifiée, SQL Server restaure la base de données avec son nom d’origine (nom du composant).

Captures instantanées récupérées automatiquement

En général, un instantané d’une base de données SQL Server obtenu en utilisant le framework VSS est dans un état non récupéré. Les données de l’instantané ne peuvent pas être consultées en toute sécurité avant de passer par la phase de récupération pour annuler les transactions en cours et placer la base de données dans un état cohérent. Étant donné que l’instantané est dans un état en lecture seule, il ne peut pas être récupéré par le processus normal d’attachement de la base de données.

Il est possible de procéder à la récupération automatique des instantanés dans le cadre du processus de création d’instantanés. Dans le cadre du document de métadonnées de l’enregistreur, l’enregistreur SQL spécifie l’indicateur de composant VSS_CF_APP_ROLLBACK_RECOVERY pour indiquer que la récupération doit être effectuée pour la base de données sur l’instantané avant que celle-ci ne soit accessible. Lors de la spécification du jeu d’instantanés, le demandeur peut indiquer si l’instantané doit être un instantané de restauration d’application (autrement dit, tous les fichiers de base de données dans un instantané doivent être dans un état cohérent pour l’utilisation de l’application) ou bien un instantané de sauvegarde, utilisé pour sauvegarder des données à restaurer ultérieurement en cas de défaillance du système.

Le demandeur doit définir VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY pour indiquer que ce composant sera sauvegardé à des fins autre qu’une sauvegarde. VSS corrèle ensuite VSS_CF_APP_ROLLBACK_RECOVERY le writer SQL spécifié sur le composant sélectionné avec VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY, et détermine que la récupération automatique est en cours. VSS rend l’instantané modifiable pendant une période limitée et ajoute automatiquement le bit VSS_VOLSNAP_ATTR_AUTORECOVERY au contexte des instantanés.

Dans SQL Server, la récupération automatique doit être appliquée uniquement aux instantanés de retour arrière d'application, et non aux instantanés de sauvegarde. Pour les instantanés d’annulation d’application, un processus de récupération automatique est lancé par l’enregistreur SQL Writer lors de PostSnapShotevent. Ce processus effectue les opérations suivantes pour chaque base de données SQL Server sélectionnée explicitement (par le demandeur) dans le jeu d’instantanés :

• Attacher la base de données d’instantané à l’instance SQL Server d’origine (c’est-à-dire l’instance à laquelle la base de données d’origine est attachée).

• Récupérer la base de données (ceci se produit dans le cadre de l’opération d’attachement).

• Réduire la taille des fichiers journaux.

  Cela réduit la quantité inutile de copie en écriture qui doit être effectuée par l’infrastructure VSS, si le fournisseur VSS est un fournisseur de logiciels. La réduction des fichiers journaux est le comportement par défaut. Cela peut être désactivé en définissant la valeur sur la clé de registre suivante : 1.

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SQLWriter\Settings\DisableLogShrink
  

  Cela peut être utile dans les scénarios où l’instantané peut être utilisé pour exporter des données à partir d’une page spécifique (à un moment précis dans le temps) à partir du journal pour résoudre un problème dans la base de données en ligne.

• Détachez la base de données.

À présent, il existe un instantané cohérent et récupéré qui peut être attaché pour des requêtes.

Transactions sur plusieurs bases de données

Dans les versions antérieures de SQL Server, les bases de données d’instantanés peuvent parfois contenir des transactions multi-bases de données en cours d’exécution. Pendant l’opération de récupération, l’auteur SQL attache la base de données aux instantanés avec l’option Annulation Présumée. Cela annule toute transaction multi-base de données qui n’est pas encore validée (y compris les transactions qui se trouvent dans un état Prêt à valider). Cela peut entraîner des incohérences entre les bases de données dans l'ensemble des clichés instantanés.

Par exemple, considérez deux bases de données A et B. Il existe une transaction distribuée entre ces deux bases de données et cette transaction est en état validé dans la base de données A et dans l’état Prêt à valider dans la base de données B. Dans le cadre du processus de récupération automatique, cette transaction est validée dans la base de données A et restaurée dans la base de données B. Cela peut entraîner des incohérences dans le jeu d’instantanés.

Les versions plus récentes de Windows ont un composant Microsoft Distributed Transaction Coordinator (MS DTC) amélioré qui résout ce problème d’incohérence pour les transactions couvrant les bases de données sur les instances SQL Server. Les versions plus récentes de SQL Server corrigent ces incohérences pour les transactions couvrant les bases de données au sein d’une instance SQL Server.

Implications en matière de sécurité pour les instantanés récupérés automatiquement

Pour les instantanés VSS, après la récupération automatique, les fichiers sont sécurisés à l’aide des listes de contrôle d’accès (ACL) pour autoriser l’accès uniquement au groupe intégré spécial auquel appartient le compte SQL Server. Cela implique que les membres de l'admin box ou du groupe spécial peuvent joindre la base de données. Le client demandant un attachement des fichiers de base de données sur un instantané doit être membre de Builtin/Administrators ou du compte SQL Server.

Bases de données utilisateur de modèle de récupération simple

Si la master base de données est restaurée avec les bases de données utilisateur qui utilisent le modèle de récupération simple, les bases de données utilisateur peuvent être restaurées avec la même technique que la master base de données : avec l’arrêt de l’instance, il vous suffit de copier ou de monter les volumes. Quand l’instance SQL est démarrée, tout est récupéré.

Bases de données utilisateur avec restauration par progression

Si les bases de données utilisateur doivent être récupérées et avancées dans le temps conjointement avec master lors de la reprise de la base de données, l’instance ne doit pas démarrer et récupérer les bases de données master et utilisateur ensemble.

La procédure est la suivante :

1. Vérifiez que l’instance SQL Server est arrêtée.

2. Effectuez la restauration en deux phases.

   1. Restaurez les bases de données système et les bases de données utilisateur qui doivent être récupérées en même temps (c’est-à-dire les bases de données utilisateur dans le modèle de récupération simple) via la copie de fichiers ou le montage en volume, via VSS.

      • Si les bases de données utilisateur à transférer ne sont pas sur le même volume que les bases de données système, ce volume ne doit pas être ramené pour l’instant. Ce scénario nécessite une planification avant la sauvegarde.

      • Si les bases de données utilisateur se trouvent sur le même volume que les bases de données système, les bases de données utilisateur doivent être masquées pour SQL Server.

   2. Démarrez l’instance SQL Server à l’aide du -f paramètre. (Lorsque vous utilisez l’option de -f démarrage, seule la master base de données peut être restaurée.)

      1. Émettre une ALTER DATABASE <database> SET OFFLINE (ou détacher la base de données) pour que chaque base de données soit mise à jour.

      2. Arrêtez l’instance SQL Server.

      3. Démarrez l’instance SQL Server (les fichiers des bases de données utilisateur à restaurer ne sont pas visibles par SQL Server).

Utilisez VSS pour restaurer les bases de données utilisateur WITH NORECOVERY, comme décrit dans Récupération complète avec roll-forward supplémentaire.

Document de métadonnées de l'auteur : un exemple

Une base de données nommée DB1, appartenant à l’instance Instance1 SQL Server sur l’ordinateur Server1, contient les fichiers de base de données/journaux suivants :

• Fichier de base de données nommé « principal » stocké sur c:\db\DB1.mdf
• Fichier de base de données nommé « secondaire » stocké sur c:\db\DB1.ndf
• Fichier journal de base de données nommé « journal » stocké à l’adresse c:\db\DB1.ldf
• Catalogue de texte intégral nommé « foo » stocké sous le répertoire c:\db\ftdata\foo
• Catalogue de texte intégral nommé « bar » stocké sous le répertoire c:\db\ftdata\bar

Voici les métadonnées de l’enregistreur de la base de données :

Composant de groupe de fichiers au niveau de la base de données

Fichier de base de données primaire :

ComponentType: VSS_CT_FILEGROUP
LogicalPath: "Server1\Instance1"
ComponentName: "DB1"
Caption: NULL
pbIcon: NULL
cbIcon: 0
bRestoreMetadata: FALSE
NotifyOnBackupComplete: TRUE
Selectable: TRUE
SelectableForRestore: TRUE
ComponentFlags: VSS_CF_APP_ROLLBACK_RECOVERY

Fichier de base de données secondaire :

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.mdf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file
LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ndf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Journal de fichier texte intégral :

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ldf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Fichier texte intégral foo :

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\foo"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Fichier texte intégral bar :

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\bar"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Si l’instance de serveur est l’instance par défaut sur l’ordinateur, le chemin logique devient une partie : Server1.

Cas particuliers

Cette section décrit quelques cas particuliers rencontrés lors des opérations de sauvegarde et de restauration basées sur SQL Writer.

Bases de données avec fermeture automatique

Dans le cadre des sauvegardes non basées sur des composants, la fermeture automatique des bases de données a lieu lors de la vérification des conditions de fragmentation, mais les bases de données ainsi fermées ne sont pas explicitement figées pendant les opérations de sauvegarde.

Le scénario attendu ici est que de nombreuses bases de données fermées peuvent exister et que vous souhaitez réduire le coût de l’instantané. Les bases de données fermées automatiquement sont généralement utilisées dans les configurations de bas niveau où les ressources sont rares.

Liste de fichiers

La liste des fichiers de chaque base de données est déterminée pendant une étape d’énumération avant l’événement Prepare for Backup. Si la liste des fichiers de base de données change entre l’énumération et le moment où la base de données est figée, la base de données peut être endommagée, à moins que l’application ne revérifie la liste des fichiers. Bien que ce scénario soit peu probable, il s’agit d’un élément dont les fournisseurs doivent être conscients.

Instances arrêtées

Si une instance de SQL Server n’est pas en cours d’exécution au moment de l’étape d’énumération, aucune des bases de données de ces instances ne peut être sélectionnée.

Si une instance s’arrête dans l’intervalle entre l’énumération et l’événement de préparation pour la sauvegarde, toutes les bases de données de l’instance arrêtée sont ignorées.

Bases de données système et utilisateur

Les bases de données système de SQL Server incluent les bases de données master, model et msdb, qui sont fournies et installées dans le cadre de SQL Server. Cette section décrit comment ces bases de données sont gérées dans un processus de sauvegarde d’instantané VSS.

La master base de données ne peut être restaurée qu’en arrêtant l’instance, en remplaçant les fichiers de base de données (effectués par l’application de sauvegarde), puis en redémarrant l’instance. Aucun avancement n'est possible.

L’enregistreur SQL prend en charge la restauration en ligne des bases de données model et msdb, sans arrêter l’instance.

Contenu connexe

• SQL Server - Journalisation de l’enregistreur VSS Writer
• BACKUP (Transact-SQL)
• Instructions RESTORE (Transact-SQL)
• Sauvegarder et restaurer des bases de données SQL Server
• Sauvegardes de copie uniquement
• Sauvegardes du journal des transactions (SQL Server)
• Appliquer les sauvegardes du journal de transactions (SQL Server)
• Guide d'architecture et gestion du journal des transactions de SQL Server