www.udivers.com tssri-reseaux@hotmail.

fr

Gestion des
Sauvegarde
s sous Ms
Sql Server
2000

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

Gestion des Sauvegardes sous Ms Sql Server 2000

Sommaire

Introduction

1. Pourquoi Sauvegarder ?

2. Présentation des Sauvegardes

2.1 Généralités
2.2 Les différents supports de sauvegarde
2.3 Les moments appropriés pour sauvegarder
2.3 Création des unités de sauvegarde
2.4 Création des sauvegardes

3. Planification d'une stratégie de Sauvegarde

3.1 Sauvegarde complète

3.2 Sauvegarde du journal de transactions
3.3 Sauvegarde différentielle
3.4 Sauvegarde d'un fichier ou d'un groupe de fichiers

4. Quelques Conseils

Conclusion

Introduction

Objectifs
Microsoft SQL Server® 2000 est un système de gestion de bases de données relationnelles.
Il a l'avantage d'être puissant, multi-utilisateurs et il permet de supporter un volume
important de données. Ce SGBDR est souvent utilisé dans un environnement de production
en entreprise. C'est pourquoi il est important de réfléchir et d'appliquer une solution de
sauvegarde des différentes bases de données. Une entreprise ne peut en effet en aucun cas
se permettre d'avoir une interruption de services au niveau d'une base de données en cas
de défaillances partielles ou complètes de celle-ci.

Ce document a donc pour objectif de vous décrire l'importance de la sauvegarde des bases
de données dans un milieu professionnel et de vous montrer les différentes méthodes qu'un
administrateur de base de données dispose pour préserver les données de l'entreprise dans
un environnement de production.

Les utilisateurs et les administrateurs de bases de données pourront ainsi comprendre

l'importance d'une bonne gestion des sauvegardes et voir pourquoi celles-ci influent
directement sur la productivité et la rentabilité de l'entreprise.

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

1. Pourquoi Sauvegarder ?

De nos jours, les composants matériels et logiciels sont performants et beaucoup plus
fiables que par le passé. Cependant, aucun d'eux n'est parfait et la possibilité d'avoir une
défaillance n'est jamais nulle. Celle-ci peut-être provoquée par un événement extérieur.

Exemple :

• Destruction logicielle dûe à un virus.

• Utiliser une clause UPDATE sans spécifier une clause de condition WHERE.
• Défaillance d'un disque dur supportant une base de données.
• Destruction par un élément naturel (feu , inondation) des serveurs de l'Entreprise.
• Corruption d'une base de données.
• ...

Toutes ces situations peuvent entraîner des pertes de données des différentes bases
défaillantes et provoquer l'arrêt de la production, ce qui peut être dans certains cas très
préjudiciable pour une entreprise.

C'est pourquoi il est important de sauvegarder efficacement les bases de données afin de
remettre le plus rapidement possible le serveur en production en minimisant la perte
éventuelle de données.

2. Présentation des Sauvegardes

2.1 Généralités
Avant de restaurer une base de données, il faut bien évidemment la sauvegarder au
préalable.

Voici des informations importantes concernant la sauvegarde :

•Un administrateur peut effectuer une sauvegarde de base de données lorsque SQL
Server est en cours d'utilisation. Toutefois, dans les différents cas suivants, il faut
éviter d'effectuer des sauvegardes :
• Lors de la création ou la modification d'une base de données.
• Lors de l'exécution d'opérations de croissance automatique.
• Lors de la création d'index.
• Lors du compactage de la base de données.
• Lors de l'exécution d'opérations non journalisées.

• Une sauvegarde contient les éléments suivants :

• Le schéma.
• La structure de fichiers.
• Les données.

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

• Une portion du journal de transactions contenant l'activité de la base de

données depuis la dernière sauvegarde.

