> Data > Tout sur la restauration

Tout sur la restauration

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par Kalen Delaney - Mis en ligne le 26/11/2002
Restaurer une base de données SQL Server après un sinistre est l'une des missions les plus importantes d'un administrateur système (sa, systems administrator). Pourtant, la reprise fait souvent l'objet de moins d'attention que son opération jumelle, la sauvegarde ...

La plupart des administrateurs compétents savent qu'ils doivent sauvegarder régulièrement les données critiques. Aussi, comme la sauvegarde est généralement une opération plutôt simple, ils la confient souvent à  un novice de l'équipe d'administration. Il n'y a d'ailleurs rien à  y redire, tant que le débutant en question utilise une procédure rigoureuse.

En revanche, on confie rarement à  des novices les opérations de restauration. Or, comme la restauration d'une base de données n'est pas une opération quotidienne, un administrateur de SQL Server peut fort bien gérer des bases de données pendant des années sans jamais faire une restauration d'urgence. Et donc, le jour où il doit procéder à  une restauration après un sinistre, il n'est pas préparé à  toutes les subtilités de l'opération. Des pépins inattendus dans la restauration peuvent vous obliger à  consulter SQL Server Books Online (BOL) et la Microsoft Knowledge Base pour résoudre des problèmes, pendant que toute l'entreprise attend fièvreusement de pouvoir disposer à  nouveau des données. Vous devez donc être prêt à  affronter des problèmes inattendus et vous devez tester le plan de reprise. Si vous n'avez pas encore complètement testé vos opérations de reprise en simulant un scénario catastrophe, réfléchissez à  une telle simulation dès que vous aurez fini de lire cet article. J'y passe en revue divers types d'opérations de sauvegarde, y compris des sauvegardes complètes, différentielles et du journal de transactions. Ensuite, j'explique les opérations de restauration de base et décris ce que SQL Server fait pendant qu'il restaure vos données. Dans de futurs articles, nous verrons les détails à  connaître quand on transfère une base de données dans un nouvel endroit avec des utilisateurs différents. Nous verrons aussi les problèmes posés par la restauration de tout un système SQL Server au lieu d'une simple base de données d'utilisateurs.

Malgré la simplicité de l’opération de
sauvegarde, il faut bien comprendre ce
qui se passe pendant les différents
types de sauvegarde, afin de planifier la
restauration en conséquence. La sauvegarde
consiste à  copier les données,
le journal de transactions, ou les deux,
dans un autre endroit présumé sûr. Ce
peut être un fichier disque local (que
vous copierez ensuite sur bande ou sur
un autre média), ou une bande. Vous
pouvez bien sûr copier sur un fichier
disque distant ; mais il est généralement
plus efficace d’écrire sur un fichier
local et d’utiliser les opérations
de copie de fichiers de l’OS pour transférer
le fichier sur une autre machine.
Le niveau de rapidité et d’exhaustivité
de la restauration des données sauvegardées
dépend du type de sauvegarde
effectuée et de la bonne planification
de l’opération de restauration. (Il faut,
par exemple, prévoir la quantité d’espace
nécessaire à  la restauration,
comme je l’explique dans l’encadré
« Prévoir l’espace pour une restauration
».) SQL Server 2000 permet trois
types principaux de sauvegardes : complète,
différentielle et journal.

Sauvegarde complète. Une sauvegarde
de base de données complète
copie toutes les pages d’une base de
données sur une unité de sauvegarde,
qui peut être un fichier disque local ou
en réseau, un lecteur de bande local,
ou même un tube nommé. SQL Server
copie également la portion du journal
de transactions qui était active pendant
que la sauvegarde s’exécutait.

Sauvegarde différentielle. Une
sauvegarde différentielle ne copie que
les extensions qui ont changé depuis la
dernière sauvegarde complète. SQL
Server 2000 indique rapidement
quelles extensions doivent être sauvegardées,
en examinant une page spéciale
appelée DCM (Differential
Changed Map) dans chaque fichier de
la base de données. Le DCM d’un fichier
contient un bit pour chaque extension
dans le fichier. A chaque sauvegarde
complète, tous les bits
reviennent à  zéro. Quand l’une des
pages d’une extension est modifiée, le
bit correspondant de la page dans la
page DCM est mis à  1. SQL Server copie
la portion du journal de transactions
qui était active pendant la sauvegarde.
En principe, on effectue
plusieurs sauvegardes différentielles
entre des sauvegardes complètes, et
chacune d’elles contient tous les changements
effectués depuis la dernière
sauvegarde complète.

Sauvegarde du journal. Une sauvegarde du journal de transactions
copie tous les enregistrements du log
que SQL Server a écrits depuis la dernière
sauvegarde du journal. Même si
vous avez effectué des sauvegardes de
base de données complètes, une sauvegarde
de journal contient toujours
tous les enregistrements depuis la dernière
sauvegarde de journal. Par conséquent,
vous pouvez restaurer à  partir
de n’importe quelle sauvegarde de
base de données complète à  la condition
d’avoir toutes les sauvegardes de
journaux suivantes. Toutefois, le comportement
exact de la commande BACKUP
LOG dépend du modèle de reprise
de votre base de données. S’il
s’agit d’un modèle de reprise complète,
la commande BACKUP LOG copie
tout le contenu du journal de transactions.
Dans le modèle de reprise
bulk_logged, une sauvegarde de journal
de transactions copie le contenu du
journal et toutes les extensions contenant
des pages de données que les
opérations de masse ont modifiées depuis
la dernière sauvegarde du journal.
Si la base de données utilise le modèle
de reprise simple, vous ne pouvez pas
effectuer une sauvegarde du journal
parce que celui-ci est tronqué régulièrement
et donc il ne contient aucune
information utile. Dans un scénario de
reprise classique, un administrateur effectue
une série de sauvegardes de
journal entre des sauvegardes de base de données complètes, chaque sauvegarde
du journal ne contenant que les
enregistrements du journal enregistrés
depuis la dernière sauvegarde du
journal.

SQL Server accepte des variantes
de ces types de sauvegarde de base, en
particulier des sauvegardes de fichiers
ou de groupes de fichiers, utiles en
présence de très grandes bases de données
(VLDB, very large databases).
Pour plus d’informations sur ce genre
de sauvegarde et de reprise, voir l’encadré
« Sauvegarder et restaurer des fichiers
et des groupes de fichiers ». Plus
les sauvegardes sont variées et fréquentes,
et plus il est facile de restaurer
une base de données rapidement
et complètement. Toutefois, sachez
que les opérations de restauration sollicitent
davantage SQL Server que les
sauvegardes. Dans le cas d’une restauration
complète, SQL Server doit s’assurer
que les données dans la base sont en accord avec les enregistrements
de transactions dans le journal
de transactions. L’opération consistant
à  vérifier que les données et le journal
sont en harmonie, est appelée reprise
de la base de données.

Téléchargez cette ressource

Microsoft 365 : HP Subscription Management Services en détail

Microsoft 365 : HP Subscription Management Services en détail

Collaboration à distance, environnements de travail et productivité optimisés, gestion évolutive des licences, accélérez la transformation de votre business pour le faire entrer dans l’ère de la collaboration hybride. Découvrez comment le service de gestion des abonnements HP peut vous aider à optimiser vos investissements et votre stratégie de gestion de vos abonnements Microsoft 365.

Data - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT