Les unités de sauvegarde

IIV 5
5Sauvegarde et restauration
Parmi les tâches assi
g
nées à un administrateur, la sauve
g
arde et la
g
estion des
j
eux de sauve
g
ardes occupent une place importante. Comme le dit l’ada
g
e, on
sait ce que l’on perd, pas ce que l’on
g
a
g
ne ! En informatique, il est clair que
la perte d’une base de données peut avoir des répercussions importantes sur le
fonctionnement d’une société.
Autant aborder la sauve
g
arde et la restauration avant de parler de sécurité ou
de distribution de données. Trois raisons motivent ce choix : tout d’abord,
montrer que ces opérations sont parmi les plus importantes du s
y
stème,
ensuite sensibiliser tout de suite aux mécanismes simples de sauve
g
arde et
enfin présenter l’or
g
anisation d’une véritable
g
estion des sauve
g
ardes.
Dans ce chapitre, nous aborderons en premier lieu les principes
g
énéraux de
la sauve
g
arde, en nous attardant à ce qu’il faut sauve
g
arder, et quand. Ensuite,
nous verrons en détail toutes les subtilités des sauve
g
ardes des bases, des
j
ournaux de transactions et des tables seules. Nous étudierons les mécanismes
de restauration des bases et surtout des
j
ournaux de transactions. Enfin, nous
conclurons sur tout ce qui peut arriver pendant une sauve
g
arde, et sur les
précautions à prendre pour que tout se passe au mieux.

Administration et maintenance
PARTIE II
216
Sauvegarde : pourquoi, comment ?
Personne n’est à l’abri d’un crash du disque dur ou d’une mauvaise manipula-
tion, qui écrase des dizaines de mé
g
a-octets de données. Que celui qui n’a
j
amais fait un DEL *.* dans le mauvais répertoire ou sur le mauvais disque,
aux temps héroïques du tout DOS, s’avance afin que
j
e le félicite. Pour se
préserver de ces erreurs, il faut sauve
g
arder ses données.
Pour éviter que tout finisse mal, SAUVEGARDEZ VOS DONNÉES !!!! Oui,
mais : quoi et quand sauve
g
arder ?
Quoi sauvegarder ?
Vous me demandez ce qu’il faut sauve
g
arder ? Mais tout, bien sûr. Non seule-
ment les bases de données que vous avez créées, mais aussi les bases s
y
stème
master, msdb et distribution si vous faites de la réplication et êtes distributeur,
ainsi que les
j
ournaux de transactions, pour tenir compte des modifications
apportées aux données.
Bien évidemment, il n’est pas question de sauve
g
arder bêtement ces bases,
sans réfléchir à une politique
g
énérale de sauve
g
arde : cela implique de déci-
der quand les sauve
g
ardes doivent avoir lieu.
Quand sauvegarder ?
Tous les
j
ours, ou presque ! N’exa
g
érons rien, tout dépend du t
y
pe de vos
bases de données.
Généralement, on se fonde sur un certain nombre de critères pour établir une
straté
g
ie de sauve
g
arde. En voici quelques-uns :
•l’indice de volatilité des données, qui indique si vos données sont
fréquemment mises à
j
our ou non. Pourquoi sauve
g
arder tous les
j
ours une
base d’infocentre qui n’est qu’en consultation ?
•l’espace alloué au
j
ournal des transactions. Si votre
j
ournal est de faible
taille, il faudra le sauve
g
arder fréquemment et le pur
g
er, tout en conser-
vant des mécanismes de tolérance de pannes ;
•la confiance que vous accordez aux bandes de sauve
g
arde ou à leur mode
de stocka
g
e. Plus vous faites confiance aux bandes, moins vous sauve
g
ar-
dez. Mais attention, ces choses-là ne devraient pas inspirer confiance.
Méfiez-vous en comme de la peste. Qu’
y
a-t-il d’aussi peu fiable qu’une
bande ?

Sauvegarde et restauration
CHAPITRE V
217
•le temps imparti aux sauve
g
ardes. Si vous n’avez pas le temps de sauve-
g
arder votre base pendant la nuit, car ladite sauve
g
arde prend plus de
12 heures, il faut penser à une politique de sauve
g
arde plus
j
udicieuse.
De manière
g
énérale, sauve
g
ardez vos bases de données toutes les semaines,
y
compris master, msdb et distribution.
Souvenez-vous que master est la clé de voûte de SQL Server. Si vous en
faites une sauve
g
arde hebdomadaire, vous prévenez les risques de crash du
disque. En effet, vous serez à nouveau opérationnel rapidement en remontant
l’une des sauve
g
ardes de master et de vos bases de données.
En rè
g
le
g
énérale, il est préférable, pour une base transactionnelle, d’adopter
un plan de sauve
g
arde incrémental, comme celui-ci :.
La sauve
g
arde du mardi ne contient donc que les transactions survenues
depuis la sauve
g
arde du
j
ournal du lundi. Puis, le dimanche suivant, on refait
une sauve
g
arde complète de la base. Ensuite, les
j
eux de sauve
g
ardes sont
permutés de façon à n’en conserver que deux ou trois.
Si le nombre d’utilisateurs est important et qu’ils font de nombreuses modifi-
cations, on peut être amené à sauve
g
arder le
j
ournal plusieurs fois par
j
our, et
de ce fait, à réaliser la sauve
g
arde, complète ou différentielle de la base, tous
les
j
ours.
L’intérêt de cette dernière méthode de sauve
g
arde est double : d’une part,
sauve
g
arder le
j
ournal est infiniment plus rapide que sauve
g
arder la base,
d’autre part, sauve
g
arder le
j
ournal le vide et contribue donc à ne conserver
en permanence qu’un
j
ournal de faible volume. Enfin la sauve
g
arde différen-
Figure 5–1
Exemple de planning de sauvegarde incrémentale

Administration et maintenance
PARTIE II
218
tielle est plus rapide qu’une sauve
g
arde complète, puisqu’elle ne contient que
les pa
g
es de la base modifiées depuis la dernière sauve
g
arde complète, et elle
contribue à accélérer les restaurations, comme nous le verrons un peu plus
loin dans ce chapitre.
Soyez rusé!
Dans tous les cas, si la sauvegarde de votre base de données est rapide, de quel-
ques minutes à quelques heures, et qu’elle peut se faire de nuit, je vous conseille
de sauvegarder le journal plusieurs fois par jour et la base tous les jours. Cette
stratégie de sauvegarde, d’une part, minimise le risque de perte d’informations et,
d’autre part, garantit que le journal garde une taille gérable dans la journée.
Principes généraux
Pour faire des sauve
g
ardes avec SQL Server, vous devez créer des unités de
sauve
g
arde. Elles peuvent accueillir indifféremment les sauve
g
ardes complè-
tes et différentielles des bases de donnée et celles des
j
ournaux de transac-
tions. Une fois l’unité créée, vous pouvez sauve
g
arder une ou plusieurs bases,
mélan
g
er bases et
j
ournaux, ou encore écraser les anciennes sauve
g
ardes par
une nouvelle. Une base —un
j
ournal, un fichier ou un
g
roupe de fichiers —
peut é
g
alement être sauve
g
ardée sur plusieurs unités, en parallèle ; chaque
unité en contiendra une portion. La réunion de ces unités permettra donc de
restaurer la base. Cette fonctionnalité propre à SQL Server permet d’accélérer
de manière si
g
nificative les sauve
g
ardes1.
La démarche est simple : créer les unités, sauve
g
arder, puis restaurer en cas
de problème.
Figure 5–2
Exemple de planning de sauvegarde différentielle et incrémentale

Sauvegarde et restauration
CHAPITRE V
219
Soyez rusé!
Une stratégie d’accélération des sauvegardes, quand vous ne disposez pas de
lecteur de bande rapide (comme les lecteurs DLT – Digital Linear Tape) consiste
à sauvegarder les bases dans des unités sur disques (c’est-à-dire dans des
fichiers), puis de sauvegarder ces fichiers grâce au gestionnaire de sauvegardes de
Windows 2000 ou de tout autre logiciel approprié.
Attention : il n’est pas possible de sauvegarder directement les fichiers de bases
de données avec le gestionnaire de sauvegarde de Windows 2000. En effet, dans
la mesure où SQL Server en a l’utilisation exclusive, Windows 2000 ne peut y
accéder, à moins d’arrêter le serveur SQL.
Les unités de sauvegarde
Avant de se lancer dans la
p
remière sauve
g
arde, il est
p
référable de créer au
moins une ou
p
lusieurs unités
p
ermanentes de sauve
g
arde.
Les différents types d’unités
Il existe
p
lusieurs t
yp
es d’unités, re
g
rou
p
ant les différents media standards de
stocka
g
e informati
q
ue :
•bande ;
•dis
q
ue ;
•dis
q
ue réseau ;
•canal nommé.
Les trois
p
remiers t
yp
es sont accessibles de
p
uis l’interface
g
ra
p
hi
q
ue. Pour ce
q
ui est du dernier, on ne
p
eut créer l’unité
q
u’à
p
artir de la
p
rocédure stockée
sp_addumpdevice.
Unités sur bande
SQL Server n’acce
p
te
q
ue les lecteurs de bandes locaux, c’est-à-dire connec-
tés directement sur la machine et reconnus
p
ar Windows 2000. Il n’est donc
p
as
p
ossible de lancer une sauve
g
arde sur un lecteur de bandes en réseau, à
moins d’utiliser un lo
g
iciel de sauve
g
arde comme ARCSERVE ou
BACKUPEXEC avec l’a
g
ent adé
q
uat.
1. En test, j’ai réussi à sauvegarder une base de 30 giga-octets sur deux lecteurs de bandes DLT en
moins d’une demi-heure. On peut mieux faire, mais c’est plus cher !