Chemins de récupération
La compréhension des chemins de récupération est importante si vous effectuez des sauvegardes différentielles ou des sauvegardes de journaux et que vous procédez à la récupération d'une base de données jusqu'à une limite antérieure dans le temps selon une des méthodes suivantes :
Restauration limitée dans le temps
Une restauration, sans restaurer au préalable toutes les sauvegardes de journaux ou les sauvegardes différentielles les plus récentes.
Si vous récupérez une base de données à partir d'un point de récupération antérieur et que vous commencez à utiliser la base de données à partir de ce point, un nouveau chemin de récupération est initialisé. Le chemin de récupération représente la séquence des sauvegardes des données et des journaux qui ont amené une base de données à un moment particulier, que cela soit via un usage régulier de la base de données ou via une restauration spécifique de données et de journaux. Un chemin de récupération est constitué d'un jeu unique de transformations particulières qui ont fait évoluer la base de données au cours du temps, tout en maintenant sa cohérence. L'illustration suivante montre les relations existantes entre un point de récupération et les chemins de récupération résultants.
.gif "Point de récupération et chemins d'accès de récupération résultants")
Les situations suivantes créent un nouveau chemin de récupération car la base de données n'est pas restaurée « jusqu'à la fin du temps ». Ensuite, les sauvegardes existantes peuvent faire descendre la base de données dans au moins deux chemins de récupération qui utilisent tous le même éventail de LSN.
Restauration d'une sauvegarde complète de la base de données et récupération de la base de données sans utilisation d'un autre type de sauvegarde.
La récupération de la base de données à la fin d’une sauvegarde différentielle différente de celle la plus récente.
La restauration d'une sauvegarde complète et une sauvegarde différentielle de la base de données, ainsi que sa récupération sans l'application des sauvegardes des journaux de transactions existants.
La récupération de la base de données à la fin d’une sauvegarde du journal des transactions différente de la plus récente.
La récupération de la base de données à un moment spécifique ou au niveau d'une transaction marquée au sein d’une sauvegarde du journal des transactions.
En général, un point de récupération marque le début d'un nouveau chemin de récupération si le point de récupération provoque la restauration de transactions. Les sauvegardes antérieures peuvent désormais avoir des LSN supérieurs au LSN du point de récupération. Ces LSN se situent sur une branche de récupération différente de la nouvelle branche créée par le point de récupération actuel.
Meilleure pratique Pour éviter de créer un chemin de récupération à plusieurs branchements de récupération, effectuez un jeu complet de sauvegardes des données dès que possible, après la récupération de la base de données. Cette méthode garantit que toutes les sauvegardes ont lieu sur une branche de récupération unique. Pour vérifier cette méthode, examinez la colonne last_recovery_fork_guid dans la table backupset ou le jeu de résultats RESTORE HEADERONLY après avoir sauvegardé les données.
Exemple de chemin de récupération
Initialement, toutes les sauvegardes d'une base de données forment un chemin de récupération unique, comme le montre l'illustration ci-dessous. Dans cette illustration, le chemin de récupération inclut une sauvegarde de la base de données, effectuée à l'instant t1, et trois sauvegardes du journal, effectuées aux instants t2, t3 et t4.
.gif "Chemin de récupération d'origine")
L'illustration ci-dessous montre un branchement de récupération qui résulte de la récupération de la base de données à un moment antérieur. En cas de problème avec la sauvegarde t4, l'administrateur de la base de données récupère la base de données à la fin de la sauvegarde du journal à l'instant t3. Cette restauration provoque un branchement de récupération. À l'instant t5, une nouvelle sauvegarde du journal démarre une nouvelle branche de récupération, la branche de récupération 2.
.gif "Création d'une deuxième branche de récupération")
[!REMARQUE]
La sauvegarde du journal à l'instant t5 contient des métadonnées de branchement de récupération qui connectent cette sauvegarde à la sauvegarde du journal à l'instant t3 sur la branche de récupération 1. Pour plus d'informations sur les métadonnées de branchement de récupération, consultez « Gestion des branchements de récupération », ultérieurement dans cette rubrique.
L'exemple indiqué dans l'illustration précédente crée un nouveau chemin de récupération, illustré dans la figure ci-dessous. Le nouveau chemin de récupération inclut certaines des sauvegardes sur la branche de récupération 1 (de t1 à t3) et chaque sauvegarde du journal sur la branche de récupération 2 (de t5 à t9). Du point de vue de ce chemin de récupération, la sauvegarde du journal à l'instant t4 est obsolète.
.gif "Nouveau chemin de récupération")
Après une restauration jusqu`à une date et heure, la sauvegarde suivante provoque toujours un branchement de récupération. Dans l'illustration ci-dessous, une restauration jusqu`à une date et heure est effectuée à mi-chemin de la sauvegarde du journal à l'instant t4. La récupération de la base de données à cet instant génère un branchement de récupération. Ensuite, une sauvegarde du journal est créée sur la base de données récupérée à l'instant t5, établissant la branche de récupération 2 et créant un nouveau chemin de récupération. La première sauvegarde du journal sur la nouvelle branche, t5, contient le même premier numéro séquentiel (LSN) que la sauvegarde du journal à l'instant t3 et la remplace. Par conséquent, les sauvegardes t3 et t4 sont toutes les deux obsolètes sur le nouveau chemin de récupération.
.gif "Nouveau chemin de récupération après une restauration limitée dans le temps")
Pour restaurer les sauvegardes sur ce nouveau chemin de récupération, la séquence de restauration est : t1, t2 et t5. Lorsque des sauvegardes futures sont effectuées sur la branche de récupération 2, elles sont incorporées dans le nouveau chemin de récupération.
Pour restaurer et restaurer par progression dans le cadre d'un ancien chemin
En général, lorsque plusieurs chemins de récupération existent, le chemin le plus récent est le chemin privilégié pour restaurer la base de données. Nous vous recommandons d'éviter l'utilisation d'un ancien chemin de récupération. Toutefois, si cela s'avère nécessaire, vous pouvez restaurer par progression sur un ancien chemin de récupération en suivant la séquence des sauvegardes effectuées avant la création du chemin de récupération actuel. Par exemple, vous pouvez utiliser des sauvegardes réalisées avant une récupération jusqu'à une date et heure pour atteindre des points ultérieurs dans le temps, le long de l'ancien chemin.
Par exemple, en fonction des sauvegardes créées dans l'illustration précédente, après la création des sauvegardes du journal 5 et 6, il est toujours possible de restaurer à partir de la sauvegarde complète de base de données effectuée à l'instant t1 jusqu'à la fin de la sauvegarde du journal à l'instant t4. Cela se situe sur l'ancien chemin de récupération.
Pour restaurer et restaurer par progression à partir d'un ancien chemin vers un nouveau chemin
Le Moteur de base de données SQL Server empêche une séquence de restauration d'utiliser des sauvegardes non compatibles entre elles, c'est-à-dire qui tentent d'effectuer une restauration par progression le long de chemins de récupération différents. Cette restriction maintient la cohérence de la base de données après une récupération.
Pour restaurer et restaurer par progression dans le cadre d'un nouveau chemin de récupération, créez des séquences de restauration distinctes pour les sauvegardes, avant et après le point de récupération :
Restaurez les sauvegardes effectuées avant la récupération qui a engendré le nouveau chemin de récupération. Excluez la sauvegarde contenant le point de récupération.
Restaurez par progression dans le cadre du nouveau chemin de récupération en restaurant les sauvegardes effectuées depuis la création du chemin de récupération.
Gestion des branchements de récupération
Une branche de récupération correspond à un éventail de LSN qui partage le même GUID (identifiant global unique). Un chemin de récupération décrit un éventail de LSN entre un point de départ (LSN,GUID) et un point final (LSN,GUID). Le jeu de LSN d'un chemin de récupération peut traverser une ou plusieurs branches de récupération entre le début et la fin. Une nouvelle branche de récupération est initialisée lorsqu'une base de données est créée et lorsque RESTORE WITH RECOVERY génère un branchement de récupération.
Un branchement de récupération correspond au point (LSN,GUID) où une nouvelle branche de récupération commence chaque fois qu'une opération RESTORE WITH RECOVERY est exécutée. Chaque branchement de récupération établit une relation de type parent/enfant entre les branches de récupération.
La récupération de la base de données définit l'état global de celle-ci, y compris le prochain LSN, au point de récupération. Les LSN sont ensuite réutilisés, en commençant par le fork_point_lsn. Par conséquent, lors de l'établissement d'une séquence de restauration, les sauvegardes doivent être reliées par branchement de récupération, ainsi que par LSN, dans la mesure où le mêmeLSN peut exister dans plus d'un branchement. L'illustration ci-dessous montre la réutilisation du LSN. Elle illustre la réutilisation des LSN dans différents branchements de récupération. Les zones vertes dans l'illustration indiquent deux sauvegardes qui utilisent le même numéro séquentiel dans le journal (LSN).
.gif "Réutilisation des numéros LSN dans différents branchements de récupération")
Si une séquence de restauration doit incorporer des sauvegardes traversant un branchement de récupération, elle doit être construite de manière à ce que les sauvegardes utilisées suivent le chemin de récupération correct jusqu'au point de récupération. Pour cela, les sauvegardes incluent le GUID d'un premier branchement de récupération et le GUID d'un dernier branchement de récupération.
Ces GUID, avec d'autres métadonnées concernant le suivi des chemins de récupération, sont stockés dans la table d'historique backupset et sont également retournés par l'instruction RESTORE HEADERONLY. Le tableau ci-dessous résume les valeurs de métadonnées relatives à la construction de séquences de restauration qui franchissent un branchement de récupération. Remarquez que les noms des colonnes pour ces valeurs sont différents pour la table d'historique et le jeu de résultats de l'instruction RESTORE HEADERONLY :
LSN |
Description |
nom de la colonne de backupset |
nom de la colonne de RESTORE HEADERONLY |
|---|---|---|---|
GUID du premier branchement de récupération |
ID du branchement de récupération initial. |
first_recovery_fork_guid |
FirstRecoveryForkID |
GUID du dernier branchement de récupération |
ID du branchement de récupération final. |
last_recovery_fork_guid |
RecoveryForkID |
Premier LSN |
Numéro séquentiel dans le journal correspondant à l'enregistrement du journal initial ou le plus ancien dans le jeu de sauvegarde. |
first_lsn |
FirstLSN |
Dernier LSN |
Numéro séquentiel dans le journal correspondant à l'enregistrement du journal suivant, après le jeu de sauvegarde. |
last_lsn |
LastLSN |
LSN du point de branchement |
Numéro séquentiel dans le journal d'un point de branchement, si le GUID du premier point de récupération n'équivaut pas (≠) au GUID du dernier point de récupération. Dans le cas contraire, aucun branchement de récupération n'intervient dans la sauvegarde et le numéro séquentiel dans le journal (LSN) du point de branchement est NULL. |
fork_point_lsn |
ForkPointLSN |
GUID de la base différentielle |
Pour une sauvegarde différentielle unique, cette valeur correspond à l'identificateur unique de la base différentielle. Pour les sauvegardes différentielles multiples, cette valeur est NULL et la base différentielle doit être déterminée au niveau des fichiers. Pour plus d'informations, consultez backupfile (Transact-SQL). Pour les types de sauvegarde non différentiels, la valeur est NULL. |
differential_base_guid |
DifferentialBaseGUID |
Le reste de cette discussion utilise uniquement les noms des valeurs dans la table d'historique backupset.
Le GUID du dernier branchement de récupération et le GUID du premier branchement de récupération sont utilisés pour s'assurer que la séquence suit le branchement correct. Pour chaque sauvegarde de journal de la séquence à restaurer, le paramètre first_recovery_fork_guid doit être égal au paramètre last_recovery_fork_guid de la sauvegarde précédente de la séquence.
.gif "first_recovery_fork_guid = last_recovery_fork_guid")
Les sauvegardes de données et différentielles doivent également être liées.
Si la sauvegarde de journal contient à la fois le dernier LSN d'une sauvegarde de base de données complète ou d'une sauvegarde de base de données différentielle et d'un point de branchement, le test de liaison dépend de l'emplacement du dernier LSN par rapport au point de branchement.
Les tests de liaison sont les suivants et reposent sur les valeurs de backupset :
Si last_lsn est inférieur ou égal à fork_point_lsn, le paramètre last_recovery_fork_guid de la sauvegarde de données ou de la sauvegarde différentielle doit être égal au paramètre first_recovery_fork_guid de la sauvegarde de journal. L'illustration suivante montre une situation au cours de laquelle last_lsn est inférieur à fork_point_lsn.
.gif "last_lsn est inférieur à fork_point_lsn")
Si last_lsn est supérieur à fork_point_lsn, le paramètre last_recovery_fork_guid de la sauvegarde de données ou de la sauvegarde différentielle doit être égal au paramètre first_recovery_fork_guid de la sauvegarde de journal. L'illustration ci-dessous montre une situation dans laquelle last_lsn est supérieur à fork_point_lsn.
.gif "last_lsn est supérieur à fork_point_lsn")
Pour une sauvegarde différentielle, recherchez la base différentielle en utilisant backupset.differential_base_guid.
Si la base de la sauvegarde différentielle est multiple, backupset.differential_base_guid est NULL, et vous devez déterminer les bases différentielles fichier par fichier en utilisant backupfile.differential_base_guid.
Voir aussi