> Tech > Sauvegarde et restauration de fichiers et de groupes de fichiers

Sauvegarde et restauration de fichiers et de groupes de fichiers

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Quand on crée une base de données dans SQL Server 2000 et 7.0, on peut répartir les données sur plusieurs fichiers. On peut aussi créer des groupes de fichiers nommés (named filegroups) qui contiennent un ou plusieurs fichiers. Une raison pour laquelle on pourrait souhaiter utiliser des fichiers multiples et

des groupes de fichiers nommés, est que ces options permettent de créer une table dans un groupe de fichiers particulier. On ne peut pas préciser le fichier dans lequel la table sera créée, mais on peut créer un groupe de fichiers constitué d’un seul fichier. Placer une table dans ce groupe de fichiers équivaut à  la placer dans le seul fichier qu’il contient.

Quand la base de données se trouve sur des fichiers multiples ou des groupes de fichiers, SQL Server 2000 et 7.0 permettent de sauvegarder et de restaurer des fichiers individuels ou des groupes de fichiers. C’est utile dans le cas de très grandes bases de données. On peut choisir de ne sauvegarder qu’un fichier ou un groupe de fichiers chaque jour, afin de ne pas sauvegarder toute la base de données aussi souvent. La possibilité de sauvegarder et de restaurer des fichiers individuels ou des groupes de fichiers peut aussi être utile quand une défaillance isolée ne concerne qu’un lecteur et que la restauration de toute la base de données serait trop longue. Même si l’on n’a fait que des sauve-gardes de base de données complètes, on peut restaurer des groupes de fichiers individuels à  partir d’une sauvegarde complète et remplacer le fichier ou le groupe de fichiers endommagé par la copie sauvegardée.

Puisqu’il est possible de restaurer un groupe de fichiers unique, on pourrait penser qu’il est possible de ne restaurer qu’une table si elle existe dans son propre groupe de fichiers. Supposons que l’on ait créé le groupe de fichiers FG1 contenant un fichier, File1, puis qu’on ait créé une table appelée Table1 sur ce groupe de fichiers. Si quelqu’un modifie incorrectement Table1 et si l’on a une sauvegarde de base de données complète effectuée juste avant la modification, on pourrait essayer de ne restaurer que le groupe de fichiers contenant la Table1, en espérant ramener les anciennes données dans Table1. Mal-heureusement, cette méthode ne fonctionne pas. Après avoir restauré un fichier ou un groupe de fichiers, il faut également restaurer tous les journaux de transactions créés entre le dernier moment où on a sauvegardé le fichier ou le groupe de fichiers et le moment où on l’a restauré. On garantit ainsi que les fichiers restaurés sont synchronisés avec le reste de la base de données. Mais, dans ce cas, on ne veut pas que les fichiers restaurés soient synchronisés avec le reste de la base de données, parce qu’en appliquant toutes les sauvegardes du journal de transactions, on rétablira dans la Table1 toutes les modifications non intentionnelles que l’on essaie précisément d’annuler.

Même si la restauration d’un fichier ou d’un groupe de fichiers n’est pas une solution pour récupérer une table endommagée par suite d’une erreur de l’utilisateur, elle peut aider dans le cas d’une défaillance de média isolée. Supposons, par exemple, que l’on sauvegarde le groupe de fichiers FG1 à  10 heures du matin lundi. Au fur et à  mesure que les utilisateurs accèdent à  la base de données, des modifications se produisent sur les données de FG1 et SQL Server traite les transactions qui modifient les données dans FG1 et dans d’autres groupes de fichiers. On sauvegarde le journal à  16 heures et SQL Server traite d’autres transactions qui modifient les données dans FG1 et dans d’autres groupes de fichiers. Mais, à  18 heures, un support tombe en panne et on perd un ou plusieurs des fichiers qui constituent FG1.

Pour restaurer, il faut d’abord sauvegarder la queue du journal qui contient toutes les modifications survenues entre 16 heures et 18 heures. On peut ensuite restaurer le groupe de fichiers FG1 en utilisant la commande RESTORE DATABASE, en n’indiquant que le groupe de fichiers FG1. La base de données ne sera pas dans un étant cohérent parce que le FG1 restauré ne contiendra que les modifications effectuées jusqu’à  10 heures du matin, mais le reste de la base de données contiendra toutes les modifications jusqu’à  18 heures. Toutefois, SQL Server sait quand la dernière modification a été apportée à  la base de don-nées, parce que chaque page du base de données contient des informations sur le moment de sa dernière modification. Quand on restaure un groupe de fichiers, SQL Server prend note du dernier moment où chaque page de la base de données a été modifiée. On peut alors restaurer les sauvegardes du journal jusqu’à  ce que celui-ci atteigne au moins le dernier moment de changement ; dans cet exemple, on atteindra ce point quand on appliquera la sauvegarde du journal de 18 heures effectuée après le moment de la panne.

Téléchargez cette ressource

Comment lutter contre le Phishing ?

Comment lutter contre le Phishing ?

Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010