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
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