• La sauvegarde peut être lancée soit en utilisant des scripts TRANSACT-SQL, soit en
utilisant Enterprise Manager. Pour pouvoir effectuer des sauvegardes, vous devrez
être membre de l'un des 3 rôles suivants :
•sysadmin (rôle fixe de serveur).
•db_owner (rôle fixe de base de données).
•db_backupoperator (rôle fixe de base de données)

2.2 Les différents supports de sauvegarde

SQL Server met à votre disposition 3 types de supports pour effectuer vos sauvegardes :

• Sauvegarde sur disques.

• Sauvegarde sur bandes.
• Sauvegarde sur canaux nommés.

Dans la mesure du possible, effectuer 2 sauvegardes identiques lorsque vous faites une
opération de sauvegarde. En effet, vous pourrez ainsi limiter les risques d'incidents qui
peuvent subvenir. De plus, essayez dans la mesure du possible de ne pas centraliser les
sauvegardes dans le même lieu géographique.

2.3 Les Moments appropriés pour sauvegarder

La stratégie que vous allez mettre en place va dépendre pleinement du volume de données
que vous être prêt à perdre lorsqu'une défaillance quelconque survient au niveau du
serveur de base de données. Toutefois, il est conseillé d'effectuer des sauvegardes dans
différents cas.

2.3.1 Bases de données système

1/ Base de données Master

La base de données MASTER contient des informations sur toutes les bases de données
présentes sur le serveur. Si suite à une défaillance, vous devez effectuer la réinstallation
complète du serveur, la base de données Master devra donc être restaurée en premier pour
que l'administrateur puisse par la suite restaurer les bases de données utilisateurs.

Il conviendra de sauvegarder la base de données MASTER dans les cas suivants.

• Utilisation des commandes suivantes :

CREATE DATABASE, ALTER DATABASE, DROP DATABASE.
• Utilisation de la procédure stockée Sp_logdevice qui modifie le journal des transactions.
• Utilisation des procédures stockées suivantes : Sp_addserver, sp_dropserver,
sp_addlinkedserver qui permettent d'ajouter ou de supprimer des serveurs.
• Modification des options de sécurité, ajout de comptes de connexion.
• Modifications des options d'une base de données.
• Création des différentes unités de sauvegarde.
• Etc…

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

2/ Bases de données Msdb et Model

Dès lors que vous modifiez les bases de données Msdb et Model, vous devrez les
sauvegarder.

La base de données Msdb contient toutes les informations concernant les travaux, les
alertes et les opérateurs que vous avez crées sur le serveur de bases de données. Ainsi, si
cette base de données n'est pas sauvegardée, vous devrez recréer tous vos objets.

La base de données Model contient quand à elle le modèle de la création d'une nouvelle
base de données. C'est pourquoi son rôle est important et qu'elle doit être sauvegardée.

2.3.2 Bases de données utilisateurs

Les bases de données utilisateurs doivent également être sauvegardées régulièrement. Ces
opérations doivent se faire dans les cas suivants :

• Après la création d'une base de données utilisateur.

• Après le vidage du journal de transactions au moyen des commandes BACKUP LOG
WITH TRUNCATE ONLY ou BACKUP LOG WITH NO LOG. En effet, si vous effectuez ses
commandes, le journal de transactions ne contient plus d'enregistrements, ce qui rend
impossible la restauration en cas de problèmes.
• Après l'exécution d'opérations non journalisées. Ici, les opérations effectuées ne seront
pas inscrites dans le journal de transactions, ce qui rendra impossible la restauration.

2.4 Création des Unités de sauvegarde

Afin d'effectuer des sauvegardes de bases de données, vous devez dans un premier temps
crée des unités de sauvegarde. Ce sont des conteneurs qui vont stocker une sauvegarde de
base de données.

Une unité de sauvegarde peut être crée de 2 manières différentes :

• en utilisant Enterprise Manager.

• en utilisant la procédure stockée sp_addumpdevice.

Une fois que la procédure sp_addumpdevice est utilisée pour créer un fichier de
sauvegarde, il faut savoir

• que SQL Server crée les noms logiques et physiques dans la table sysdevices de la base
de données MASTER.
• qu'il est possible de créer au maximum 32 unités de sauvegarde.

Voici la syntaxe générale pour créer une unité de sauvegarde ainsi que 2 exemples
d'application :

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

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

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

USE master EXEC sp_addumpdevice 'disk', 'SauvegardeMaster',

'D:\Master\master.bak'

USE master EXEC sp_addumpdevice 'tape', 'SauvegardeMaster',

'\\.\tape0'

Si vous souhaitez n'effectuer une sauvegarde qu'une seule fois, il ne sera bien évidemment
pas nécessaire de créer une unité de sauvegarde. Vous pourrez dans ce cas utiliser le nom
du fichier de sauvegarde directement dans l'instruction Backup

Exemple :

USE master BACKUP DATABASE Test TO DISK =

'D:\SauvegardeBaseTest\Test.bak'

2.5 Création des Sauvegardes

Afin d'effectuer une sauvegarde de bases de données, il faut utiliser l'instruction BACKUP
DATABASE.

Voici sa syntaxe :

BACKUP DATABASE {nom_base_de_données |

@var_nom_base_de_données} TO <unité_sauvegarde> [,...n]
[WITH … ]

Cette instruction dispose d'une multitude de commandes. Je vous invite donc à visiter la
MSDN pour plus de détails à l'adresses suivante :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ba-
bz_35ww.asp

Vous pourrez ainsi voir les options de sauvegarde sur bande, les options pour sauvegarder
sur des disques multiples ...

Enfin, sachez que pour une gestion facilitée de votre stratégie, vous pourrez effectuer une
planification de travaux pour gérer vos différentes sauvegardes.

3. Planification d'une stratégie de Sauvegarde

3.1 Sauvegarde Complète

3.1.1 But d'une Sauvegarde Complète

Dans le cadre des sauvegardes de votre base de données, vous devrez avoir fait
préalablement au minimum une sauvegarde complète de votre base de données. En effet,
ce type de sauvegarde sert de point de référence en cas de défaillance d'une base de
données.

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

Une sauvegarde complète contient :

• L'ensemble des données et objets de la base de données.

• L'ensemble des tables systèmes de la base de données.
• L'ensemble des transactions ouvertes du journal de transactions. C'est à dire l'ensemble
des opérations journalisées.

Exemples d'application :

--Création d'une unité de sauvegarde testbak

USE master EXEC sp_addumpdevice 'disk' , 'testbak' ,
'D:\SauvegardeTest\test.bak'

--On utilise l'unité de sauvegarde pour effectuer la sauvegarde

complète de la base de données Test.
BACKUP DATABASE Test TO testbak

--On utilise l'unité de sauvegarde pour effectuer la sauvegarde

complète de la base de données Test en supprimant les
sauvegardes précédentes
BACKUP DATABASE Test TO testbak WITH INIT

--On peut effectuer la sauvegarde complète sans utiliser d'unité

de sauvegarde
BACKUP DATABASE Test TO DISK='D:\SauvegardeTest\test.bak'

3.1.2 Planification de sauvegarde complète

Cette stratégie s'applique dans les cas suivants :

• La base que vous souhaitez sauvegarder régulièrement a une faible taille.

• La base que vous souhaitez sauvegarder est peu ou pas modifiée.
• La quantité maximum d'informations que vous pouvez perdre se situe dans l'intervalle des
sauvegardes. C'est à dire que si vous effectuez des sauvegardes complète journalière et en
soirée, votre entreprise ne subira pas de préjudice dans le cas où l'une des base de données
devient défaillance en milieu de journée. (dans ce cas, la sauvegarde de la veille devant
être utilisée pour la restauration).

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

3.2 Sauvegarde des Journaux de Transactions

3.2.1 But de la sauvegarde des journaux

Un journal de transactions va contenir l'ensemble des opérations simples (Select, Update,
Delete, ...) qui ont été effectuées sur la base de données.

Vous devrez obligatoirement avoir fait une sauvegarde complète pour pouvoir effectuer ce
type de sauvegarde. La sauvegarde complète étant la référence.

Voici quelques notions qu'il est important de connaître :

•SQL Server sauvegarde le journal de transactions depuis la dernière instruction BACKUP

LOG réussie.

•Si une base de données devient défaillante, vous pourrez tout de même effectuer
l'instruction BACKUP LOG en utilisant l'option NO_TRUNCATE. Dans ce cas, le journal de
transactions sera sauvegardé normalement, depuis la dernière instruction BACKUP LOG
valide.

•Il existe une multitude d'options pour l'instruction BACKUP LOG. En l'occurence, les options
TRUNCATE_ONLY et NO_LOG permettent de tronquer la taille du journal de transactions
sans en faire la sauvegarde. Il est primordial de tronquer le journal de transactions de
temps en temps afin d'éviter qu'il atteigne une taille trop importante. Sachez que si le
journal de transactions est plein, les modifications apportées à la base de données ne
seront pas journalisées et vous ne pourrez donc pas les restaurer complètement en cas de
défaillance. Vous pouvez donc tronquer le journal de transactions en effectuant soit une
sauvegarde complète, soit en utilisant l'instruction BACKUP LOG WITH TRUNCATE_ONLY
ou BACKUP LOG WITH NO_LOG.

Exemple d'application :

--On utilise l'unité de sauvegarde pour effectuer la sauvegarde

des journaux de transactions de la base de données Test en
utilisant l'option NO_TRUNCATE
BACKUP LOG Test TO testbak WITH NO_TRUNCATE

3.2.2 Planification de la sauvegarde des journaux

Afin de disposer de l'activité de la base de données entre les différentes sauvegardes
complètes, vous pouvez mettre en place une planification de sauvegarde des journaux de
transactions au cours de la journée.

Vous limiterez ainsi le risque de perte de données.

Si une défaillance survient au niveau de la base de données, il suffira alors de restaurer la

dernière sauvegarde complète, puis d'appliquer la succession des journaux de transactions
jusqu'au moment de la défaillance.

Si la sauvegarde des journaux de transactions est réalisée dans un temps acceptable, cette
stratégie s'avèrera très efficace car elle limitera le risque de perte de données et optimisera
ainsi le temps de restauration en cas de défaillance du serveur de base de données.

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

3.3 Sauvegarde Différentielle

3.3.1 But d'une Sauvegarde Différentielle

Afin de réduire le temps de sauvegarde sur une base de données qui est fréquemment
utilisée, vous pourrez effectuer une sauvegarde différentielle.Celle ci s'effectue plus
rapidement qu'une sauvegarde complète. Toutefois, comme dit précédemment, une
sauvegarde complète devra avoir été faite pour servir de point de référence.

La sauvegarde différentielle contient :

• Toutes les parties de la base de données qui ont changé depuis la dernière sauvegarde
complète.
• Toutes les instructions survenant pendant l'opération de sauvegarde ainsi que les
transactions ouvertes du journal de transactions.

Exemples d'application :

--On utilise l'unité de sauvegarde pour effectuer la sauvegarde

différentielle de la base de données Test.
BACKUP DATABASE Test TO testbak WITH DIFFERENTIAL

3.3.2 Planification de sauvegarde différentielle

Si vous décidez de mettre en plus une solution de planification de sauvegarde différentielle,

il est conseillé d'inclure des journaux de transactions et des sauvegardes complètes.

La sauvegarde différentielle permet en effet de restaurer une base de données plus

rapidement en cas de défaillance, car elle ne va sauvegarder que les parties de la base de
données qui ont été modifiées depuis le dernière sauvegarde complète. Ainsi, en cas de
défaillance, l'administrateur de base de données n'aura juste qu'une sauvegarde complète à
restaurer, suivi de la sauvegarde différentielle et des journaux de transactions éventuelles.

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

