IIV 5

5Sauvegarde et restauration

Parmi les tâches assignées à un administrateur, la sauvegarde et la gestion des

jeux de sauvegardes occupent une place importante. Comme le dit l’adage, on
sait ce que l’on perd, pas ce que l’on gagne ! 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 sauvegarde 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 système,
ensuite sensibiliser tout de suite aux mécanismes simples de sauvegarde et
enfin présenter l’organisation d’une véritable gestion des sauvegardes.
Dans ce chapitre, nous aborderons en premier lieu les principes généraux de
la sauvegarde, en nous attardant à ce qu’il faut sauvegarder, et quand. Ensuite,
nous verrons en détail toutes les subtilités des sauvegardes des bases, des
journaux de transactions et des tables seules. Nous étudierons les mécanismes
de restauration des bases et surtout des journaux de transactions. Enfin, nous
conclurons sur tout ce qui peut arriver pendant une sauvegarde, et sur les
précautions à prendre pour que tout se passe au mieux.
 Administration et maintenance
216
PARTIE II

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éga-octets de données. Que celui qui n’a
jamais 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 je le félicite. Pour se
préserver de ces erreurs, il faut sauvegarder ses données.
Pour éviter que tout finisse mal, SAUVEGARDEZ VOS DONNÉES !!!! Oui,
mais : quoi et quand sauvegarder ?

Quoi sauvegarder ?
Vous me demandez ce qu’il faut sauvegarder ? Mais tout, bien sûr. Non seule-
ment les bases de données que vous avez créées, mais aussi les bases système
master, msdb et distribution si vous faites de la réplication et êtes distributeur,
ainsi que les journaux de transactions, pour tenir compte des modifications
apportées aux données.
Bien évidemment, il n’est pas question de sauvegarder bêtement ces bases,
sans réfléchir à une politique générale de sauvegarde : cela implique de déci-
der quand les sauvegardes doivent avoir lieu.

Quand sauvegarder ?
Tous les jours, ou presque ! N’exagérons rien, tout dépend du type de vos
bases de données.
Généralement, on se fonde sur un certain nombre de critères pour établir une
stratégie de sauvegarde. En voici quelques-uns :
• l’indice de volatilité des données, qui indique si vos données sont
fréquemment mises à jour ou non. Pourquoi sauvegarder tous les jours une
base d’infocentre qui n’est qu’en consultation ?
• l’espace alloué au journal des transactions. Si votre journal est de faible
taille, il faudra le sauvegarder fréquemment et le purger, tout en conser-
vant des mécanismes de tolérance de pannes ;
• la confiance que vous accordez aux bandes de sauvegarde ou à leur mode
de stockage. Plus vous faites confiance aux bandes, moins vous sauvegar-
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
217
CHAPITRE V

• le temps imparti aux sauvegardes. Si vous n’avez pas le temps de sauve-

garder votre base pendant la nuit, car ladite sauvegarde prend plus de
12 heures, il faut penser à une politique de sauvegarde plus judicieuse.
De manière générale, sauvegardez 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 sauvegarde hebdomadaire, vous prévenez les risques de crash du
disque. En effet, vous serez à nouveau opérationnel rapidement en remontant
l’une des sauvegardes de master et de vos bases de données.
En règle générale, il est préférable, pour une base transactionnelle, d’adopter
un plan de sauvegarde incrémental, comme celui-ci :.

Figure 5–1
Exemple de planning de sauvegarde incrémentale

La sauvegarde du mardi ne contient donc que les transactions survenues

depuis la sauvegarde du journal du lundi. Puis, le dimanche suivant, on refait
une sauvegarde complète de la base. Ensuite, les jeux de sauvegardes 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é à sauvegarder le journal plusieurs fois par jour, et
de ce fait, à réaliser la sauvegarde, complète ou différentielle de la base, tous
les jours.
L’intérêt de cette dernière méthode de sauvegarde est double : d’une part,
sauvegarder le journal est infiniment plus rapide que sauvegarder la base,
d’autre part, sauvegarder le journal le vide et contribue donc à ne conserver
en permanence qu’un journal de faible volume. Enfin la sauvegarde différen-
 Administration et maintenance
218
PARTIE II

Figure 5–2
Exemple de planning de sauvegarde différentielle et incrémentale

tielle est plus rapide qu’une sauvegarde complète, puisqu’elle ne contient que
les pages de la base modifiées depuis la dernière sauvegarde 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 sauvegardes avec SQL Server, vous devez créer des unités de
sauvegarde. Elles peuvent accueillir indifféremment les sauvegardes complè-
tes et différentielles des bases de donnée et celles des journaux de transac-
tions. Une fois l’unité créée, vous pouvez sauvegarder une ou plusieurs bases,
mélanger bases et journaux, ou encore écraser les anciennes sauvegardes par
une nouvelle. Une base — un journal, un fichier ou un groupe de fichiers —
peut également être sauvegardé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 significative les sauvegardes1.
La démarche est simple : créer les unités, sauvegarder, puis restaurer en cas
de problème.
 Sauvegarde et restauration
219
CHAPITRE V

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 première sauvegarde, il est préférable de créer au
moins une ou plusieurs unités permanentes de sauvegarde.

Les différents types d’unités

Il existe plusieurs types d’unités, regroupant les différents media standards de
stockage informatique :
• bande ;
• disque ;
• disque réseau ;
• canal nommé.
Les trois premiers types sont accessibles depuis l’interface graphique. Pour ce
qui est du dernier, on ne peut créer l’unité qu’à partir de la procédure stockée
sp_addumpdevice.

Unités sur bande

SQL Server n’accepte que les lecteurs de bandes locaux, c’est-à-dire connec-
tés directement sur la machine et reconnus par Windows 2000. Il n’est donc
pas possible de lancer une sauvegarde sur un lecteur de bandes en réseau, à
moins d’utiliser un logiciel de sauvegarde comme ARCSERVE ou
BACKUPEXEC avec l’agent adéquat.

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 !
 Administration et maintenance
220
PARTIE II

Avant de créer une unité de sauvegarde sur bande, on doit installer le pilote du
lecteur de bandes dans Windows 2000. Par défaut, cette unité aura pour nom
\\.\TAPE0. S’il y en a plusieurs sur la même machine, elles s’appelleront
\\.\TAPE1, \\.\TAPE2, et ainsi de suite.
Il est possible de sauvegarder plusieurs bases sur une seule bande, ainsi
qu’une base sur plusieurs bandes. De plus avec le nouveau format de sauve-
garde sur bande (MSTF, Microsoft Tape Format), il est possible de grouper
sauvegardes Windows et SQL sur la même bande.

Unité sur disque

La création d’une unité sur disque se résume en fait à la création d’un fichier
local ou d’un fichier situé sur un répertoire partagé distant. Le fichier n’est
créé qu’au moment de la première sauvegarde sur cette unité.
Dans le cas d’une unité sur disque réseau, on peut (et c’est préférable) utiliser
un nom UNC (Universal Naming Convention), par exemple,
\\GODZILLA\SAUVESQL\PLANNING.BAK, pour sauvegarder dans le répertoire
partagé SAUVESQL du serveur GODZILLA.
Bien évidemment, la sauvegarde sur une unité réseau est subordonnée au fait
que le disque distant soit en marche et accessible.

Unités de canal nommé

Cette fonctionnalité est proposée pour permettre la connexion de logiciels de
sauvegarde. Il est alors possible de faire des sauvegardes sur des unités de
bande se trouvant sur le réseau ou sur des périphériques particuliers. La diffé-
rence majeure avec les autres types d’unités est qu’elles ne possèdent pas de
nom logique. Le canal est appelé pendant la sauvegarde ou la restauration
(voir les instructions BACKUP et RESTORE, plus loin dans ce chapitre).

La création des unités

La création d’une unité peut se faire depuis SQL Enterprise Manager ou
depuis Transact-SQL. Avec SQL Enterprise Manager, on ne peut créer que
des unités sur disque ou sur bande.

Création avec SQL Enterprise Manager

Voici les étapes de création d’une unité depuis SQL Enterprise Manager :
1. Depuis SQL Enterprise Manager, ouvrir le dossier Gestion ;
 Sauvegarde et restauration
221
CHAPITRE V

2. Sur l’icône Sauvegarde, cliquer avec le bouton droit de la souris et sélec-

tionner la commande Nouvelle unité de sauvegarde : la fenêtre de créa-
tion d’une unité apparaît (figure 5–3) ;

Figure 5–3
Création d’une unité de sauvegarde

3. Dans la zone Nom, donner le nom de l’unité de sauvegarde ;

4. Dans la zone Nom de fichier ou Nom du lecteur de bande, donner le nom
physique de l’unité.
Dans le cas d’unités sur disque, donner le nom du fichier avec son chemin
complet. Exemple : G:\BACKUP\MABASE.BAK.
Dans le cas d’unités sur disque réseau, indiquer le nom du fichier avec son
chemin, par exemple : \\GODZILLA\BACKUP\MABASE.BAK. Il est préférable
de donner un nom UNC plutôt que d’utiliser une lettre de lecteur logique,
celle-ci pouvant changer au redémarrage de la machine.
Dans le cas d’unités sur bande, donner le nom de la bande conforme à sa
définition dans le gestionnaire de bande de Windows 2000, par exemple :
\\.\TAPE0. S’il y a plusieurs lecteurs de bandes sur la machine, ils sont
identifiés par leur numéro (TAPE0, TAPE1, TAPE2...).
5. Cliquer sur le bouton OK. L’unité est créée.

Important
Dans le cas d’une sauvegarde sur disque, si vous allez voir sur le disque où se
trouve le fichier, vous constaterez qu’il n’existe pas, contrairement aux fichiers de
base de données. Ce fichier ne sera créé que lors de la première sauvegarde.

Création avec Transact-SQL

Il existe une instruction permettant de créer tout type d’unité (à part les unités
de canaux nommés) : sp_addumpdevice.
 Administration et maintenance
222
PARTIE II

Syntaxe

sp_addumpdevice [@devtype =] 'type_d’unité',

[@logicalname =] 'nom_logique',
[@physicalname =] 'nom_physique'
[, { [@cntrltype =] type_de_contrôleur | [@devstatus =] 'état_unité' } ]

Exemple :
sp_addumpdevice 'disk', 'SAUVEMABASE', 'C:\MSSQL\BACKUP\MABASE.BAK'
crée une unité de sauvegarde sur disque appelée MABASE.BAK.

La maintenance des unités

Comme pour tout composant du serveur, il est possible d’éditer l’état et le
contenu d’une unité et, bien évidemment, de la supprimer.

Éditer le contenu d’une unité

Une unité va contenir une ou plusieurs sauvegardes de bases de données, de
journaux de transaction et de tables. Le moyen le plus simple est de passer par
SQL Enterprise Manager. Une fois l’unité créée, elle apparaît dans la liste des
unités dans le dossier Sauvegarde.
Faire un clic droit sur l’unité dont on souhaite éditer le contenu et choisir
Propriétés, ou double-cliquer sur le nom de l’unité : la fenêtre de Propriétés
apparaît (figure 5–4).

Figure 5–4
Propriétés d’une unité de sauvegarde

Appuyer sur le bouton Afficher le contenu pour visualiser le contenu de

l’unité sélectionnée (figure 5–5).
 Sauvegarde et restauration
223
CHAPITRE V

Figure 5–5
Contenu d’une unité de sauvegarde

On peut également obtenir des informations sur une unité de sauvegarde à

partir de la fenêtre Restauration de la base de données. Nous reviendrons sur
les informations contenues dans cette fenêtre et sur leur interprétation, plus
loin dans ce chapitre.

Figure 5–6
Contenu d’une unité de sauvegarde depuis la fenêtre Restauration

Enfin, pour obtenir des informations sous forme de texte, on peut utiliser la
procédure stockée système sp_helpdevice, qui interroge la table
master..sysdevices.

Syntaxe

sp_helpdevice [[@devname=] 'nom']

Le tableau 5–1 montre le résultat obtenu en exécutant cette procédure sans

paramètres. Dans la mesure où la table sysdevices contient la référence des
unités de base de données et celle des unités de sauvegarde, le résultat de
sp_helpdevice contient la liste de toutes les unités.
 Administration et maintenance
224
PARTIE II

Tableau 5–1
Résultat de sp_helpdevice

device_name physical_name description status cntrltype size

master C:\Program Files\Microsoft SQL special, physical 2 0 512

Server\MSSQL\data\master.mdf disk, 4 MB

mastlog C:\Program Files\Microsoft SQL special, physical 2 0 128

Server\MSSQL\data\mastlog.ldf disk, 0.8 MB

modeldev C:\Program Files\Microsoft SQL special, physical 2 0 80

Server\MSSQL\data\model.mdf disk, 0.6 MB

modellog C:\Program Files\Microsoft SQL special, physical 2 0 96

Server\MSSQL\data\modellog.ldf disk, 0.8 MB

tempdev C:\Program Files\Microsoft SQL special, physical 2 0 256

Server\MSSQL\data\tempdb.mdf disk, 2 MB

templog C:\Program Files\Microsoft SQL special, physical 2 0 64

Server\MSSQL\data\templog.ldf disk, 0.5 MB

Supprimer une unité de sauvegarde

Supprimer une unité de sauvegarde ne supprime pas le fichier physique asso-
cié, mais simplement sa référence dans la table sysdevices. Pour supprimer, en
mode graphique, une unité de sauvegarde, il suffit, à partir du dossier Sauve-
garde de SQL Enterprise Manager, de sélectionner le nom de l’unité et
d’appuyer sur la touche SUPPR ou de choisir Supprimer dans le menu contex-
tuel. À partir de Transact-SQL, utiliser la procédure système sp_dropdevice.

Syntaxe

sp_dropdevice [@logicalname =] 'unité'

[, [@delfile =] 'suppr_fichier']

La sauvegarde
Lorsque les unités sont créées, on peut passer à la sauvegarde des informa-
tions. SQL Server 2000 permet de sauvegarder cinq types de composants :
• la base de données complète ;
• la base de données en mode différentiel ;
• le journal des transactions ;
 Sauvegarde et restauration
225
CHAPITRE V

• un fichier ;
• un groupe de fichiers.
L’une des fonctionnalités les plus puissantes de SQL Server concerne la
possibilité de sauvegarder une base, alors même qu’elle est en cours
d’utilisation : il s’agit du mécanisme de sauvegarde dynamique.

Sauvegarde dynamique
Il n’est pas nécessaire d’arrêter l’exploitation d’une base de données pour en
faire la sauvegarde. En effet, le mécanisme de sauvegarde dynamique donne
la possibilité de la sauvegarder alors que des utilisateurs y sont connectés.
Pour comprendre comment cela est possible, il nous faut revenir sur la struc-
ture interne d’une base de données SQL Server. Toutes les informations sont
stockées dans des pages de 8 kilo-octets, que SQL Server sauvegarde, dans
l’ordre du fichier, que les pages aient été modifiées ou non depuis le début de
la sauvegarde. Mais sauvegarder une page modifiée, alors que la transaction
qui la modifie n’est pas terminée, est une opération dangereuse. En effet, si la
transaction échoue, les données modifiées doivent revenir dans l’état précé-
dant la modification. C’est pourquoi, le système sauvegarde le journal des
transactions en même temps que la base de données.
Le schéma ci-dessous résume ce fonctionnement (figure 5–7).

Figure 5–7
Mécanisme de sauvegarde d’une base de données

Pendant la sauvegarde de la base, SQL Server capture les pages de données

directement sur le disque sans chercher à savoir si ces pages sont cohérentes
ou non. La sauvegarde de la base seule est donc incohérente, s’il y a une acti-
vité sur le système. Pour assurer la cohérence de la sauvegarde, SQL Server
enregistre la portion du journal des transactions correspondant à la période de
 Administration et maintenance
226
PARTIE II

sauvegarde. Ainsi, si la base doit être restaurée, SQL Server rejouera le jour-
nal qu’il a sauvegardé en même temps que la base pour ramener les données
dans un état cohérent. Dans ce cas, à la différence de la sauvegarde du journal
des transactions seul, celui-ci n’est pas purgé.

Sauvegarde complète de la base de données

La première chose à sauvegarder est la base elle-même : cela assure qu’en cas
de crash, on pourra revenir à la dernière sauvegarde pour restaurer les structu-
res et les données. Une sauvegarde complète est le point de références des
sauvegardes de journaux et différentielles ultérieures.

Sauvegarder avec SQL Enterprise Manager

Pour sauvegarder la base avec SQL Enterprise Manager, il est préférable
d’avoir créé une ou plusieurs unités de sauvegarde. Ensuite, rien n’est plus
simple.
1. Dans SQL Enterprise Manager, sélectionner le serveur sur lequel se trouve
la base à sauvegarder.
2. Sélectionner la base et dans le menu Outils, choisir Sauvegarder la base
de données (on peut aussi obtenir cette commande via le menu contex-
tuel, sur le dossier de la base de données). La fenêtre de sauvegarde appa-
raît alors (figure 5–8).

Figure 5–8
Boîte de dialogue de sauvegarde d’une base de données
 Sauvegarde et restauration
227
CHAPITRE V

3. Dans la liste Base de données, sélectionner la base à sauvegarder.

4. Choisir le type de sauvegarde dans la zone Sauvegarde. Souvenez-vous
qu’il faut impérativement commencer par une sauvegarde complète de la
base de données avant de sauvegarder le journal ou de faire une sauve-
garde différentielle.
5. Dans la zone Destination, ajouter la ou les unités dans lesquelles on
souhaite sauvegarder la base, en cliquant sur le bouton Ajouter. Si l’on
souhaite effectuer une sauvegarde en agrégat (c’est-à-dire sur plusieurs
unités simultanément), indiquer les unités les unes après les autres.

Figure 5–9
Sélection d’une unité de sauvegarde

6. Si l’on souhaite écraser le contenu d’une ou des unités sélectionnées,

cocher le bouton Remplacer le support existant.
7. Choisir éventuellement les options de sauvegarde, telles la vérification de
la sauvegarde2 ou la date d’expiration du jeu de sauvegarde (figure 5–10).
8. Si l’unité sélectionnée est une bande, on peut choisir d’Éjecter la bande
après sauvegarde.

9. Cliquer sur le bouton OK pour lancer la sauvegarde.

Soyez rusé !
La sauvegarde est une opération qui bloque l’interface graphique de
SQL Enterprise Manager. Donc, pendant qu’elle s’exécute, il ne vous reste plus
qu’à regarder le curseur d’avancement !
Pour éviter cela, cochez la case Planification, puis cliquez sur le bouton contenant
trois points de la zone Planification. La boîte de planification de la sauvegarde
apparaît alors. Cochez la case Une fois et sélectionnez une planification dans
quelques minutes, puis cliquez sur le bouton OK. Le système revient à la fenêtre

2. Dans la boîte de dialogue, Vérifier que la sauvegarde est terminée est une erreur de traduction. Il faut
lire Vérification du jeu de sauvegarde à la fin de l’opération de sauvegarde.
 Administration et maintenance
228
PARTIE II

Figure 5–10
Sélection des options de sauvegarde

de sauvegarde de la base de données, que vous pouvez fermer en cliquant sur le

bouton OK. Votre sauvegarde va se dérouler à l’arrière-plan à l’heure indiquée. De
plus, vous avez créé une tâche que vous pouvez invoquer à tout moment.

Sauvegarder avec Transact-SQL

La sauvegarde avec le code, bien que plus contraignante (il faut taper la tota-
lité de la commande), est beaucoup plus souple en termes de fonctionnalités.

Syntaxe

BACKUP DATABASE {nom_base | @var_nom_base}

TO <unité_sauvegarde> [,...n]
[WITH
[BLOCKSIZE = {taille_bloc | @var_taille_bloc}]
[[,] DESCRIPTION = {texte | @var_texte}]
[[,] DIFFERENTIAL]
[[,] EXPIREDATE = {date | @var_date}
| RETAINDAYS = {jours | @var_jours}]
[[,] PASSWORD = { mot_de_passe | @var_mot_de_passe } ]
[[,] FORMAT | NOFORMAT]
[[,] {INIT | NOINIT}]
[[,] MEDIADESCRIPTION = {texte | @var_texte}]
[[,] MEDIANAME = {nom_support | @var_nom_support}]
[[,] MEDIAPASSWORD = { mot_de_passe_media | @var_mot_de_passe_media } ]
[[,] [NAME = {nom_jeu_sauve | @var_nom_jeu_sauve}]
[[,] {NOSKIP | SKIP}]
[[,] {NOREWIND | REWIND} ]
 Sauvegarde et restauration
229
CHAPITRE V

[[,] {NOUNLOAD | UNLOAD}]

[[,] [RESTART]
[[,] STATS [= pourcentage]]

Exemple :
BACKUP DATABASE mabase TO sauvemabase
sauvegarde la base mabase dans l’unité sauvemabase.

Le paramètre unité_sauvegarde de l’instruction BACKUP peut prendre les

valeurs suivantes :
• nom de l’unité de sauvegarde ;
• variable contenant le nom de l’unité de sauvegarde ;
• {DISK | TAPE | PIPE} = nom de l’unité physique.
Si l’on souhaite faire une sauvegarde sans créer d’unité de sauvegarde au
préalable, on peut se servir de la troisième valeur. Par exemple, pour sauve-
garder dans un fichier appelé C:\BACKBASE.BAK, il suffit d’exécuter la ligne
suivante :

BACKUP DATABASE MABASE TO DISK='C:\BACKBASE.BAK'.

Voici la description exhaustive des options disponibles :

• BLOCKSIZE : il s’agit de la taille de bloc à utiliser. Cette taille est fonction
du type d’unité de bande utilisée. SQL Server détecte automatiquement le
type de bande et y adapte la taille de bloc. À moins d’y être invité par le
fabricant du lecteur de bande, ne modifiez pas ce paramètre qui a des
répercutions importantes sur la vitesse de sauvegarde. De plus, il faut utili-
ser cette option conjointement avec FORMAT pour formater la bande avec
la taille de bloc définie ;
• DESCRIPTION, MEDIADESCRIPTION, MEDIANAME : DESCRIPTION donne la
description du jeu de sauvegarde, alors que MEDIADESCRIPTION et MEDIA-
NAME donnent la description et le nom du média sur lequel se fait la
sauvegarde ;
• EXPIREDATE={date|@var_date} : précise une date au-delà de laquelle la
sauvegarde est considérée comme obsolète et peut être écrasée. Cette
option ne peut être employée que pour les unités sur bande ou sur disque,
avec le paramètre INIT ;
• FORMAT | NOFORMAT : invalide tout le contenu de l’unité de sauvegarde.
Cette option valide implicitement INIT et va plus loin que cette dernière
option puisque le contenu de la bande est alors totalement écrasé, qu’il
existe un mot de passe ou non ;
 Administration et maintenance
230
PARTIE II

• MEDIAPASSWORD : permet de protéger le support de sauvegarde par un

mot de passe ;
• INIT | NOINIT : précise s’il faut ou non initialiser la bande avant la sauve-
garde. Cependant, s’il existe d’autres jeux de sauvegardes sur le bande qui
ne sont pas arrivés à expiration, ils ne sont pas impactés par cette option ;
• UNLOAD | NOUNLOAD : spécifie s’il faut ou non décharger la bande en fin
de sauvegarde ;
• PASSWORD : permet de protéger le jeu de sauvegarde par un mot de passe
qui sera demandé à chaque restauration ultérieure ;
• RETAINDAYS={jours|@var_jours} : donne le nombre de jours pendant
lesquels la sauvegarde ne peut pas être écrasée. Comme EXPIREDAYS, cette
option n’est utilisée qu’avec les unités sur bande ou sur disque avec le
paramètre INIT ;
• STATS : définit la fréquence des messages en pourcentage de pages sauve-
gardées. Si vous ne renseignez pas ce paramètre, sa valeur est 10, c’est-à-
dire que vous recevrez 10 messages pendant la sauvegarde (de 0 à 100%) ;
• RESTARTS : indique que la sauvegarde précédente a échoué et qu’il faut la
redémarrer là où elle s’est arrêtée.
• REWIND | NOREWIND : spécifie s’il faut ou non fermer la bande après la
sauvegarde. NOREWIND implique NOUNLOAD ;
• SKIP | NOSKIP : indique s’il faut lire ou non l’en-tête des bandes contenant
le nom et la date d’expiration du jeu de sauvegarde ;
• STATS : définit la fréquence des messages en pourcentage de pages sauve-
gardées. Si vous ne renseignez pas ce paramètre, sa valeur est 10, c’est-à-
dire que vous recevrez 10 messages pendant la sauvegarde (de 0 à 100%).
La sauvegarde d’une base de données sauve tous les objets et toutes les
données de la base, ainsi que toutes les modifications validées pendant la
sauvegarde. Cela signifie que si l’on effectue une sauvegarde de la base alors
que plusieurs utilisateurs sont au travail, la sauvegarde contient le reflet exact
de l’état réel de la base à la fin de la sauvegarde.

Sauvegarde du journal des transactions

Une transaction est définie par quatre caractéristiques : Atomique, Cohérente,
Isolée, Durable (ACID). Voir « Transactions », page 54. Le journal des tran-
sactions permet de s’assurer de la durabilité des transactions.
Il peut être sauvegardé indépendamment de la base de données. C’est en fait
une double opération : outre son enregistrement sur disque, bande ou canal
 Sauvegarde et restauration
231
CHAPITRE V

nommé, le journal est purgé des transactions validées (ce que l’on appelle sa
partie inactive). La sauvegarde est donc un mécanisme qui ne conserve qu’un
journal des transactions de faible volume.

Sauvegarder avec SQL Enterprise Manager

Avec SQL Enterprise Manager, la sauvegarde du journal se déroule comme la
sauvegarde d’une base de données. Cependant, il n’est pas possible de passer
tous les paramètres spécifiques des journaux de transactions comme avec
Transact-SQL.

Sauvegarder avec Transact-SQL

La syntaxe est similaire à celle qui sert à sauvegarder une base de données,
mais on dispose de trois options supplémentaires, spécifiques des journaux.
Comme avec BACKUP DATABASE, l’unité de sauvegarde peut être une unité
existante ou une variable contenant un nom d’unité ou un nom d’unité physi-
que.

Syntaxe

BACKUP LOG {nom_base_de_données | @var_nom_base_de_données}

{
[WITH { NO_LOG | TRUNCATE_ONLY }]
}
|
{
TO <unité_sauvegarde> [,...n]
[WITH
[BLOCKSIZE = {taille_bloc | @var_taille_bloc}]
[[,] DESCRIPTION = {texte | @var_texte}]
[[,] EXPIREDATE = {date | @var_date}
| RETAINDAYS = {jours | @var_jours}]
[[,] PASSWORD = { mot_de_passe | @var_mot_de_passe } ]
[[,] FORMAT | NOFORMAT]
[[,] {INIT | NOINIT}]
[[,] MEDIADESCRIPTION = {texte | @var_texte}]
[[,] MEDIANAME = {nom_support | @var_nom_support}]
[[,] MEDIAPASSWORD = { mot_de_passe_media | @var_mot_de_passe_media } ]
[[,] [NAME = {nom_jeu_sauve | @var_nom_jeu_sauve}]
NO_TRUNCATE
[[,] {NOREWIND | REWIND} ]
[[,] {NOSKIP | SKIP}]
[[,] {NOUNLOAD | UNLOAD}]
[[,] [RESTART]
[[,] STATS [= pourcentage]]
]
}
 Administration et maintenance
232
PARTIE II

Exemple :
BACKUP LOG Mabase TO Sauvelog
sauvegarde le journal de la base mabase dans l’unité Sauvelog.

Truncate_only
Cette option permet de vider la partie inactive du journal sans la sauvegarder.
Bien évidemment, cette opération est risquée sur un site de production
puisqu’on perd la capacité de recharger une sauvegarde de la base et des jour-
naux. Elle sert surtout au cours des phases de développement ou de test,
pendant lesquelles les journaux n’ont pas besoin d’être conservés.
Toutes les modifications faites depuis la dernière synchronisation sont
perdues corps et biens : sauvegardez donc toujours la base après un BACKUP
LOG WITH TRUNCATE_ONLY. Il n’est pas nécessaire de préciser le nom d’une
unité de sauvegarde, puisque le journal n’est pas sauvegardé. Un exemple ?
En voici un : backup log mabase with truncate_only.

Important
Après un BACKUP LOG WITH TRUNCATE_ONLY, il faut faire une sauvegarde de la
base de données : sinon, on ne pourra pas faire d’autres BACKUP LOG.

No_log
Comme TRUNCATE_ONLY, NO_LOG vide le journal. La différence concerne
l’enregistrement dans le journal. Sans l’option NO_LOG, BACKUP LOG est une
transaction inscrite dans le journal ; avec cette option, BACKUP LOG vide la
partie inactive du journal et n’enregistre pas le fait que le journal a été vidé.
NO_LOG est l’option à utiliser si le journal est saturé. On ne peut rien faire
d’autre ! Il faut d’abord vider le journal avant de continuer à travailler. Bien
évidemment, pensez à faire une sauvegarde de la base immédiatement après
(en priant que tout se passe bien !).

No_truncate
Attention : ne pas confondre NO_TRUNCATE avec TRUNCATE_ONLY ou
NO_LOG. Cette option sert lorsque la base est suspecte, et que le journal de
transactions est accessible.
Si la base est suspecte — défaillance du disque sur lequel elle est stockée, par
exemple —, il est impossible de sauvegarder le journal normalement. Avec
cette option, on peut faire une sauvegarde du journal, ce qui permettra de
recharger la base et les journaux jusqu’au moment de la défaillance.
 Sauvegarde et restauration
233
CHAPITRE V

Pour que cette opération soit possible, master doit être accessible. Si, par
malheur, master et la base de données se trouvaient sur le même disque
défaillant, il ne vous reste que les yeux pour pleurer sur la dépouille des tran-
sactions perdues.

Important
Dans SQL Server 7, si le fichier .MDF de la base de données n’est pas accessible,
on ne peut pas sauvegarder le journal avec l’option NO_TRUNCATE. On obtient les
messages d’erreurs 3446 et 3013 qui indiquent que la sauvegarde a échoué.
Microsoft a confirmé le problème (note Q218739 du TechNet) sans apporter de
solutions autre que la protection du fichier .MDF par du RAID 1 ou 5. Ce dysfonc-
tionnement a été corrigé dans SQL Server 2000 : il est donc possible de sauvegar-
der le journal des transactions, même si le fichier .mdf n’est pas accessible.

Sauvegarde différentielle et incrémentale

La mise en œuvre d’une sauvegarde complète de base de données et du jour-
nal des transactions est appelée sauvegarde incrémentale.

Figure 5–11
Sauvegarde incrémentale

Dans l’exemple de la figure 5–11, le journal de mardi 8h00 contient unique-

ment les modifications ayant eu lieu sur la base entre la sauvegarde complète
de la base et la sauvegarde du journal des transactions. De même, la sauve-
garde de mardi 12h00 contient les modifications ayant eu lieu sur la base
entre la sauvegarde du journal de 8h00 et celle de 12h00.
On peut dire qu’il s’agit d’une stratégie incrémentale, puisque les sauvegardes
de journaux ne contiennent que la partie ajoutée — l’incrément — des modi-
fications depuis la dernière sauvegarde. L’inconvénient d’une telle stratégie
est qu’en cas de restauration, il faut réappliquer tous les journaux des transac-
tions. L’application de certaines transactions peut engendrer un traitement
long et fastidieux. De plus, il n’est pas toujours possible de sauvegarder la
 Administration et maintenance
234
PARTIE II

base tous les jours. En effet, si la sauvegarde de la base dépasse la durée

impartie pendant la nuit, vous devez utiliser une autre stratégie. C’est ici
qu’entre en jeu la sauvegarde différentielle.
La sauvegarde différentielle est une sauvegarde de base de données qui
capture les pages modifiées depuis la dernière sauvegarde complète.

Figure 5–12
Sauvegarde différentielle

La sauvegarde différentielle est donc plus rapide, puisqu’elle ne contient que

les différences survenues depuis la dernière sauvegarde complète. Dans
l’exemple de la figure 5–12, la sauvegarde différentielle effectuée lundi à
22h00 contient les pages modifiées depuis samedi 22h00, date et heure de
dernière la sauvegarde complète, rendant ainsi caduques les sauvegardes du
journal de la journée de lundi. De plus, elle est le point de départ de la sauve-
garde suivante du journal de mardi 8h00. Si un crash se produit après 8h00 le
mardi, il faut restaurer la sauvegarde complète de la base, puis la sauvegarde
différentielle et enfin le journal de mardi.
L’intérêt de la sauvegarde différentielle réside surtout dans le fait qu’elle est
plus rapide qu’une sauvegarde complète et que sa restauration est plus rapide
que celle du journal des transactions : elle restaure des pages, alors que celle
d’un journal rejoue les transactions. Dans le cas, par exemple, de la création
d’un index, le journal des transactions ne contient que l’instruction de créa-
tion de l’index, alors que la sauvegarde différentielle contient les pages de
l’index créé.
Depuis SQL Server 7, la sauvegarde différentielle a été améliorée et accélérée
par l’introduction des pages DCM (Differential Changed Map). Cette page
système, située en début de fichier de données, permet de suivre 64 000
extensions. Si une extension est modifiée depuis la dernière sauvegarde
complète de la base de données, son bit dans la DCM passe à 1. Lors de la
sauvegarde différentielle, SQL Server a juste besoin de parcourir la DCM
pour trouver les extensions à sauvegarder. Cette stratégie évite le parcours de
la base à la recherche des extensions modifiées.
 Sauvegarde et restauration
235
CHAPITRE V

Sauvegarder avec SQL Enterprise Manager

Le lancement d’une sauvegarde différentielle est identique à celui d’une
sauvegarde complète, à l’exception du bouton radio à sélectionner.

Sauvegarder avec Transact-SQL

La syntaxe est identique à celle d’une sauvegarde complète, à l’exception de
l’option DIFFERENTIAL qui indique une sauvegarde différentielle.

Sauvegarde d’un fichier ou d’un groupe de fichiers

Avec SQL Server 7 disparaissait la sauvegarde d’une table seule. SQL Server
2000 confirme cette disparition et pérennise la sauvegarde d’un fichier ou
d’un groupe de fichiers. Comme il est possible de placer une table dans un
groupe de fichiers donné, on conserve, de manière détournée, la possibilité de
sauvegarder une table indépendante.
La sauvegarde d’un fichier est utile si la sauvegarde complète ou différen-
tielle de la base n’est pas possible en raison de sa durée excessive. Soit, par
exemple, une base de 800 giga-octets répartie en quatre fichiers de 200 giga-
octets. La base est sauvegardée le week-end et les fichiers chaque jour, les uns
à la suite des autres, comme dans la figure 5–13.

Figure 5–13
Sauvegarde de fichiers

À la différence d’une sauvegarde complète de la base, le journal des transac-

tions n’est pas inclus dans la sauvegarde d’un fichier, il faut donc faire une
sauvegarde du journal immédiatement après celle du fichier afin de capturer
toutes les modifications apportées au fichier. Cette stratégie est à prendre en
considération si vous ne disposez pas d’un temps suffisant pour la sauvegarde
complète de la base, la nuit en semaine. Mais, nous le verrons plus tard, il est
possible de restaurer un seul fichier à partir d’une sauvegarde complète de
base de données.
 Administration et maintenance
236
PARTIE II

Important
Les groupes de fichiers sont parfois créés pour séparer physiquement les tables de
leurs index. Par exemple, une table peut être créée sur le groupe numéro 1 et ses
index dans le groupe 2. Il est alors obligatoire de sauvegarder ensemble les deux
groupes. Si l’on ne sélectionne qu’un des deux groupes à sauvegarder,
SQL Server génère une erreur 3013, « La sauvegarde ou la restauration se sont
terminées anormalement », indiquant que la sauvegarde du groupe a échoué.

Sauvegarder avec SQL Enterprise Manager

La sauvegarde d’un fichier avec SQL Enterprise Manager se fait au travers de
la fenêtre de sauvegarde. En cliquant sur l’option Fichier et groupe de
fichiers, on active le bouton permettant de choisir le fichier ou le groupe de
fichiers à sauvegarder : on peut sélectionner soit un groupe de fichiers (ce qui
sélectionne l’ensemble des fichiers du groupe), soit un ou plusieurs fichiers
indépendants.

Figure 5–14
Choix du fichier ou du groupe de fichiers à sauvegarder

Sauvegarder avec Transact-SQL

La sauvegarde d’un fichier ou d’un groupe de fichiers est lancée par l’instruc-
tion BACKUP DATABASE dont voici la syntaxe.
Syntaxe

BACKUP DATABASE {nom_base | @var_nom_base}

[FILE = {nom_fichier_logique | @var_nom_fichier_logique}
|
FILEGROUP = {nom_groupe | @var_nom_groupe}
[,...n]]
TO <unité_sauvegarde> [,...n]
[WITH options]
Exemple :
BACKUP DATABASE Mabase FILE = 'DonnéesBase1' TO Sauvefichiers
sauvegarde le fichier DonnéesBase1 de la base mabase dans l’unité Sauvefichiers.
 Sauvegarde et restauration
237
CHAPITRE V

Mettre en place une stratégie de sauvegarde

Nous venons de découvrir les quatre types de sauvegardes : complète, diffé-
rentielle, journal et fichier/groupe de fichiers. Il est très important de mettre
en place une stratégie utilisant une ou plusieurs de ces sauvegardes pour
réduire au maximum le risque de perte d’informations en cas de crash.

Important
Si votre installation SQL Server est un cluster, vous devez quand même sauvegar-
der vos bases de données. La mise en cluster vous protège de la défaillance d’une
machine, mais pas des pertes de données suite à un crash des disques. De la même
façon, même si vos données sont protégées par RAID 1 ou 5, vous devez sauve-
garder vos bases. En cas de crash, improbable, de plusieurs disques de la baie
RAID vous perdriez toute la base. La sauvegarde de la base est donc indépen-
dante des mécanismes de protection de vos données.

La stratégie de sauvegarde dépend de quatre facteurs principaux :

• le temps dont vous disposez pour faire les sauvegardes ;
• le débit des unités de sauvegarde ;
• le facteur d’accroissement de la taille du journal des transactions ;
• le temps acceptable pour la restauration complète de la base.
Le tableau 5–2, propose différentes stratégies de sauvegarde en fonction de
diverses contraintes opérationnelles.

Tableau 5–2
Types de stratégies en fonction de diverses contraintes opérationnelles

Contrainte Type de sauvegarde

La base peut être sauvegardée toutes les nuits. Sauvegarde complète de la base tous les soirs,
sauvegarde du journal dans la journée dont la
fréquence est fonction de la vitesse de
remplissage.

La base ne peut-être sauvegardée que le week- Sauvegarde complète de la base tous les week-
end, mais le volume de modification reste ends, plusieurs sauvegardes du journal dans la
inférieure à moins de 10% de celui de la base journée, sauvegarde différentielle tous les soirs.

La base est très volumineuse, seule une petite Sauvegarde complète une fois par semaine ou par
partie peut être sauvegardée la nuit. mois, plusieurs sauvegardes du journal dans la
journée, sauvegarde cyclique des fichiers de
données.

Le choix des unités de sauvegarde doit être fonction du coût d’arrêt de votre
système. S’il vous faut deux heures pour restaurer l’ensemble de la base et de
ses journaux, et que la minute d’arrêt du système coûte 10 000 Francs à votre
 Administration et maintenance
238
PARTIE II

société, acheter un nouveau lecteur de bande à 50 000 Francs qui permet de

réduire le temps de restauration à une demi-heure est un investissement renta-
ble, grâce au temps gagné. Sans parler de l’effet induit : un temps inférieur de
restauration signifie souvent temps inférieur de sauvegarde !

La restauration
Généralement, lorsque l’on restaure une base ou un journal, c’est que l’on a
vécu un crash. Pour éviter d’avoir de mauvaises surprises en cas d’urgence,
mieux vaut être prêt au pire et bien comprendre le mode de fonctionnement de
la restauration. À l’inverse de la sauvegarde, il n’est pas possible de restaurer
une base en production. Il faudra donc demander à tous les utilisateurs de se
déconnecter, et s’assurer que le dbo est le seul utilisateur autorisé.
L’historique de toutes les sauvegardes et restaurations est conservé dans les
tables backupfile, backupset, backupmediafamily, backupmediaset, restore-
file, restorefilegroup et restorehistory de la base msbd. Il est possible de les
interroger depuis SQL Enterprise Manager à partir des fenêtres Sauvegarde et
Restauration de la base de données, ou avec une requête SELECT. Ces tables
sont décrites à l’annexe C.

Restauration d’une base de données

La restauration de la base de données restitue le contenu complet de la base de
données. Elle ne doit donc pas être en exploitation lors de la restauration. Là
encore, on peut utiliser SQL Enterprise Manager ou Transact-SQL.
SQL Enterprise Manager permet de consulter le contenu des bandes avant de
procéder au chargement.

Important
La restauration est parfois utilisée pour transférer des bases de données d’un site à
un autre. Le problème du classement ne se pose plus, puisque chaque base de
données peut posséder le sien. Il n’y a donc aucune contre indication à restaurer
une base de données créée avec un classement X sur un serveur installé avec un
classement Y. Il est cependant important de noter que la base de données conser-
vera son classement d’origine.

Restaurer avec SQL Enterprise Manager

1. Dans SQL Enterprise Manager, sélectionner le serveur sur lequel se trouve
la base à charger.
 Sauvegarde et restauration
239
CHAPITRE V

2. Dans le menu Outils, choisir Restaurer une base de données (on peut
aussi obtenir cette commande via le menu contextuel de la base de
données, dans l’option Toutes les tâches). La fenêtre Restaurer la base de
données apparaît alors.

Figure 5–15
Boîte de dialogue de restauration d’une base de données

3. Choisir la base à restaurer dans la liste déroulante Restaurer en tant que

base de données, ainsi que dans Afficher les sauvegardes de la BdD.

Important
Attention ! Vous pouvez restaurer une base x à partir de la sauvegarde d’une
base y ! Vérifiez bien que les deux listes déroulantes sont concordantes.

4. Choisir la sauvegarde à restaurer dans le jeu, dans la liste Première sauve-

garde à restaurer. Le système va alors afficher l’historique des sauvegar-
des en sélectionnant la dernière sauvegarde complète de base, les journaux
et, le cas échéant, les sauvegardes différentielles à appliquer pour ramener
la base dans un état cohérent.
5. Choisir éventuellement des options. L’option Forcer la restauration sur la
base de données existante permet d’écraser la base existante, de recréer
les fichiers aux emplacements indiqués dans le tableau Restaurer les
fichiers base de données en tant que.

6. Il ne reste qu’à choisir la sauvegarde à utiliser, et à cliquer sur le

bouton OK.
 Administration et maintenance
240
PARTIE II

Figure 5–16
Options de restauration

Restaurer à partir d’une unité spécifique

Il se peut que l’unité à partir de laquelle on souhaite restaurer une sauvegarde
n’ait pas été définie. C’est le cas quand on doit réinstaller SQL Server après
un crash disque, ou quand on branche un lecteur de bande sur le serveur pour
récupérer une bande d’un autre serveur. Il faut alors redéfinir l’unité pour que
SQL Server puisse s’en servir. Nous verrons que l’instruction RESTORE
permet d’utiliser une unité sur disque, bande ou canal nommé sans qu’elle ait
été au préalable définie avec la procédure sp_addumpdevice.

Figure 5–17
Restaurer à partir d’une unité
 Sauvegarde et restauration
241
CHAPITRE V

Pour l’instant, voyons comment restaurer une sauvegarde à partir d’un fichier
se trouvant sur un disque local ou sur un disque réseau. À partir de la fenêtre
Restaurer la base de données (figure 5–15), cliquer sur le bouton radio
À partir de l’unité. La boîte de dialogue apparaît (figure 5–17).

On a alors la possibilité d’ajouter une ou plusieurs unités en cliquant sur le

bouton Sélectionner les unités. On obtient alors une boîte de dialogue qui
permet de sélectionner les unités à ajouter (figure 5–18).

Figure 5–18
Choix d’une unité

En cliquant sur le bouton Ajouter, on choisit une unité existante ou l’on pointe
sur un fichier ou un lecteur de bande.
Attention ! Le titre de cette boîte de dialogue est erroné et devrait être
Sélectionnez l’unité source de la restauration (figure 5–19).

Figure 5–19
Sélection de l’unité contenant la sauvegarde

Une fois l’information saisie et validée deux fois par OK, la nouvelle unité
apparaît dans la liste des unités disponibles (figure 5–20).
 Administration et maintenance
242
PARTIE II

Figure 5–20
Restauration à partir d’une unité

Il est possible à partir de cette fenêtre de visualiser le contenu de l’unité afin

de sélectionner la sauvegarde à restaurer (figure 5–21). La sélection de la
sauvegarde entraîne le choix du numéro et du type de la sauvegarde.

Figure 5–21
Choix de la sauvegarde dans l’unité

Par exemple, si l’on coche la deuxième case, on sélectionne en fait l’option

FILE = 2 et un journal des transactions. Une fois le choix fait, il ne reste qu’à
sélectionner les options nécessaires et à cliquer sur le bouton OK.

Obtenir des informations sur un jeu de sauvegarde

avant de le restaurer
Obtenir des informations sur une unité de sauvegarde revient à consulter son
en-tête. Il est possible de le faire soit directement depuis SQL Enterprise
Manager, en demandant le contenu d’une unité sélectionnée, comme dans les
 Sauvegarde et restauration
243
CHAPITRE V

manipulations précédentes, soit à l’aide de l’instruction RESTORE

HEADERONLY étudiée plus loin : voir « Chargement d’un en-tête », page 249.

Restaurer avec Transact-SQL

Comme pour la sauvegarde, l’instruction de restauration présente quelques
options intéressantes qui méritent d’être mentionnées.

Syntaxe

RESTORE DATABASE {nom_base_de_données | @var_nom_base_de_données}

[FROM <unité_de_sauvegarde> [,...n]]
[WITH
[RESTRICTED_USER]
[[,] FILE = numéro_fichier]
[[,] PASSWORD = {mot_de_passe | @variable_mot_de_passe }]
[[,] MEDIANAME = {nom_support | @variable_nom_support}]
[[,] MEDIAPASSWORD = {mdp_media | @variable_mdp_media}]
[[,] MOVE 'nom_fichier_logique' TO 'nom_fichier_système_d’exploitation']
[,...n]
[[,] KEEP_REPLICATION ]
[[,] {NORECOVERY | RECOVERY | STANDBY = nom_fichier_annulation}]
[[,] {NOREWIND | REWIND}]
[[,] {NOUNLOAD | UNLOAD}]
[[,] REPLACE]
[[,] RESTART]
[[,] STATS [= pourcentage]]
]

Exemple :
RESTORE DATABASE mabase FROM Sauvebase
charge la base mabase depuis l’unité Sauvebase.

Les noms d’unités de sauvegarde sont identiques à ceux qui figurent dans les
instructions BACKUP mais nous ne retrouvons pas toutes les options :
• FILE = numéro_de_fichier : spécifie l’emplacement de la sauvegarde dans
le cas où l’unité contient plusieurs sauvegardes séquentielles ;
• KEEP_REPLICATION : indique que les paramètres de réplication d’une base
de données publiés sont conservés lors de sa restauration ;
• MEDIAPASSWORD : indique le mot de passe protégeant le support de
sauvegarde ;
• MOVE : permet de changer l’emplacement des fichiers de base de données
pendant la restauration. Pour utiliser cette option, il ne faut pas que la base
restaurée existe sur le système. L’opération de restauration se charge de la
création des fichiers aux emplacements indiqués dans l’option MOVE ;
 Administration et maintenance
244
PARTIE II

• NORECOVERY : indique au système que d’autres sauvegardes vont être

restaurées à la suite de la base. Il est impératif de stipuler cette option dans
le cas où l’on doit restaurer les journaux des transactions ou une sauve-
garde différentielle ;
• NOREWIND | REWIND : permet d’indiquer de libérer et de rembobiner ou
non la bande après restauration. Si vous ne libérez pas la bande à l’issue de
la restauration, elle ne pourra pas être utilisée pas un autre processus.
NOREWIND implique NOUNLOAD ;

• PASSWORD : indique le mot de passe protégeant la sauvegarde ;

• RECOVERY : indique que la sauvegarde à restaurer est la dernière du jeu de
sauvegarde. Cette option (par défaut) est à stipuler pour laisser la base en
état cohérent et empêcher la restauration des journaux des transactions ;
• REPLACE : indique à SQL Server qu’il doit remplacer la base si elle existe
sur le système ;
• RESTART : indique à SQL Server que la restauration précédente s’est inter-
rompue (par exemple, à la suite d’un crash système) et qu’il faut reprendre
la restauration à son point d’arrêt (ne concerne que les restaurations à
partir de bandes) ;
• RESTRICTED_USER : remplace l’option DBO_ONLY des versions précéden-
tes et permet de restreindre l’accès de la base de données restaurée aux
membres des rôles db_owner, dbcreator et sysadmin ;
• UNLOAD | NOUNLOAD (voir l’instruction BACKUP DATABASE, page 230).
Si l’on restaure une base sauvegardée sur plusieurs unités en parallèle, il faut
sélectionner l’ensemble de ces unités.
La base de données master est un cas particulier dans les opérations de restau-
ration. Voir le chapitre 14, « Tolérance aux pannes et arrêts système ».

Restauration du journal des transactions

La restauration du journal des transactions est une opération qui consiste à
réappliquer les transactions sauvegardées. Pour pouvoir restaurer un journal,
il faut que celui-ci ait été sauvegardé indépendamment de la base de données,
donc qu’il ait fait l’objet d’une instruction BACKUP LOG. Si l’on applique une
stratégie de sauvegarde incrémentale, on dispose de plusieurs sauvegardes du
journal depuis la dernière sauvegarde de la base. Pour restaurer les journaux,
il faut d’abord restaurer la base avec l’option NORECOVERY, puis réappliquer
les transactions enregistrées dans les journaux, dans l’ordre. Si l’on tente de
les réappliquer dans un ordre différent, le système indique que la sauvegarde
utilisée n’est pas à sa place dans la séquence.
 Sauvegarde et restauration
245
CHAPITRE V

Restaurer avec SQL Enterprise Manager

La démarche de restauration d’un journal est identique à celle d’une base de
données. On peut en plus indiquer la date et l’heure à laquelle on souhaite
arrêter la restauration : par exemple, restaurer le journal sauvegardé mardi
soir, jusqu’à mardi 12 h 45 (voir, dans le paragraphe suivant, l’exemple illus-
trant l’option STOPAT).

Restaurer avec Transact-SQL

Syntaxe

RESTORE LOG {nom_base | @var_nom_base}

[FROM <unité_de_sauvegarde> [,...n]]
[ WITH
[RESTRICTED_USER]
[[,] FILE = {numéro_fichier | @variable_numéro_fichier } ]
[[,] PASSWORD = {mot_de_passe | @variable_mot_de_passe }]
[[,] MEDIANAME = {nom_support | @variable_nom_support}]
[[,] MEDIAPASSWORD = {mdp_media | @variable_mdp_media}]
[[,] MOVE 'nom_fichier_logique' TO 'nom_fichier_système_d’exploitation']
[,...n]
[[,] KEEP_REPLICATION ]
[[,] {NORECOVERY | RECOVERY | STANDBY = nom_fichier_annulation}]
[[,] {NOREWIND | REWIND}]
[[,] {NOUNLOAD | UNLOAD}]
[[,] REPLACE]
[[,] RESTART]
[[,] STATS [= pourcentage]]
[[,] STOPAT = { date_heure | @var_date_heure }
| [,] STOPATMARK = 'nom_marque' [ AFTER dateheure ]
| [,] STOPBEFOREMARK = 'nom_marque' [ AFTER dateheure ]]
]

Exemple :
RESTORE LOG mabase FROM Sauvelog
réapplique les transactions du journal de la base mabase, sauvegardé dans l’unité
Sauvelog.

Les noms d’unités de sauvegarde obéissent aux mêmes règles que les instruc-
tions BACKUP et RESTORE DATABASE. Les options sont identiques à celles de
RESTORE DATABASE, à l’exception de STOPAT, STOPATMARK et STOPBEFORE-
MARK qui sont propres aux journaux de transactions.

STOPAT existait déjà en version 7, les deux autres sont nouvelles dans SQL
Server 2000.Supposons, par exemple, que vous ayez fait une sauvegarde du
journal le mardi à 21h00 ; vous souhaitez revenir à l’état dans lequel était la
 Administration et maintenance
246
PARTIE II

base à 12h45 le mardi 21 septembre 2001 ; vous allez donc restaurer la sauve-
garde de base du dimanche par un BACKUP DATABASE simple, restaurer le
journal du lundi par un BACKUP LOG simple et enfin, restaurer celui du mardi
avec l’option : WITH STOPAT '21/09/01 12:45:00'.
En fin d’exécution, le système indique le nombre de transactions validées
(rolled forward) et le nombre de transactions annulées (rolled back). Les tran-
sactions annulées sont celles qui sont dotées d’un ROLLBACK explicite, ou
celles qui n’ont pas fait l’objet d’un COMMIT. Généralement, il s’agit des tran-
sactions en cours lors de la sauvegarde du journal et dont il a été impossible
de sauvegarder les ordres COMMIT.
STOPATMARK et STOPBEFOREMARK permettent de restaurer le journal des
transactions jusqu'à une marque nommée placée spécialement dans une tran-
saction par l’instruction BEGIN TRANSACTION nom_transaction WITH MARK.
Supposons que vous souhaitiez exécuter une transaction dont vous n’êtes pas
certain à 100%. Vous « marquez » cette transaction de façon à pouvoir, lors de
la restauration du journal, revenir à l’état dans lequel était la base juste avant
la transaction (STOPBEFOREMARK). L’existence de l’option AFTER est justifiée
par le fait qu’il peut exister plusieurs marques portant le même nom dans une
sauvegarde de journal. Imaginons les marques suivantes :
• marque1 – 12 juillet 2001 – 20h00
• marque2 – 12 juillet 2001 – 21h00
• marque1 – 13 juillet 2001 – 14h00
Si vous restaurez le journal WITH STOPATMARK marque1, la restauration va
avoir lieu jusqu’à la première occurrence de la marque, c’est-à-dire celle du
12 juillet à 20 heures. En revanche, avec WITH STOPATMARK marque1 AFTER
'07/13/01 13h00', la sauvegarde va se poursuivre jusqu’à la seconde marque
marque1 car elle est postérieure à la date et à l’heure indiquées dans la
première.
STOPATMARK rejoue toutes les transactions jusqu’à celle qui est marquée
incluse. STOPBEFOREMARK s’arrête à la dernière transaction précédant celle
qui est marquée. Ces deux options pallient en fait les limites intrinsèques de
l’option STOPAT. Il est en effet plus simple de laisser une marque dans le jour-
nal des transactions pour permettre de retrouver une transaction particulière
que de noter l’heure et la date auxquelles elle a eu lieu.
 Sauvegarde et restauration
247
CHAPITRE V

Restauration d’une sauvegarde différentielle

La restauration d’une sauvegarde différentielle suit immédiatement celle
d’une sauvegarde complète de la base de données faite avec l’option
NORECOVERY. Plus rapide qu’une restauration d’un ensemble de sauvegarde
de journal des transactions, son but est le même : restaurer l’activité de la base
de données depuis la sauvegarde complète.

Restaurer avec SQL Enterprise Manager

Avec SQL Enterprise Manager, la démarche est identique à la restauration
d’une base ou d’un journal.

Restaurer avec Transact-SQL

La syntaxe de la restauration différentielle est celle de l’instruction RESTORE
DATABASE. Il n’y a donc aucune différence syntaxique entre une restauration
complète et une restauration différentielle. La différence réside dans le jeu de
sauvegarde et dans l’option NORECOVERY appliquée à la restauration
complète.

Restauration d’un fichier ou d’un groupe de fichiers

La restauration d’un fichier ou d’un groupe de fichiers peut s’effectuer à
partir d’une sauvegarde de fichier/groupe de fichiers ou de base de données.
Elle n’est pas sans poser de problèmes de cohérence. En effet, si vous restau-
rez un fichier à une version antérieure, vous perdez toutes les modifications
apportées aux données depuis leur sauvegarde et prenez donc le risque
d’avoir une base incohérente.
Pour garantir le retour à une cohérence totale, il suffit de restaurer les sauve-
gardes du journal des transactions faites depuis la sauvegarde du fichier. La
restauration du fichier est faite avec l’option NORECOVERY, et celle des jour-
naux ne rejouent que les transactions s’appliquant aux données du fichier/
groupe de fichiers restauré.

Restaurer avec SQL Enterprise Manager

L’opération est identique à la restauration d’une base de données ou d’un
journal des transactions à l’exception du choix de l’option Groupe de fichiers
ou fichiers (figure 5–22).

SQL Enterprise Manager sélectionne automatiquement les journaux à appli-

quer au fichier/groupe à la suite de sa restauration.
 Administration et maintenance
248
PARTIE II

Figure 5–22
Restauration d’un fichier

Restaurer avec Transact-SQL

Comme pour la sauvegarde, l’ordre indique le nom d’une base de données et
désigne le fichier ou le groupe de fichier.

Syntaxe

RESTORE DATABASE {nom_base | @var_nom_base}

FILE = {nom_fichier | @var_nom_fichier }
|
FILEGROUP = {nom_groupe | @var_nom_groupe}
[,...n]
[FROM <unité_de_sauvegarde> [,...n]]
[WITH options]

Restauration partielle d’une base de données

Nous venons de voir qu’il était possible de restaurer un seul fichier ou groupe
de fichier ; on peut encore restaurer une base de données partiellement, en
mettant certains de ses fichiers ou de ses groupes de fichiers offline. L’intérêt
d’une restauration partielle réside dans la possibilité de ne pas restaurer l’inté-
gralité d’une base de données si l’on ne souhaite accéder qu’à un sous-ensem-
ble de ses données, par exemple, des données archivées.
 Sauvegarde et restauration
249
CHAPITRE V

Syntaxe

RESTORE DATABASE {nom_base | @var_nom_base}

FILE = {nom_fichier | @var_nom_fichier }
|
FILEGROUP = {nom_groupe | @var_nom_groupe}
[,...n]
[FROM <unité_de_sauvegarde> [,...n]]
WITH PARTIAL[, options]

La granularité d’une restauration partielle est le fichier ou le groupe de

fichier. Si donc on souhaite accéder aux données d’une table précise, il faudra
restaurer son fichier ou son groupe en totalité. Il est à noter que la restauration
partielle n’est possible que depuis Transact-SQL.

Pour en savoir plus

Pour consulter des exemples complets et avoir de plus amples informations sur la
restauration partielle, consultez la documentation en ligne à Administration de
SQL Server/Sauvegarde et restauration de base de données/Opérations de sauve-
garde et de restauration/Opérations de restauration d’une base de données
partielle.

Chargement d’un en-tête

Il faut charger l’en-tête pour avoir un aperçu du contenu d’une unité. L’intérêt
en est la vérification du contenu d’une bande, avant de la charger ; par exem-
ple, lorsque la bande vient d’un site distant. Cette opération peut être faite
depuis l’interface graphique ou par une commande Transact-SQL.

Syntaxe

RESTORE HEADERONLY FROM unité_de_sauvegarde

[ WITH { NOUNLOAD | UNLOAD }
[[,] FILE = numéro_fichier]
[[,] PASSWORD = {mot_de_passe | @variable_mot_de_passe} ]
[[,] MEDIAPASSWORD = {mdp_media | @variable_mdp_media} ]
]

Le tableau 5–3 explique les paramètres du résultat obtenu.

 Administration et maintenance
250
PARTIE II

Tableau 5–3
Liste des colonnes obtenues avec RESTORE HEADERONLY

Type de
Option Valeurs possibles
données

BackupName nvarchar(128) Nom du jeu de sauvegarde.

BackupDescription nvarchar(255) Description du jeu de sauvegarde.

BackupType smallint Si la sauvegarde est réalisée par SQL Server : base de

données (1), journal des transactions (2), fichier (4),
base de données différentielle (5).
Si la sauvegarde est réalisée par un logiciel tiers :
normale (1), différentielle (5).

ExpirationDate datetime Date d’expiration du jeu de sauvegarde.

Compressed tinyint Compressé (1), non compressé(0), (SQL Server ne

prend pas en compte, seul, la compression logicielle).

Position smallint Position du jeu de sauvegarde dans le volume (FILE =).

Devicetype tinyint Disque (2, 102), bande (5, 105) ou canal de

communication (6, 106), Périphérique virtuel (7, 107).

UserName nvarchar(128) Nom de l’utilisateur ayant lancé la sauvegarde.

ServerName nvarchar(128) Nom du serveur qui a créé la sauvegarde.

DatabaseName nvarchar(128) Nom de base de données sauvegardée.

DatabaseVersion int Version de la base de données sauvegardée.

DatabaseCreationDate datetime Date et heure de création de la base de données.

BackupSize numeric(20,0) Taille de la sauvegarde en octets.

FirstLSN numeric(25,0) Numéro de séquence du journal des transactions

correspondant à la première transaction sauvegardée.

LastLSN numeric(25,0) Numéro de séquence du journal des transactions

correspondant à la dernière transaction sauvegardée.

CheckpointLSN numeric(25,0) Numéro de séquence du journal des transactions

correspondant au point de synchronisation le plus
proche du moment de la sauvegarde.

DatabaseBackupLSN numeric(25,0) Numéro de séquence du journal des transactions

correspondant à la sauvegarde.

BackupStartDate datetime Date et heure du début de la sauvegarde.

BackupFinishDate datetime Date et heure de la fin de la sauvegarde.

SortOrder smallint Ordre de tri du serveur.

CodePage smallint Jeu de caractères du serveur.

 Sauvegarde et restauration
251
CHAPITRE V

Tableau 5–3
Liste des colonnes obtenues avec RESTORE HEADERONLY

Type de
Option Valeurs possibles
données

UnicodeLocaleId int Identifiant du style Unicode (langue) du serveur.

UnicodeComparisonStyle int Ordre de comparaison Unicode.

CompatibilityLevel tinyint Niveau de compatibilité de la base (60, 65 ou 70).

SoftwareVendorId int Numéro de l’éditeur du logiciel de sauvegarde

(4608 pour Microsoft SQL Server).

SoftwareVersionMajor int Numéro principal de version du logiciel de sauvegarde.

SoftwareVersionMinor int Numéro secondaire de version du logiciel de

sauvegarde.

SoftwareVersionBuild int Numéro de build de version du logiciel de sauvegarde.

Machine_name nvarchar(128) Nom de l’ordinateur qui a effectué la sauvegarde.

Flags int Indique si les données insérées en bloc (bcp ou BULK

INSERT) sont contenues dans la sauvegarde du
journal.

BindingID uniqueidentifier ID de la base de données.

RecoveryForkID uniqueidentifier ID de fourchette de récupération de cette sauvegarde.

Utilisé conjointement avec BindingID pour vérifier
qu’une sauvegarde peut être restaurée sur un serveur
particulier.

Collation nvarchar(128) Classement de la base de données.

 Administration et maintenance
252
PARTIE II

Résumé
Les nombreux mécanismes de sauvegarde et de restauration peuvent engen-
drer une certaine confusion. Voici un résumé rapide des diverses situations
nécessitant la restauration d’une ou plusieurs bases de données.

Restauration suite à corruption de la base de données

1. Faire d’urgence une sauvegarde du journal des transactions :

BACKUP LOG mabase TO unité_sauvegarde WITH NO_TRUNCATE

2. Supprimer la base depuis SQL Enterprise Manager ou avec l’instruction

DROP DATABASE ;

3. Restaurer la base de données depuis SQL Enterprise Manager ou avec

l’instruction RESTORE DATABASE :
RESTORE DATABASE mabase FROM unité_sauvegarde WITH NORECOVERY
RESTORE LOG mabase FROM unité_sauvegarde WITH FILE = 1, NORECOVERY
…
RESTORE LOG mabase FROM unité_sauvegarde WITH FILE = n, RECOVERY

4. Accéder à la base depuis SQL Enterprise Manager.

Crash des disques de la base de données

1. Faire une sauvegarde d’urgence du journal des transactions :
BACKUP LOG mabase TO unité_sauvegarde WITH NO_TRUNCATE

2. Remplacer et formater les disques incriminés ;

3. Supprimer la base depuis SQL Enterprise Manager ou avec l’instruction
DROP DATABASE ;

4. Restaurer la base de données depuis SQL Enterprise Manager ou avec

l’instruction RESTORE DATABASE :
RESTORE DATABASE mabase FROM unité_sauvegarde WITH NORECOVERY
RESTORE LOG mabase FROM unité_sauvegarde WITH FILE = 1, NORECOVERY
…
RESTORE LOG mabase FROM unité_sauvegarde WITH FILE = n, RECOVERY

5. Accéder à la base depuis SQL Enterprise Manager.

 Sauvegarde et restauration
253
CHAPITRE V

Crash des disques du journal des transactions

En cas de crash des disques du journal des transactions, le système recrée
automatiquement un journal à l’emplacement du fichier .MDF permettant
l’exploitation de la base.

1. Changer le disque défectueux ;

2. Détacher la base incriminée :
sp_detach_db mabase

3. Déplacer le fichier journal que le système a créé automatiquement et le

renommer avec l’ancien nom ;
4. Rattacher la base :
sp_attach_db mabase, "fichierMDF", "FichierNDF",…, "FichierLDF"

Saturation du journal des transactions

1. Faire d’urgence un vidage du journal des transactions :
BACKUP LOG mabase WITH NO_LOG

2. Exécuter une instruction CHECKPOINT sur la base de production ;

3. Faire immédiatement une sauvegarde de la base de données :
BACKUP DATABASE mabase TO unité_sauvegarde

4. Augmenter la taille du journal des transactions pour éviter le phénomène.

Crash des bases système

Nous reviendrons sur les problèmes de crash système et sur les moyens de
s’en protéger au chapitre 14, « Tolérance aux pannes et arrêts système ».
Voici cependant les procédures à suivre si le support contenant les bases de
données système est endommagé.

Restauration de bases de données système

depuis une sauvegarde
Si le service SQL Server peut être lancé, vous pouvez utiliser l’instruction
RESTORE DATABASE ou SQL Enterprise Manager pour restaurer les bases de
données système à partir d’une sauvegarde valide :
RESTORE DATABASE master FROM unité_sauvegarde_master
RESTORE DATABASE msdb FROM unité_sauvegarde_msdb
 Administration et maintenance
254
PARTIE II

Reconstruction et restauration
des bases de données système
Si la base de données master est endommagée et que vous ne pouvez pas
lancer SQL Server, suivez la procédure ci-après :
1. Reconstruire les bases de données système avec l’utilitaire REBUILDM.EXE
qui se trouve dans le répertoire \Program Files\Microsoft SQL
Server\80\Tools\Binn ;
2. Redémarrer normalement le service SQL Server ;
3. Restaurer la base master à partir de sa sauvegarde la plus récente :
RESTORE DATABASE Master FROM unité_sauvegarde_master

4. Restaurer la base msdb :

RESTORE DATABASE msdb FROM unité_sauvegarde_msdb

5. Restaurer la base model, le cas échéant :

RESTORE DATABASE model FROM unité_sauvegarde_model

6. Restaurer la base distribution si la machine est distributeur de réplication :

RESTORE DATABASE distribution FROM unité_sauvegarde_distribution

Rattachement ou restauration
des bases de données de production
Si vous avez pu restaurer la base master, aucune autre opération n’est néces-
saire, car cette base contient les informations suffisantes à la récupération des
bases utilisateur. Si la restauration de master a échoué, vous devez rattacher
les bases de données de production ou les restaurer si l’attache échoue.

Crash du disque système

Si le support contenant SQL Server est endommagé, il faut réinstaller
SQL Server et les bases système.

1. Réinstaller SQLServer en installation par défaut, à moins que vous

n’ayez fait et noté des choix d’installation particuliers ;
2. Démarrer SQL Server en mode monoutilisateur, avec l’applet Services
du Panneau de configuration, en utilisant le commutateur –m dans le
paramètre du service SQL Server ;
3. Restaurer master à partir de la sauvegarde la plus récente, depuis
SQL Enterprise Manager :
RESTORE DATABASE master FROM unité_sauvegarde_master
 Sauvegarde et restauration
255
CHAPITRE V

4. Restaurer la base msdb à partir de sa sauvegarde la plus récente depuis

SQL Enterprise Manager :
RESTORE DATABASE msdb FROM unité_sauvegarde_msdb

5. Rattacher les bases de production :

sp_attach_db mabase, "fichierMDF", "FichierNDF",…, "FichierLDF"
ou les restaurer :
RESTORE DATABASE mabase FROM unité_sauvegarde WITH NORECOVERY
RESTORE LOG mabase FROM unité_sauvegarde WITH FILE = 1, NORECOVERY
…
RESTORE LOG mabase FROM unité_sauvegarde WITH FILE = n, RECOVERY

Problèmes courants
et précautions d’usage
Une sauvegarde ne peut jamais être fiable à 100%, ne serait-ce qu’à cause du
support sur lequel elle est faite et de son mode de stockage. Même si toutes
les précautions sont prises à ce niveau, il peut arriver que la sauvegarde ne
puisse être récupérée, essentiellement à cause des problèmes de cohérence de
la base.
De plus, pour assurer une stratégie de sauvegarde parfaite, il est préférable de
la faire alors que le trafic sur la base est faible, voire nul. Pour cela, il est inté-
ressant d’automatiser le processus de sauvegarde, pour qu’il ait lieu la nuit ou
le week-end, sans intervention d’un opérateur.

Vérification de cohérence
Dans les versions précédentes de SQL Server, les structures de données
n’étaient pas d’une fiabilité à toute épreuve dans la mesure où il n’existait pas
de mécanisme de vérification des allocations. Dans les versions 7 et 2000, les
pages des tables qui possèdent un index clustered sont chaînées et référencées
dans l’IAM (Index Allocation Map). Dans le cas, improbable, de suppression
d’un pointeur avant ou arrière entre pages, le système peut facilement retrou-
ver les allocations correctes en examinant l’IAM. Cependant, si un problème
d’allocation existe, il peut entraîner une instabilité du système et une corrup-
tion des sauvegardes ou des restaurations.
 Administration et maintenance
256
PARTIE II

Résultat : il faut vérifier et, le cas échéant, réparer ces incohérences avant de
lancer une sauvegarde ! Pour cela, nous avons trois armes : la défragmenta-
tion (voir chapitre 12, « Optimisation des performances »), l’utilitaire
SQLMAINT (voir « Outil de maintenance », page 259) ou le Database Consis-
tency Checker (DBCC). Cependant ces vérifications sont moins nécessaires
qu’en version 6.x et, par ailleurs, elles ont été optimisées et sont beaucoup
plus rapides.

Database Consistency Checker (DBCC)

Voici quatre de ses instructions.
• DBCC CHECKDB : vérifie que les pages d’index et de tables sont correcte-
ment liées. Si cette instruction renvoie des erreurs, il va falloir demander
une réparation des allocations et l’on va au devant de pertes potentielles de
données. Il convient d’arrêter l’exploitation de la base, de sauvegarder
d’urgence le journal de transactions, de faire les réparations avec l’option
REPAIR_REBUILD (qui n’engendre pas de perte de données, mais est limité
dans ses réparations) ou REPAIR_ALLOW_DATA_LOSS (qui peut entraîner
des pertes de données), de faire les vérifications de fonctionnement et, le
cas échéant, de reconstruire la base depuis sa dernière sauvegarde3.
• DBCC CHECKALLOC : vérifie les allocations de pages par rapport aux
extensions. Elle est implicitement contenue dans DBCC CHECKDB et n’est
donc pas utile en sus.
• DBCC CHECKTABLE : vérifie la cohérence d’une table et éventuellement de
ses index. Comme CHECKALLOC, elle est contenue dans DBCC CHECKDB.
• DBCC CHECKCATALOG : vérifie la cohérence des tables système. Si on ne
donne pas de nom de base de données, elle s’applique à la base en cours.
Si cette instruction renvoie des erreurs, il s’agira vraisemblablement de
modifications apportées aux tables sans que ces modifications aient été
répercutées dans les tables système, mais ce cas est très peu probable.
Et puis si après tout, nous laissions faire le système... Microsoft nous donne
une boîte à outils complète, à nous de mettre en place les stratégies gagnantes.

3. Rassurez-vous ! ces cas sont rarissimes et même si nous n’avons que peu de recul sur les systèmes
SQL Server 2000 en production, je n’ai pas eu connaissance de corruption ayant entraîné des pertes de
données.
 Sauvegarde et restauration
257
CHAPITRE V

Automatisation
SQL Server met à notre disposition un gestionnaire de tâches automatisées.
Parmi ces tâches, celles qui concernent la sauvegarde occupent une place
prépondérante.
Il y a deux moyens d’automatiser la sauvegarde :
• créer un travail qui exécute un BACKUP DATABASE ou BACKUP LOG, soit
depuis la fenêtre Sauvegarder la base de données, soit directement depuis
le gestionnaire de travaux ;
• créer un travail qui s’appuie sur l’utilitaire SQLMAINT, soit avec l’Assistant
Plan de maintenance de base de données, soit depuis la fenêtre du Gestion-
naire de travaux.

Automatiser une sauvegarde

En ce qui concerne le premier moyen, il ne s’agit que de l’automatisation
d’instructions que nous avons déjà étudiées, mise en place directement grâce
au gestionnaire de travaux ou depuis la boîte de dialogue Sauvegarder la base
de données.

Figure 5–23
Liste des travaux définis

Dans SQL Enterprise Manager, ouvrir le dossier Gestion, puis Agent SQL
Server, enfin sélectionner Travaux (figure 5–23). Pour créer un nouveau
travail, choisir Nouveau travail dans le menu contextuel du dossier Travaux
ou utiliser l’Assistant Création de travail en sélectionnant Planification de
travail dans le menu Outils.

Tout travail planifié se compose de trois éléments essentiels : un nom (et,

accessoirement, une catégorie), une ou plusieurs étapes et une ou plusieurs
planifications. Une étape appartient à l’un de ces quatre types : Transact-SQL
(une ou plusieurs commandes SQL), CmdExec (une commande du système
 Administration et maintenance
258
PARTIE II

d’exploitation), script ActiveX (Visual Basic Script ou Javascript) et réplica-

tion (que nous verrons plus tard).
Voici les étapes pour créer un travail de sauvegarde, depuis la boîte de dialo-
gue Propriétés du nouveau travail :
1. donner un nom et une catégorie au nouveau travail ;

Figure 5–24
Définition du nom et de la catégorie du travail

2. sélectionner l’onglet Étapes, cliquer sur le bouton Nouvelle et définir les

caractéristiques de l’étape, à savoir son nom et la commande SQL à
exécuter, puis valider en cliquant sur le bouton OK (figure 5–25) ;

Figure 5–25
Définition d’une étape de type Transact-SQL

3. de retour dans la boîte de dialogue Propriétés du nouveau travail, sélec-

tionner l’onglet Planification et cliquer sur le bouton Nouvelle planifica-
tion, définir les paramètres de la planification, puis valider en cliquant sur
le bouton OK (figure 5–26) :
 Sauvegarde et restauration
259
CHAPITRE V

Figure 5–26
Définition d’une planification

Il est possible de définir plusieurs planifications : par exemple, l’une char-

gée de la sauvegarde tous les jours ouvrés à 22h00 et l’autre chargée de
celle du dimanche à 04h00 ;
4. Valider la création du travail en cliquant sur le bouton OK.
Nous reverrons toutes les options de création et de planification d’un travail
au chapitre 13, « Automatisation des tâches ».

Outil de maintenance
L’utilitaire SQLMAINT est apparu avec la version 6.5. Il a été conçu comme
support de l’Assistant Plan de maintenance de base de données. Néanmoins,
personne ne vous empêche de l’utiliser pour mettre en place des stratégies de
sauvegarde automatisée.
Le but ici n’est pas de détailler tous les paramètres de cet utilitaire, mais
simplement d’en présenter les options intéressant cette partie du livre.

Syntaxe

sqlmaint
[
[-S serveur]
[-U nom_d’accès [-P mot_de_passe]]
{
[ -D nom_base | -PlanName nom | -PlanID guid ]
[-Rpt fichier_texte [-DelTxtRpt <période>] ]
[-To nom_opérateur]
[-HtmlRpt fichier_html [-DelHtmlRpt <période>] ]
[-RmUnusedSpace pourcentage_seuil pourcentage_libre]
[-CkDB | -CkDBNoldx]
[-CkAl | -CkAlNoIdx]
[-CkTxtAl]
[-CkCat]
 Administration et maintenance
260
PARTIE II

[-UpdOptiStats pourcentage_échantillonage]
[-RebldIdx espace_libre]
[-WriteHistory]
[
[-BkUpDB chemin | -BkUpLog chemin]
{-BkUpMedia
{DISK [[-DelBkUps <période>]
[-CrBkSubDir ] [ -UseDefDir ]]
| TAPE}
}
[-BkUpOnlyIfClean]
[-VrfyBackup]
]
}
]

Les options de la commande ont presque toutes une correspondance avec

l’une des commandes que nous avons vues dans les sections précédentes.
• Rpt : indique le fichier avec son chemin complet dans lequel sera inscrit le
rapport d’exécution ;
• HtmlRpt : indique le fichier HTML avec son chemin complet dans lequel
sera inscrit le rapport d’exécution ;
• RmUnusedSpace : stipule de récupérer l’espace libre en fin de fichier, si la
base est à croissance automatique et qu’elle a crû ;
• CkDB, CkDBNoIdx : équivalent de DBCC CHECKDB, avec ou sans l’option
NOINDEX ;
• CkAl, CkAlNoIdx : équivalent de DBCC NEWALLOC, avec ou sans l’option
NOINDEX ;
• CkTxtAl : équivalent de DBCC TEXTALL ;
• CkCat : équivalent de DBCC CHECKCATALOG ;
• WriteHistory : indique que chaque opération de maintenance est consignée
dans la table msdb.dbo.sysdbmaintplan_history.
• BkUpDB : indique le chemin dans lequel faire la sauvegarde. Dans le cas
d’une sauvegarde sur bande, indiquer son nom sous la forme \\.\TAPEn,
où n représente le numéro du lecteur de bande. Le fichier généré sera de la
forme : NOMBASE_DB_AAAAMMJJHHMM.BAK, où aaaammjjhhmm repré-
sente la date et l’heure de sauvegarde ;
• BkUpLog : identique à BkUpDB pour les journaux de transactions. Le
fichier s’appellera NOMBASE_LOG_AAAAMMJJHHMM.BAK ;
• BkUpMedia : spécifie le type de l’unité de sauvegarde. Pour le type DISK,
DelBkUps permet de donner un délai de rétention ;
 Sauvegarde et restauration
261
CHAPITRE V

• BkUpOnlyIfClean : ne fait la sauvegarde que si les opérations de vérifica-

tion (CkDB et CkCat) ne renvoient aucune erreur ;
• VrfyBackup : vérifie la sauvegarde à son issue.

Attention
Les paramètres sont sensibles aux différences majuscule/minuscule. Respectez
bien leur casse sous peine de ne pas voir votre commande s’exécuter.

Si vous exécutez l’instruction suivante le 23 septembre 2001 à une invite de

commande :

sqlmaint -D pubs -Rpt "c:\mssql\log\pubs.rpt" -CkDB -CkCat

-BkUpDB "c:\mssql\backup" –BkUpMedia DISK –BkUpOnlyIfClean

vous faites une sauvegarde de la base pubs dans le fichier

PUBS_DB_200109232315.BAK sur disque, à condition que les rapports de véri-
fication de cohérence ne renvoient pas d’erreurs. Vous pourrez alors lire le
résultat de l’opération dans le fichier de rapport
PUBS_MAINT_200109232315.RPT.

Quand une commande est bien paramétrée, sauvegardez-la et planifiez-la

avec le gestionnaire de tâches.
 Administration et maintenance
262
PARTIE II

Points clés

• Mettez en place dès le début de la mise en production de votre base une straté-
gie de sauvegarde.
• Sauvegardez toutes les bases de données, y compris master, msdb et distribu-
tion (si vous utilisez de la réplication).
• Une unité de sauvegarde peut être créée sur disque, disque réseau, bande ou
canal nommé.
• Toute sauvegarde est faite à destination d’une unité de sauvegarde explicite-
ment créée ou définie au moment de la sauvegarde.
• Les unités de sauvegarde sur bande s’appuient sur le gestionnaire de bande de
Windows 2000.
• Toutes les informations sur les unités de sauvegarde se trouvent dans la table
sysdevices dans master.
• On peut sauvegarder une base de données complète, une base de données en
mode différentiel, un journal des transactions, un fichier ou un groupe de
fichiers.
• Le mécanisme de sauvegarde dynamique permet de sauvegarder une base ou
son journal alors même que les utilisateurs travaillent sur la base.
• La sauvegarde d’un journal des transactions vide sa partie inactive, conservant
ainsi au journal un faible volume.
• Il est possible de restaurer un journal jusqu’à une date et une heure précise
avec le paramètre STOPAT.
• Vérifiez de temps en temps la cohérence de la base de données avec les
instructions DBCC.
• Planifier vos sauvegardes avec SQLMAINT vous permet de mettre en place
simplement et rapidement une stratégie de sauvegarde de vos informations,
avec les vérifications de cohérence nécessaires.

Pour en savoir plus sur les sujets abordés dans ce chapitre

Documentation en ligne de SQL Server, livre « Administration de

SQL Server », chapitre « Sauvegarde et restauration de base de données ».