Sauvegarde en mode de récupération complète
Le mode de récupération complète utilise les sauvegardes de fichiers journaux pour éviter la perte de données dans les scénarios de défaillance les plus variés possibles ; il exige la sauvegarde et la restauration du journal des transactions (sauvegardes de fichiers journaux). L'avantage d'utiliser des sauvegardes de fichiers journaux est de pouvoir restaurer une base de données à n'importe quel moment dans le temps inscrit dans une sauvegarde de fichier journal (récupération jusqu'à une date et heure). Vous pouvez recourir à une série de sauvegardes de fichiers journaux pour restaurer par progression une base de données jusqu'à une date et heure figurant dans l'une des sauvegardes de fichiers journaux. N'oubliez pas que, pour réduire la durée de la restauration, vous pouvez compléter chaque sauvegarde complète par une série de sauvegardes différentielles des mêmes données.
En admettant que la sauvegarde du journal actif après un sinistre soit possible, vous pouvez restaurer la base de données jusqu'au point de défaillance sans aucune perte de données. L'inconvénient d'utiliser des sauvegardes de fichiers journaux est leur complexité accrue et le fait qu'elles nécessitent de l'espace de stockage et qu'elles augmentent le temps de restauration.
[!REMARQUE]
Si les avantages à utiliser des sauvegardes de journaux ne justifient pas le coût de gestion des sauvegardes, nous vous recommandons d'utiliser le mode de récupération simple.
Dans le cas d'une base de données employant régulièrement le mode de sauvegarde complète, vous pouvez optimiser certaines opérations en bloc en utilisant temporairement le mode de récupération utilisant les journaux de transactions. Ce mode fait l'objet de plusieurs restrictions qui le rendent incompatible avec les opérations quotidiennes. Pour plus d'informations, consultez Sauvegarde avec le mode de récupération utilisant les journaux de transactions.
Exemple de stratégie de sauvegarde
La figure ci-dessous illustre la stratégie de sauvegarde la plus simple disponible en mode de restauration complète. Dans cette illustration, une sauvegarde complète de base de données appelée Db_1 et deux sauvegardes de fichiers journaux régulières (Log_1 et Log_2) sont utilisées. Une perte de données est constatée dans la base de données peu de temps après la sauvegarde du journal Log_2. Avant de restaurer ces trois sauvegardes, l'administrateur de la base de données doit sauvegarder le journal actif (la fin du journal). Il procède ensuite à la restauration de Db_1, Log_1 et Log_2 sans récupérer la base de données. Ce n'est seulement qu'après qu'il restaure et récupère la sauvegarde du fichier journal après défaillance (fin du journal). Ceci permet de récupérer la base de données jusqu'au point de défaillance et de restituer ainsi toutes les données.
Pour plus d'informations, consultez Sauvegardes complètes de base de données et Utilisation des sauvegardes de journaux de transactions.
Réduction des risques de perte de données de travail
Au terme de la première sauvegarde complète de la base de données et après le lancement de sauvegardes de fichiers journaux régulières, le risque de perte de données de travail est limité à la période située entre l'altération de la base de données et la dernière sauvegarde de fichier journal régulière. Par conséquent, il est recommandé d'effectuer des sauvegardes de fichiers journaux suffisamment régulières pour limiter les risques de perte de données de travail en fonction des besoins de votre entreprise.
La figure suivante illustre une stratégie de sauvegarde qui permet d'ajouter des sauvegardes différentielles aux sauvegardes complètes de base de données et aux sauvegardes de fichiers journaux. Les sauvegardes des journaux de transactions limitent le risque de perte de données de travail à la période qui suit la sauvegarde de fichier journal la plus récente, t14. Une série de trois sauvegardes différentielles est effectuée pour réduire le nombre de journaux des transactions qui doivent être restaurés en cas de problème. La troisième sauvegarde différentielle est suffisamment importante pour que la prochaine sauvegarde soit une sauvegarde complète de la base de données. Ainsi se fonde une nouvelle base différentielle.
Dans la figure, avant la première sauvegarde de la base de données, cette dernière est exposée à un risque potentiel de perte des données (entre l'instant t0 et l'instant t1). En conséquence, les sauvegardes de fichiers journaux régulières réduisent le risque de perte de données de travail à la seule perte des modifications intervenues après la dernière sauvegarde de fichier journal (effectuée à l'instant t14 dans cette figure). En cas de problème après la sauvegarde la plus récente, l'administrateur de base de données peut essayer d'effectuer une sauvegarde de fichier journal après défaillance (il s'agit du journal qui n'est pas encore sauvegardé). Si cette sauvegarde de fichier journal après défaillance réussit, l'administrateur de base de données peut éviter la perte de données de travail en restaurant la base de données jusqu'au point de défaillance.
Pour plus d'informations sur les sauvegardes différentielles de base de données, consultez Utilisation des sauvegardes différentielles.
Mode de restauration complète et opérations par bloc
En consignant dans des journaux toutes les opérations, y compris les opérations en masse lancées par les instructions SELECT INTO, CREATE INDEX et celles sur des données de chargement en masse, le mode de restauration complète vous permet de récupérer une base de données jusqu'au point de défaillance ou à tout moment la précédant, appelée récupération dans le temps.
De nombreux utilisateurs du mode de restauration complète basculent temporairement en mode de récupération utilisant les journaux de transactions dans les cas où les données de chargement en masse et les performances améliorées permettent de négliger le risque de perte de données. Le mode de récupération utilisant les journaux de transactions consigne les opérations en bloc de façon minime, tout en consignant entièrement les autres transactions. Pour plus d'informations sur ce dernier mode, consultez Sauvegarde avec le mode de récupération utilisant les journaux de transactions.
[!REMARQUE]
Dans SQL Server 2005 et versions ultérieures, l'option de base de données Sélectionner dans/copier en bloc de sp_dboption n'est jamais requise et doit toujours être évitée. Utilisez ALTER DATABASE à la place. Cette procédure stockée sp_dboption sera supprimée dans une future version de SQL Server.
Utilisation des sauvegardes pour restaurer une base de données
La restauration d'une base de données fait appel à une séquence d'opérations de restauration (appelée séquence de restauration). Une séquence de restauration commence par la restauration d'au moins une sauvegarde complète suivie éventuellement d'une sauvegarde différentielle correspondante.
Chaque sauvegarde différentielle et complète contient suffisamment d'enregistrements de journaux pour vous permettre de récupérer la base de données. Cependant, il vous faut généralement restaurer l'une après l'autre les sauvegardes des journaux suivantes et terminer le processus par la sauvegarde éventuelle de fichier journal après défaillance. Par conséquent, effectuez une sauvegarde de fichier journal après défaillance avant de commencer à restaurer une base de données. La sauvegarde de fichier journal après défaillance vous permet de restaurer la base de données jusqu'au point de défaillance. À l'issue de la restauration de la dernière sauvegarde de journal, vous devez récupérer la base de données.
[!REMARQUE]
En modes de restauration complète ou de récupération utilisant les journaux de transactions, SQL Server 2005 Enterprise Edition et les versions ultérieures prennent en charge la restauration des pages ou des fichiers, ou les deux, tandis qu'une base de données est en ligne. Cette opération s'appelle une restauration en ligne. La syntaxe RESTORE permettant de restaurer les fichiers ou les pages est la même que la base de données soit en ligne ou hors connexion.
Pour plus d'informations, consultez Vue d'ensemble de la restauration et de la récupération (SQL Server).
Voir aussi