3.4 Sauvegarde d'un fichier ou d'un groupe de fichiers

Si votre base de données est très volumineuse (plusieurs dizaines de Go de données),il est
bien évident qu'une sauvegarde complète et régulière de la base de données va prendre un
temps conséquent. Vous devrez alors séparer votre base de données en plusieurs fichiers et
planifier leur sauvegarde de manière cyclique au cours de la semaine.

Cette stratégie ne sera pas détaillée dans ces moindres détails dans la mesure où son
utilisation dépendra grandement de vos besoins au niveau de la base de données.

Cependant, voici un exemple d'application de cette stratégie * :

*:
Une sauvegarde complète est effectuée le lundi.
Les journaux de transactions sont sauvegardés périodiquement au cours de la semaine.
Les fichiers de données sont sauvegardés cycliquement.

4. Quelques Conseils

Afin d'améliorer les sauvegardes de façon générale, voici quelques considérations que vous
devrez prendre en compte lors du déploiement de votre stratégie :

• Lorsque vous effectuez la sauvegarde sur des contrôleurs de disques multiples, celle-ci
sera beaucoup plus rapide.
• Le temps nécessaire pour accomplir une sauvegarde de base de données est variable et
va dépendre de la performance de votre matériel (disque dur , lecteur de bande ...).
• De façon générale, la sauvegarde sur un disque dur est plus performante que sur un
lecteur de bande.
• Dans la mesure où la sauvegarde demande des ressources système au niveau disque,
processeur ..., les utilisateurs de base de données peuvent rencontrer une baisse de
performance au niveau du serveur de bases de données. C'est la raison pour laquelle, il
sera préférable d'effectuer les sauvegardes lorsqu'il y aura peu d'activité au niveau du
serveur.

www.udivers.com tssri-reseaux@hotmail.fr
www.udivers.com tssri-reseaux@hotmail.fr

Afin d'éviter de sauvegarder des bases de données corrompues, il est impératif de vérifier
l'intégrité des données avant d'effectuer des sauvegardes de bases de données. La raison
est simple : si une base de données corrompue a été sauvegardée, la restauration sera
compromise si cette base venait à être défaillante ultérieurement ...

Pour éviter ce genre de désagrément, je vous invite donc à vérifier la cohérence des bases
de données en utilisant des commandes DBCC. Sur la MSDN, vous pourrez trouver une
multitude d'information sur ces commandes à l'adresse suivante :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_217n.asp

Si vous avez une erreur qui est retournée par une de ces commandes, cela veut peut-être
dire que l'une des bases de données est corrompues, auquel cas, celle-ci devra être
restaurée dans les plus brefs délais afin d'éviter des désagréments.

Enfin, il est conseillé de tester la validité de ses sauvegardes de temps en temps. Ainsi, sur
un serveur de test, vous pourrez restaurer les différentes sauvegardes et vérifier que celle-
ci sont correctes. Ceci permettra d'éviter des pertes de données non négligeables pour une
entreprise en cas de problèmes au niveau du processus de sauvegarde.

Conclusion

Ce document vous a donc permis de vous rendre compte que les sauvegardes sont un
élément essentiel pour administrer de façon optimal un serveur de bases de données. Les
méthodes que vous choisirez pour sauvegarder vos bases de données vont donc
directement conditionner les données de votre entreprise.

Disposant des contraintes techniques et fonctionnelles de l'entreprise, il conviendra donc à

l'administrateur de bases de données d'effectuer tout ce qui est en son pouvoir pour
réfléchir à une solution de sauvegarde, l'analyser dans ses moindres détails et la tester. Il
sera ainsi apte à remettre un serveur de bases de données le plus rapidement possible, en
perdant le moins de données en cas d'un éventuel sinistre

www.udivers.com tssri-reseaux@hotmail.fr