Sur cette page
Microsoft Exchange Server : Notions de base sur la
sauvegarde et la restauration
Ce qu'il faut sauvegarder
Données relativement statiques
Données dynamiques
Partitionnement des serveurs Exchange
Composants principaux d'Exchange
Autres composants
Méthodes de sauvegarde Exchange
Sauvegarde en ligne et sauvegarde en mode autonome
Types de sauvegardes en ligne Normale (complète)
Copie
Incrémentielle
Différentielle
Sauvegarde en ligne
Bases de données Exchange
État normal d'une base de données Exchange
Lecture du fichier de contrôle
Comprendre la sauvegarde en ligne
Restaurer les bases de données Exchange
Logiciels de sauvegarde
Avantages des solutions tierces parties
Performances de la sauvegarde et de la restauration
Sélectionnez un matériel à hautes
performances
Équilibrez sauvegarde et restauration
Stratégies pour les sauvegardes en ligne
Sauvegarde normale plus une différentielle
Sauvegarde quotidienne
Restaurer des composants Exchange Server
Une procédure de restauration minutieuse
Disque système
Partition de bases de données
Disque système
Disque des journaux de transactions
Base de données Exchange
Restauration en utilisant un logiciel de sauvegarde tierce
partie comme ARCserve ou BackupExec
Complications potentielles
Perte de EDB.CHK
Un trou dans la séquence des fichiers-journaux
Retour nécessaire vers une sauvegarde plus
ancienne
Restauration totale d'un serveur
Procédures tierces parties
Microsoft Exchange Server : Notions de base sur la
sauvegarde et la restauration
La sauvegarde et la restauration de tout ou partie d'un
serveur Exchange nécessitent une connaissance de l'endroit
où se trouvent les données et de la manière dont
elles sont sauvegardées et restaurées.
Récupération signifie restauration ou reconstruction
à partir de fichiers de sauvegarde des données
statiques, comme le système d'exploitation et les
logiciels applicatifs, ainsi que des données dynamiques,
comme les bases de données et les journaux de messages. Ce
chapitre diffère des autres ayant traité de la
sauvegarde/restauration en ce qu'il présente une vue
d'ensemble des mécanismes.
Ce qu'il faut sauvegarder
Cette discussion se fonde sur un serveur Windows NT
dédié à Exchange. Cela ne signifie pas que les
techniques et procédures décrites ici ne sont pas
applicables à des serveurs supportant plusieurs fonctions,
mais plutôt que certains ajustements et
interprétations sont spécifiques à
l'environnement en question.
Vous devez sauvegarder deux types de données.
Données relativement statiques
-
Le système d'exploitation, qui se trouve être
dans ce cas Windows NT et tout Service Pack ou correctif
logiciel.
-
Les applications logicielles (Exchange).
-
Les autres logiciels liés à l'application de
production, comme les outils de sauvegarde tierce partie, les
logiciels de gestion du système, etc.
-
Les applications utilisateurs, comme les applications
ASP, les agents de boîtes aux lettres et les logiciels
de workflow.
-
Les scripts de gestion.
Données dynamiques
-
Les bases de données Exchange et fichiers relatifs,
comme les bases de données de l'annuaire et de la banque
d'informations, les fichiers-journaux de transactions et les
fichiers de point de contrôle.
-
La "base de données" du MTA.
-
Les journaux de suivi des messages.
Partitionnement des serveurs Exchange
La configuration Exchange Server dont il est question ici
est une structure classique largement répandue pour les
serveurs dédiés à Exchange. Elle implique trois
zones disques de base :
-
le disque système qui contient Windows NT, le
fichier de pagination, les exécutables Exchange,
d'autres applications logicielles et parfois des données
dynamiques d'Exchange comme des espaces de travail ou la base
de données du MTA ;
-
le disque des journaux de transactions, un disque
complètement dédié aux fichiers-journaux de
transactions des bases de données d'Exchange. Ceci est
un élément fondamental pour les conseils
d'optimisations des performances, largement adopté dans
les faits ;
-
une partition étendue pour les bases de
données, habituellement, un RAID 5 fournissant une
unique partition Windows NT volumineuse,
protégée contre les pannes de disques
individuels.
Ce type de partitionnement n'est pas une règle
figée, et le détail de la localisation de composants
particuliers (base de données du MTA, "espaces de travail"
de l'annuaire et de la banque et journaux de suivi des
messages) dépend à la fois de préférences
personnelles et du besoin d'équilibrer la charge entre les
différents disques.
Remarque Il s'agit d'une configuration très simple qui
peut être améliorée en utilisant des
caractéristiques matérielles plus poussées pour
obtenir un niveau plus élevé de protection pour les
différents types de données. Si vous êtes
concerné par la disponibilité des serveurs Exchange,
envisagez de protéger les disques grâce à une
quelconque forme de RAID comme une mise en miroir du disque
système et du disque des journaux de transactions, et
à une partition RAID 5 pour les bases de
données.
Composants principaux d'Exchange
Voici un exemple de partitionnement d'Exchange Server :
C:\Disque système
D:\Journaux de transactions
E:\Bases de données Exchange
Le tableau suivant montre la répartition de certains
des composants principaux d'Exchange à travers ces
différents disques.
Description | Emplacement | Fichiers |
|---|
Exécutables Exchange, modèles,
compléments, etc. | C:\exchsrvr |
|
Base de données de l'annuaire | E:\exchsrvr\dsadata | DIR.EDB |
Bases de données de la banque
d'informations | E:\exchsrvr\mdbdata | PRIV.EDB, PUB.EDB |
Fichiers-journaux de transactions de
l'annuaire | D:\exchsrvr\dsadata | EDB.LOG, EDBXXXXX.LOG |
Fichiers-journaux de transactions de la
banque d'informations | D:\exchsrvr\mdbdata | EDB.LOG, EDBXXXXX.LOG |
Base de données du MTA | C:\exchsrvr\mtadata |
|
Fichier de point de contrôle de
l'annuaire | C:\exchsrvr\dsadata | EDB.CHK |
Fichier de point de contrôle de la
banque d'informations | C:\exchsrvr\mdbdata | EDB.CHK |
Fichiers de travail de l'annuaire | C:\exchsrvr\dsadata | TMP.EDB |
Fichiers de travail de la banque
d'informations | C:\exchsrvr\mdbdata | TMP.EDB |
Fichiers-journaux de suivi des
messages | C:\exchsrvr\tracking.log |
|
Autres composants
Une installation Exchange contient bien d'autres composants
qui ne sont pas décrits ci-avant, comme les données
du service de messagerie Internet (espace de travail, espace de
journalisation), les données de l'Agent de synchronisation
d'annuaires (DXA), le bureau de poste du connecteur MS-MAIL,
etc. La sauvegarde et la restauration d'Exchange Server sont
des sujets complexes qui impliquent une série de
composants qui doivent cohabiter. Cette discussion
s'intéresse intentionnellement aux composants centraux qui
se trouvent être les clés de voûte de la
sauvegarde et de la restauration des données contenues
dans les boîtes aux lettres utilisateurs et dans les
dossiers publics.
Avantages du partitionnement
Partitionner un serveur Exchange est en général
bénéfique du point de vue des performances et de la
récupération. Avec des sauvegardes appropriées,
la structure de partitionnement décrite
précédemment peut préserver toutes les
données utilisateurs si une partition est perdue. Voici
quelques exemples :
Si le disque système est détruit, –
il doit être reconstruit avant qu'Exchange ne fonctionne
à nouveau –, les données utilisateurs
sont protégées. Si le système tombe en panne,
les bases de données seront incohérentes.
Cependant, le fait de rejouer tous les fichiers-journaux de
transactions ramènera les bases de données à
un état cohérent car le disque des journaux de
transactions était sain. Comme le fichier de point de
contrôle est présumé perdu avec la panne du
disque système, tous les fichiers-journaux doivent
être rejoués.
Si le disque des journaux de transactions est
détruit, vous perdez la possibilité de rejouer les
fichiers-journaux remplis depuis la dernière sauvegarde.
Cependant, vous ne devriez pas avoir à rejouer ces
transactions à moins que la base de données ne soit
endommagée. Par conséquent aucune donnée n'est
perdue.
Si la partition des bases de données est
endommagée, aussi longtemps que le disque des journaux
de transactions reste intact vous pourrez restaurer la
dernière sauvegarde et toutes les transactions seront
rejouées. Le fichier de point de contrôle doit
également rester intact (sur le disque système),
garantissant que seuls les journaux appropriés seront
rejoués, se protégeant ainsi d'une éventuelle
corruption incluant une incohérence entre les bases de
données restaurées et les fichiers-journaux sur
disque.
Cette configuration augmente également la
sécurité, mais vous devez cerner les relations qui
existent entre les différents composants. Si vous ne les
maîtrisez pas, vous pouvez, par inadvertance, perdre des
données lorsque vous essaierez de récupérer tout
ou partie d'Exchange Server.
Méthodes de sauvegarde Exchange
Sauvegarde en ligne et sauvegarde en mode autonome
En ligne : Nécessite que le service respectif (annuaire
ou banque d'infirmations) soit démarré. Cela
n'interrompt pas la messagerie gérée par le serveur
Exchange. Vous pouvez inclure le registre Windows NT dans
la sauvegarde ; vous pouvez parfaitement sauvegarder le
service annuaire même si le service banque d'informations
n'est pas démarré.
En mode autonome : Nécessite que tous les services
Exchange soient arrêtés. C'est une sauvegarde
fichiers. Vous exécutez simplement NTBACKUP.EXE pour
sauvegarder tous les fichiers des disques que vous
sélectionnez, y compris le registre de
Windows NT.
Types de sauvegardes en ligne Normale (complète)
L'intégralité des bases de données de la
banque d'informations et de l'annuaire est sauvegardée.
Les journaux de transactions sont sauvegardés puis
purgés, définissant un contexte pour des sauvegardes
incrémentielles ou différentielles.
Copie
Cela ne supprime pas de fichiers-journaux et ne fournit pas
un contexte pour des sauvegardes incrémentielles ou
différentielles. Une "photo" des bases de données est
prise, sans interférer avec les autres routines de
sauvegarde. Cela s'avère pratique lorsque vous souhaitez
reproduire un système à des fins de tests.
Incrémentielle
Un sous-ensemble de la banque d'informations ou de
l'annuaire est sauvegardé, ne prenant en compte que les
changements effectués depuis la dernière sauvegarde
complète ou incrémentielle (la plus récente des
deux). Une sauvegarde incrémentielle écrit les
fichiers .LOG (seulement) sur la bande, puis les supprime du
disque dur, définissant un contexte pour la prochaine
opération de sauvegarde. En fait, une restauration
incrémentielle nécessite la bande de la dernière
sauvegarde complète et les bandes des sauvegardes
incrémentielles effectuées jusqu'à la panne du
système. Par exemple, supposez qu'une sauvegarde
complète ait été réalisée le dimanche
soir et une sauvegarde incrémentielle chaque jour de la
semaine. Si une panne survient le vendredi matin, une
restauration complète doit être effectuée (bande
du dimanche soir) plus une restauration de chaque sauvegarde
incrémentielle (bandes jusqu'au jeudi soir inclus). Les
services ne doivent pas être redémarrés tant que
la dernière bande n'a pas été
restaurée.
Différentielle
Cela sauvegarde les changements apportés à la
banque d'informations ou à l'annuaire depuis la
dernière sauvegarde complète (normale) ou
incrémentielle, bien que la plupart des administrateurs
choisissent de ne pas mélanger les deux types de
sauvegardes, incrémentielle et différentielle, dans
un même jeu. Une sauvegarde différentielle prend en
compte seulement les fichiers .LOG et ne les supprime pas du
disque dur. Si une restauration des bases de données et
des fichiers-journaux est requise, seules deux bandes sont
nécessaires : la dernière bande de sauvegarde
complète et la dernière bande de sauvegarde
différentielle. Si les journaux de transactions sont
intacts depuis la dernière sauvegarde complète, seule
la bande de cette sauvegarde complète est nécessaire
car le processus de restauration rejouera les journaux de
transactions jusqu'au fichier EDB.LOG, ce qui restaurera toutes
les transactions effectuées jusqu'à la date du jour.
Ne sŽlectionnez pas Supprimer toutes les données
existantes quand vous restaurez dans ce cas : les
fichiers-journaux créés jusqu'à la date du jour
seraient alors effacés.
Sauvegarde en ligne
La meilleure démarche à adopter pour
sécuriser les bases de données Exchange est la
sauvegarde en ligne, qui doit être une partie importante
de vos routines de gestion des bases de données. C'est la
seule procédure standard qui accède
systématiquement à chaque page de la base de
données et détecte toute altération au niveau
physique.
En interne, au niveau le plus bas, chaque base de
données Exchange est constituée de pages de
4 Ko, chacune avec un code de contrôle d'erreur que
le moteur de la base de données vérifie chaque fois
qu'il y accède.
Une sauvegarde en mode autonome copie les fichiers physiques
sur le média de sauvegarde sans vérifier une
éventuelle altération. Ceci peut être
ennuyeux : les utilisateurs Exchange détectent
parfois une corruption physique et découvrent que celle-ci
a été copiée dans chacune des sauvegardes
récentes réalisées en mode autonome. Une
sauvegarde en ligne détecte la corruption
instantanément, et vous pouvez alors recourir à la
dernière sauvegarde et restaurer une base de données
opérationnelle.
Bases de données Exchange
Pour comprendre comment fonctionne la sauvegarde en ligne,
vous devez savoir à quoi ressemble une base de
données Exchange pendant son fonctionnement normal. Trois
composants principaux sont impliqués :
la base de données (par exemple
PRIV.EDB) ;
une séquence de fichiers-journaux de transactions
(le fichier-journal courant EDB.LOG, plus une série
continue de journaux précédents
EDBXXXXX.LOG) ;
le fichier point de contrôle (EDB.CHK).
État normal d'une base de données Exchange
Lors d'une exécution normale, la base de données
seule (PRIV.EDB) n'est jamais à jour. Le service de la
banque gère un tampon mémoire de grande taille
comprenant les données de la banque et transfère ces
dernières périodiquement sur le disque. Les
détails du processus ne sont pas importants ici. Le point
clé est qu'il existe un décalage au niveau de la mise
à jour du fichier de la base de données sur le
disque.
Ce décalage compromet l'intégrité de la base
de données si une panne soudaine survient. Pour se
prémunir contre ce type d'incident, les pages sont
sécurisées par le fait qu'elles sont envoyées
vers les fichiers-journaux. Cette méthode est beaucoup
plus rapide que de mettre à jour la base de données
(qui implique la charge complémentaire de mises à
jour de nombreux index, d'accès disque aléatoires,
etc.) et permet à Exchange de maintenir un haut niveau de
performances même si les charges sont importantes.
Quand le service de la banque s'arrête proprement,
toutes les pages se trouvant dans le tampon mémoire sont
écrites dans le fichier de la base de données,
l'amenant ainsi à un état cohérent avant que le
service ne s'arrête. Si le service de la banque
s'arrête inopinément, la base de données est
laissée dans un état incohérent ou inconnu, mais
toutes les informations décrivant comment la ramener
à un état correct existent dans les fichiers-journaux
de transactions. Rejouer les journaux vers la base de
données ramène celle-ci dans l'état
cohérent qui aurait dû être le sien après
un arrêt normal.
Lecture du fichier de contrôle
Le fichier de contrôle, crucial pour le processus de
retransfert, maintient des informations sur la séquence
des fichiers-journaux et leurs bases de données
respectives, et pointe sur l'endroit à partir duquel les
données devront être rejouées pour ramener la
base à un état cohérent.
Pour visualiser le fichier point de contrôle, utilisez
eseutil /mk edb.chk. Assurez-vous de référencer le
fichier EDB.CHK correct. Le point de contrôle courant est
référencé par trois nombres : le premier se
réfère à la génération du fichier, et
les deux suivants font référence à un
décalage au sein de ce fichier.
Les numéros de décalage ne sont pas importants
ici. Néanmoins, le numéro de génération est
utilisé pour construire le nom du fichier-journal (par
exemple, EDB020CA.LOG). Si le numéro de
génération est supérieur d'une unité au
plus grand numéro actuel utilisé par les
fichiers-journaux, alors le point de contrôle se trouve
dans le fichier-journal courant (EDB.LOG), qui sera
renommé, lorsque sa taille maximale sera atteinte, à
partir de ce numéro de génération. Dans la
plupart des systèmes le numéro de
génération de contrôle est inférieur de
plusieurs unités au numéro courant.
Comprendre la sauvegarde en ligne
Une sauvegarde en ligne fonctionne en extirpant toutes les
pages de la base de données au travers des API de
sauvegarde. Le système continue de fonctionner pendant
l'exécution de la sauvegarde, permettant un accès
normal aux utilisateurs, une mise à jour permanente des
fichiers-journaux, etc. Pour éviter la perte des
modifications apportées aux pages déjà
sauvegardées, elles sont écrites dans des fichiers de
correction temporaires (.PAT ; par exemple :
PRIV.PAT) qui sont à leur tour sauvegardés puis
appliqués à une base de données restaurée
avant que les transactions ne soient rejouées.
Voici le processus de sauvegarde en ligne :
1. Sauvegarde du point de contrôle courant vers un
autre emplacement dans le fichier de contrôle :
sauvegarde du point de contrôle.
2. Copie de la base de données.
3. Copie du fichier .PAT.
4. Force un transfert complet des transactions en
créant un nouveau fichier-journal de transactions.
5. Sauvegarde de tous les fichiers-journaux de transactions
depuis celui référencé lors de la sauvegarde du
point de contrôle jusqu'à celui qui précède
le point courant.
6. Suppression de tous les fichiers-journaux antérieurs
à celui référencé lors de la sauvegarde du
point de contrôle.
L'intérêt est qu'il reste sur le disque une
séquence de fichiers-journaux commençant par le
premier requis s'il fallait rejouer les transactions vers une
base de données restaurée.
Restaurer les bases de données Exchange
En réalité, la restauration correspond à un
de ces deux scénarios : restauration de toutes les
bases de données si l'ensemble des partitions sont
détruites ou restauration d'une base de données dans
le cas d'un désastre mineur n'affectant qu'une partie des
disques.
Si le fichier PRIV.EDB est le seul endommagé sur un
serveur Exchange par exemple, vous pouvez le restaurer en deux
étapes très simples :
1. Remettez à nouveau sur disque tout ce dont vous
disposez sur la bande.
2. Appelez Exchange pour initier les procédures de
récupération.
Cette seconde étape est automatiquement
déclenchée par la plupart des produits de sauvegarde
et de restauration. Cependant, avant d'initier la
récupération, il peut s'avérer judicieux de
vérifier que tout se trouve sur le disque à l'endroit
où vous pensez que cela devrait être. Restaurer les
mauvaises données dans un cas de récupération
peut engendrer des problèmes énervants. Par
conséquent, une vérification rapide n'est pas
inutile.
Juste après la phase de restauration du processus de
récupération, ces fichiers devraient se trouver sur
le disque :
PRIV.EDB, restauré à partir d'une
bande ;
PRIV.PAT, restauré à partir d'une
bande ;
EDB.CHK, le fichier de contrôle, non affecté
par la phase de restauration ;
EDBXXXXX.LOG, fichiers restaurés à partir d'une
bande ;
série de fichiers-journaux jusqu'au fichier courant
EDB.LOG, non affectés par la restauration.
Quand le service de la banque démarre, il initialise la
base de données logicielle, qui vérifie l'état
des données sur le disque. Le message "restauration en
cours" indique au logiciel de base de données que celle-ci
a été restaurée à partir d'une bande.
Le logiciel de base de données applique, à la base
de données, les modifications contenues dans le fichier
.PAT, trouve dans le fichier de contrôle la valeur du
point de contrôle ˆ la date de la dernire sauvegarde,
puis tente d'ouvrir le fichier-journal référencé
par le point de contrôle. Si cette opération
réussit, il commence à rejouer les transactions vers
la base de données jusqu'à ce qu'il atteigne la
dernière transaction réalisée se trouvant dans
le fichier-journal courant EDB.LOG. La base de données est
maintenant cohérente et l'initialisation de la banque peut
continuer.
Remarque Cette procédure peut varier en fonction de la
partie d'Exchange qui a été endommagée et des
fichiers qui ont été restaurés. Ce sujet est
traité au Chapitre 9.
Logiciels de sauvegarde
Exchange installe une version de NTBACKUP.EXE qui permet de
sauvegarder les bases de données Exchange en ligne comme
décrit précédemment, ou bien de restaurer une
sauvegarde en ligne à partir des bandes. À l'heure
où s'écrit ce livre, quelques revendeurs fournissent
des modules (agents) Exchange qui satisfont au logo du
programme BackOffice.
La liste suivante n'est pas exhaustive :
Cheyenne ARCserve ;
Seagate BackupExec ;
Legato NetWorker.
Avantages des solutions tierces parties
Voici quelques bonnes raisons de choisir une des solutions
tierces parties pour sauvegarder vos serveurs de production
Exchange :
Administration et gestion. Certains des produits tierces
parties gèrent les opérations de sauvegarde à
partir d'un point central et offrent des possibilités
étendues pour gérer les cycles de sauvegardes, les
ensembles de support, etc. De plus, ils fournissent une
structure clés en main pour gérer les sauvegardes
Exchange, structure que vous devez développer si vous
utilisez seulement NTBACKUP.
Performance. Il existe des différences significatives
de performances entre NTBACKUP et certaines des solutions
tierces parties, (elles devraient disparaître avec les
prochaines versions de Windows NT). Quoi qu'il en
soit, aujourd'hui, les tailles énormes de bases de
données possibles avec Exchange 5.5 peuvent avoir
un impact sérieux sur les performances des
sauvegardes. Par exemple, établissons une comparaison
des vitesses de sauvegarde sur un serveur multiprocesseur
Intel, avec les bases de données Exchange sur un
RAID 5 de sept disques et un seul lecteur DLT 35/70
(Exchange 5.5 avec Windows NT 4.0 et Service Pack
3, compression matérielle activée) :
Fonctionnalités. Vous devez également
évaluer comment l'outil gère les fichiers-journaux
de transactions lors d'une sauvegarde en ligne. NTBACKUP
sauvegarde toutes les bases de données et tous les
fichiers-journaux à partir du point de contrôle au
moment où la sauvegarde démarre. Il supprime
ensuite tout fichier-journal antérieur, laissant le
système dans un état où il pourra rejouer les
transactions après une restauration. Si la restauration
d'une sauvegarde échoue à cause d'un problème
de support ou pour d'autres raisons, vous devez trouver la
sauvegarde antérieure à celle dont la restauration
a échoué pour obtenir une base de données
cohérente, mais vous ne pouvez pas rejouer les
transactions car NTBACKUP a supprimé les fichiers. Si
vous utilisez NTBACKUP, vous devez implémenter des
processus additionnels pour sauvegarder les fichiers-journaux
qui peuvent être effacés.
Les solutions tierces parties sauvegardent, en
général, tous les fichiers-journaux avant de
supprimer ceux antérieurs à celui
référencé par le point de contrôle au
commencement de la sauvegarde. Le processus de restauration
recopie tous ces fichiers de telle sorte que, si la base de
données est corrompue (encore une fois, probablement
dû à une altération du média), il soit
possible de rejouer toutes les transactions une fois que la
sauvegarde antérieure a été restaurée.
Performances de la sauvegarde et de la restauration
Voici un récapitulatif des principes fondamentaux.
Après avoir choisi le logiciel, les performances de
sauvegarde et de restauration dépendent de deux choix de
configuration matérielle.
Sélectionnez un matériel à hautes
performances
Commencez par choisir un matériel de sauvegarde
très performant (ce qui signifie aujourd'hui choisir des
lecteurs DLT 35/70) et un sous-système disque
également très performant (implémentation
matérielle d'un système RAID avec contrôleur
cache, tout en gardant à l'esprit que celui-ci doit
être protégé par batterie et ECC).
Le matériel de sauvegarde rapide ainsi que le
sous-système disque performant doivent être
connectés avec le maximum de bande passante disponible,
ceci afin d'atteindre des performances optimales. Cela signifie
aussi que tous les composants doivent être installés
dans le même serveur ou dans le même cluster. En
général, vous ne pourrez obtenir des ratios de
sauvegarde élevés (> 30 Go/heure) à
travers une quelconque forme de connexion réseau.
Équilibrez sauvegarde et restauration
Il n'y a pas d'intérêt à disposer de
matériel de sauvegarde rapide si le sous-système
disque ne suit pas. Pour obtenir des performances optimales,
équilibrez les deux côtés du processus de
sauvegarde et de restauration en effectuant, si possible, des
lectures et écritures sur plusieurs
périphériques en parallèle. Par exemple, vous
obtiendrez un débit plus élevé en utilisant un
RAID de douze disques au lieu d'un RAID de six disques. Les
revendeurs de matériel possèdent des techniques pour
évaluer les capacités de débit ;
assurez-vous donc que leur matériel supportera vos
exigences de performances au niveau de la sauvegarde et de la
restauration.
Stratégies pour les sauvegardes en ligne
Quels sont les rôles joués par les différents
types de sauvegarde (complète, incrémentielle et
différentielle) et quelle doit en être la
fréquence de réalisation ?
La première étape de cette stratégie consiste
à désactiver l'enregistrement circulaire :
celui-ci ne conserve, en effet, qu'une fenêtre de quelques
fichiers-journaux, juste assez pour permettre de disposer d'une
base de données dans un état cohérent après
une panne. Il supprime les anciens fichiers-journaux, ce qui
implique que vous ne pouvez quasiment jamais rejouer les
transactions à partir d'une sauvegarde. L'enregistrement
circulaire a néanmoins son intérêt. Si vous
savez que vous n'aurez jamais besoin de sauvegarder un serveur
Exchange (par exemple parce qu'il a été installé
dans un environnement de tests, ou bien parce qu'il
s'avère être un serveur de connecteurs), alors
l'enregistrement circulaire évitera que le disque ne se
remplisse.
Il y a deux approches classiques pour une sauvegarde en
ligne :
effectuez une sauvegarde complète chaque
nuit ;
effectuez une sauvegarde en ligne régulière
(hebdomadaire), plus des sauvegardes incrémentielles ou
différentielles.
Sauvegarde normale plus une différentielle
En elles-mêmes, les sauvegardes incrémentielles
sont insuffisantes. Si ce sont les seules dont vous disposez,
vous devez savoir qu'une récupération implique trop
d'opérations de restauration individuelles, augmentant, de
fait, le risque de plantage dû au fait que vous vous
retrouvez avec un trou dans la séquence des
fichiers-journaux à rejouer.
Un scénario plus opérationnel est de réaliser
une sauvegarde complète en ligne hebdomadairement (par
exemple, le dimanche soir quand l'utilisation du système
s'avère minimale) et une sauvegarde différentielle
quotidiennement durant la nuit. Pour effectuer une
récupération dans ce cas-là, vous restaurez la
sauvegarde en ligne, restaurez la dernière
différentielle de la nuit passée (qui remet tous les
fichiers-journaux créés entre dimanche et la nuit
passée), puis rejouez les fichiers-journaux de
transactions.
Avantages
Peu de bande utilisée.
Cela diminue les possibilités que la sauvegarde
contienne une corruption logicielle au niveau de
l'entité de la banque (cette méthode ne
protège pas une éventuelle corruption d'une page de
la base de données). Parce qu'une corruption au niveau
de la banque demande plusieurs jours avant d'être
évidente, la détecter avec une sauvegarde
différentielle régulière peut permettre
d'éviter de l'enregistrer lors d'une sauvegarde
complète. Inconvénients
Si votre sauvegarde détecte une corruption physique
(mauvaise page), vous devez retourner à la dernière
sauvegarde en ligne (de la semaine précédente) et
rejouer tous les journaux d'une semaine de production
complète. Ceci prend un certain temps.
Les serveurs qui hébergent de nombreux utilisateurs
ou fortement sollicités peuvent générer de
nombreux fichiers-journaux (jusqu'à plusieurs centaines
par jour). Le temps nécessaire pour rejouer les
transactions dépend du nombre et du type de celles
enregistrées dans le fichier-journal, mais un taux
classique est compris entre 1 à 2 minutes par
fichier-journal (testé sur l'un de nos systèmes
pour estimer cette valeur). Rejouer une journée de
fichiers-journaux de transactions peut prendre plus de temps
que de restaurer la base de données complète.
Sauvegarde quotidienne
Voici la stratégie la plus simple : effectuez une
sauvegarde complète en ligne de toutes les bases de
données Exchange chaque nuit.
Avantages
C'est simple. Chaque sauvegarde est identique, d'un point
de vue réalisation ; chaque restauration
également.
Il s'agit de la plus rapide des méthodes pour
détecter et corriger les corruptions physiques. Si la
sauvegarde de la nuit passée a fonctionné, vous
pouvez en déduire qu'il n'y a pas de corruption. Si, en
revanche, elle a échoué, vous pouvez en
déduire que la corruption a été introduite
dans la journée ; tout ce que vous avez à
faire est de restaurer la sauvegarde précédente et
rejouer les fichiers-journaux de transactions de la
journée. Inconvénients
Vous pouvez avoir à utiliser de nombreuses bandes,
tout particulièrement si vous sauvegardez vers un pool
de lecteurs DLT.
Si vous détectez une corruption logicielle, vous
aurez peut-être à retourner plusieurs jours en
arrière pour trouver une sauvegarde qui ne la contienne
pas, puis rejouer les journaux de plusieurs journées de
production (si votre logiciel de sauvegarde les a bien
sauvegardés). En général cela prend plus de
temps que si vous utilisez la différentielle.
Malgré tout, les sauvegardes quotidiennes
représentent la plus simple et la plus pratique des
méthodes.
Restaurer des composants Exchange Server
Cette section présente des exemples techniques et
traite de la problématique induite par la restauration de
différentes parties d'Exchange Server. La plupart du
temps, récupérer un serveur ne signifie pas devoir
réinstaller un serveur complet, mais plutôt corriger
un composant comme un disque système ou une partition de
bases de données. Dans ce cas, essayez de restaurer le
service en un minimum d'étapes. Par exemple, si le disque
système se corrompt mais que la partition des bases de
données reste intacte, vous pouvez gagner du temps si vous
pouvez récupérer cette situation sans restaurer les
bases de données. Si vous avez besoin de restaurer un
serveur après une panne, référez-vous aux
procédures présentées dans la section
"Récupération d'un serveur complet", plus loin dans
ce chapitre.
Une procédure de restauration minutieuse
Tout d'abord, vous devez parfaitement maîtriser ce qui
a besoin d'être restauré. Il est fort probable que
vous n'ayez pas à restaurer toutes les partitions, et
quand bien même un serveur devrait être reconstruit,
il est probable que la plupart des disques, voire tous les
disques, pourront être déplacés de l'ancien
serveur vers le nouveau.
Pour décider de ce qui doit être restauré,
vous devez connaître ce qui est installé sur les
différentes partitions et comment tout cela est
relié.
Disque système
Les éléments les plus importants d'un disque
système sont :
Windows NT (et tous ses détails de
configuration) ;
les exécutables Exchange, plus des fichiers de
travail (par exemple les fichiers "base de données" du
MTA qui peuvent se trouver sur le disque) ;
le logiciel de sauvegarde tierce partie, avec les
informations de configuration et d'état.
Un endommagement (corruption logicielle) d'un de ces
composants (même Windows NT) peut probablement ne pas
nécessiter une restauration complète du disque
système. </<h4>p>Journaux des transactions
Si votre serveur est configuré pour des performances
optimales, le disque des journaux de transactions ne doit
contenir rien d'autre que les journaux de transactions
Exchange. Pour une récupération, installez un disque
sain, créez la structure de base des répertoires et
redémarrez les services Exchange.
Avec les bandes appropriées de sauvegarde en ligne
d'Exchange, les journaux de transactions vous permettent de
rejouer les transactions jusqu'au jour en question sans perte
de messages. Parce que les fichiers-journaux sont utilisés
pour les sauvegardes des bases de données Exchange, il
sont gérés par le logiciel de sauvegarde. Après
une sauvegarde en ligne réussie, les journaux de
transactions "anciens" (ceux relatifs à la
précédente sauvegarde en ligne) sont purgés. Si
la partition des journaux est corrompue (dû par exemple
à une erreur du sous-système disque), vous perdez la
possibilité de pouvoir rejouer les transactions après
une restauration. Ce n'est pas un problème car vous n'avez
à rejouer des transactions qu'en cas de corruption d'une
base de données ou face à un problème
semblable.
L'aspect le plus important à comprendre est que les
fichiers-journaux ne possèdent pas une valeur dans le
temps : ils sont utiles s'ils ont été
créés depuis la dernière sauvegarde en ligne. Il
n'y a pas de raison de devoir sauvegarder ou restaurer les
fichiers-journaux de transactions indépendamment des bases
de données auxquelles ils sont rattachés.
Partition de bases de données
Les bases de données représentent la partie d'une
sauvegarde qui a le plus de chance d'être restaurée.
Ceci n'est pas dû au fait qu'elles ont plus de chance
qu'une autre partie du système, de devenir corrompues,
mais plutôt qu'une restauration (plus les transaction
rejouées) est, en général, le seul moyen (ou le
plus simple) de récupérer les bases de données
après une corruption.
La procédure pour récupérer une base de
données seule (c'est-à-dire hors du contexte d'une
restauration complète) est extrêmement simple.
Cependant, pour une banque volumineuse ou un serveur très
occupé, cela peut prendre un certain temps pour
réaliser les deux opérations suivantes :
Restaurer les fichiers de base de données sur le
disque. Le temps requis dépend de la structure de la
partition de la base de données, mais la plupart des
contrôleurs RAID 5 actuels ne semblent pas
être optimisés pour des opérations de
restauration, ne donnant que des taux de l'ordre de 20 à
25 Go/heure.
Rejouer les journaux de transactions. Le nombre et la
complexité des transactions dépendent du type
d'activité effectuée par les utilisateurs. Testez
votre système pour avoir une idée des performances
que vous pouvez en tirer. Rejouer des transactions peut
prendre de 1 à 2 minutes par fichier-journal et sur de
gros serveurs (plus de 1 000 utilisateurs) des centaines
de fichiers-journaux peuvent avoir été
générés pendant une journée. Plusieurs
heures peuvent donc être nécessaires pour rejouer
une journée de transactions.
Vous avez peut-être entendu parler "d'alternatives"
à la restauration, comme le fait d'exécuter des
utilitaires de réparation des bases de données. Ils
s'avèrent souvent plus lents et ne peuvent garantir une
restauration pleine de succès. Pour maintenir
l'intégrité des bases de données Exchange,
utilisez systématiquement la vérification des
sauvegardes et des restaurations.
Disque système
Si le disque système est complètement corrompu et
doit être reconstruit après une panne, mais que le
disque des journaux de transactions et la partition des bases
de données sont intacts, vous devez restaurer le disque
système de telle sorte qu'il puisse repartir de là
où il s'était arrêté pour que les services
Exchange puissent redémarrer.
Cette section traite des problèmes spécifiques
à Exchange Server, et n'est pas une discussion exhaustive
relative aux techniques de récupération de
Windows NT.
Il existe plusieurs approches. La méthode
traditionnelle consiste à reconstruire le disque
système en réinstallant et en reconfigurant
Windows NT, en réinstallant Exchange, etc. Si vous
migrez vers un matériel nouveau, il s'agira peut-être
de l'unique solution qui fonctionnera à cause du nom du
serveur, des ID utilisateurs de Windows NT, etc. Au fond,
il suffit de réinstaller un serveur avec les mêmes
noms d'organisation et de site, mais en sélectionnant
Créer un nouveau site. Ainsi, Exchange sera prêt pour
la "jonction" avec les bases de données existantes ou
issues d'une sauvegarde, sans interaction prématurée
avec les serveurs existants dans le site. Conservez ces deux
idées présentes à l'esprit à tout
moment :
N'utilisez pas l'option install /r. Avant de vous
reconnecter aux bases de données existantes, vous devez
appliquer, au serveur remplaçant, tous les Services Pack
et correctifs logiciels précédemment
installés. Vous ne pouvez pas le faire en utilisant
install /r.
Ne supprimez jamais le serveur ayant échoué du
site Exchange. Cela rend impossible pour le "même"
serveur (c'est-à-dire le nouveau serveur exécutant
les anciennes bases de données) la jonction, vous
forçant par là-même à devoir
réinstaller Exchange en tant que nouveau serveur puis
à suivre une procédure (longue) pour
récupérer les boîtes aux lettres
utilisateurs.
Une technique plus rapide (et généralement plus
sûre) consiste à restaurer le disque système
à partir d'une sauvegarde récente. Voici un exemple
de cette approche :
Installez Windows NT et le logiciel de sauvegarde,
ce qui vous permet de faire un peu plus que de lire les
bandes.
En utilisant cette installation, effectuez une
restauration complète de la partition système
à partir de la plus récente des sauvegardes.
Réinitialisez un ou deux éléments sur la
nouvelle image système.
Redémarrez, ce qui démarrera automatiquement
les services Exchange. Vous pouvez effectuer ces
opérations seulement si votre logiciel a sauvegardé
le registre Windows NT avec le disque système.
Avant de démarrer sur l'image restaurée, vous devez
effectuer une opération de nettoyage :
Si vous avez les espaces de travail des bases de
données sur le disque système, vous devez supprimer
les fichiers de point de contrôle de la banque
d'informations et de l'annuaire (c:\exchsrvr\dsadata\edb.chk
et c:\exchsrvr\mdbdata\edb.chk) avant de démarrer les
services. Vous éviterez ainsi qu'Exchange ne rejoue les
mauvaises transactions pour l'annuaire et la banque
d'informations, ce qui engendrerait une corruption des bases
de données.
Réinitialisez les fichiers de la base de
données du MTA s'ils se trouvent sur le disque
système. Bien que vous puissiez normalement vous passer
de cette étape, vous devriez le faire pour éviter
que le MTA ne reprenne en compte des données sur
lesquelles il travaillait au moment où le serveur a
été sauvegardé. Tout message dans la base de
données, à ce moment-là, a dû
déjà être envoyé et une
réinitialisation permet d'éviter une confusion
(pour le MTA et les utilisateurs).
Disque des journaux de transactions
Si le disque des journaux de transactions est
complètement détruit ou corrompu, les journaux de
transactions courants sont perdus. Si cela se produit, Exchange
n'est probablement plus en état de fonctionner.
Ces fichiers-journaux ont été créés
depuis la dernière sauvegarde, il n'en existe donc pas une
sauvegarde et il n'y a aucun moyen de les restaurer. Ceci peut
être ou non un problème, tout dépend de
l'état des bases de données. Si les bases de
données des banques n'ont pas été corrompues par
le même événement qui a détruit le disque
des journaux, vous pouvez "réparer" le disque des journaux
de transactions et redémarrer la banque. Vous
initialiserez ainsi un nouveau jeu de fichiers-journaux et
aucune donnée ne devrait être perdue, bien que
jusqu'à ce que vous réalisiez une nouvelle sauvegarde
en ligne vous ne pourrez ni effectuer de restauration, ni
rejouer les transactions (si vous restaurez la plus
récente des sauvegardes, il y aura un intervalle au
début de la séquence des fichiers-journaux, ce qui
empêchera de rejouer les transactions).
La procédure pour "réparer" la partition des
journaux de transactions est simple : installez un nouveau
disque, affectez-lui la même lettre de lecteur,
formatez-le et créez les répertoires dsadata et
mdbdata.
Si, pour une raison quelconque, vous ne souhaitez pas
réparer le disque maintenant, vous pouvez utiliser
l'assistant Performance d'Exchange pour faire pointer
temporairement les services Exchange vers un autre emplacement
de création des fichiers-journaux. En général,
il est préférable de réparer le disque
immédiatement, pour éviter de devoir arrêter le
serveur plus tard.
Base de données Exchange
Si une panne matérielle survient, vous aurez à
restaurer la banque d'informations à partir d'une
sauvegarde en ligne vers un serveur Exchange qui se trouve en
activité. La procédure qui suit considère que
l'espace de travail de la base de données existe sur le
disque système.
Les parties suivantes du système sont
impliquées :
Le disque système : c:\exchsrvr\mdbdata\ :
"l'espace de travail" de la banque. Ce répertoire
contient le fichier de point de contrôle EDB.CHK, qui
est très important car il comprend un pointeur indiquant
quel est le journal de transactions à partir duquel il
faudra rejouer les transactions, et également TEMP.EDB,
fichier peu important contenant des informations temporaires
utilisées par la banque lors d'une exécution
normale. TEMP.EDB n'est pas sauvegardé et est
supprimé quand le service banque d'informations est
arrêté proprement.
Le disque des journaux de transactions : lettre de
lecteur:\exchsrvr\ mdbdata\ qui contient les
fichiers-journaux. EDB.CHK inclut un pointeur vers le
fichier-journal contenant la dernière transaction
transférée vers la ou les bases de données.
Remarquez que celui-ci peut ne pas être le
fichier-journal courant (ouvert) (qui est toujours EDB.LOG)
car le service de la banque s'exécute habituellement en
tâche de fond pour transférer les
éléments vers le disque. Le disque des journaux de
transactions doit contenir une séquence continue de
fichiers-journaux démarrant à partir du fichier
courant et remontant jusqu'au fichier-journal contenant la
dernière transaction transférée au moment
où a été effectuée la dernière
sauvegarde en ligne (comme indiqué alors par
EDB.CHK).
Par exemple (une séquence courte) :
EDB.LOG
EDB0002B.LOG
EDB0002A.LOG } EDB.CHK pointe sur la dernière
transaction dans la banque.
EDB00029.LOG
EDB00028.LOG
EDB00027.LOG
EDB00026.LOG } C'était EDB.LOG lors de la dernière
sauvegarde.
EDB00025.LOG
EDB00024.LOG } EDB.CHK pointe sur la dernière
transaction dans la banque au moment de la dernière
sauvegarde.
Ce répertoire contient également les fichiers
RES1.LOG et RES2.LOG, qui sont actuellement réservés
et seront utilisés si la banque d'informations
s'arrête proprement au cas où elle viendrait à
manquer d'espace disque.
Restauration en utilisant un logiciel de sauvegarde tierce
partie comme ARCserve ou BackupExec
L'opération de restauration est simple.
Sélectionnez la base de données Exchange
appropriée comme source, conservez l'endroit de
destination par défaut à emplacement d'origine et
démarrez le processus de restauration. En
général, vous laisserez les options de restauration
par défaut : ne sélectionnez pas Supprimer
toutes les données existantes ou Démarrer le service
après restauration. La restauration peut prendre un
certain temps (même avec un débit de l'ordre de 20
à 25 Go/heure). Les opérations suivantes auront
lieu :
Aucun changement sur le disque système. Rien n'est
restauré à cet endroit, EDB.CHK reste
inchangé.
Tous les fichiers-journaux de transactions
sauvegardés avec les bases de données sont
restaurés sur le disque des journaux de transactions.
Cela signifie qu'il y a maintenant une séquence
étendue commençant (par exemple) à partir de
EDB0001E.LOG (tous les fichiers de EDB0001E.LOG à
EDB00025.LOG ont été restaurés à partir
de la bande) :
EDB.LOG
EDB0002B.LOG
EDB0002A.LOG } EDB.CHK pointe sur la dernière
transaction dans la banque.
EDB00029.LOG
EDB00028.LOG
EDB00027.LOG
EDB00026.LOG } C'était EDB.LOG lors de la dernière
sauvegarde.
EDB00025.LOG
EDB00024.LOG } EDB.CHK pointe sur la dernière
transaction dans la banque au moment de la dernière
sauvegarde.
EDB00023.LOG
EDB00022.LOG
EDB00021.LOG
EDB00020.LOG
EDB0001F.LOG
EDB0001E.LOG
Par ailleurs, deux fichiers PRIV.PAT et PUB.PAT sont
restaurés. Ils contiennent les pages modifiées
écrites vers des parties de la base de données
ayant déjà été sauvegardées par le
logiciel de sauvegarde (ceci lors du processus de
sauvegarde).
Finalement, l'une ou l'autre des bases de données
(PRIV.EDB ou PUB.EDB) ou les deux à la fois ont
été restaurées vers la partition des bases de
données.
Assurez-vous enfin, en consultant le journal de
restauration, que tout a bien fonctionné, et
redémarrez le service banque d'informations pour rejouer
les fichiers-journaux de transactions (une sélection sera
faite grâce à EDB.CHK et seules les transactions
à partir du journal EDB00024.LOG seront
rejouées).
Complications potentielles
Perte de EDB.CHK
Par exemple, si le disque système a été
également reconstruit, il est fort probable que vous
n'ayez plus de fichier EDB.CHK ou que celui-ci soit incorrect
(c'est-à-dire que la copie du fichier n'est pas en
relation avec la sauvegarde en ligne que vous restaurez). Un
fichier EDB.CHK incorrect s'avère être pire qu'aucun
fichier EDB.CHK car il fournit des pointeurs incorrects au
processus de récupération. Si vous doutez du statut
du fichier EDB.CHK, supprimez-le.
S'il n'y a plus de fichier EDB.CHK, la
récupération logicielle débutera avec le plus
ancien fichier-journal trouvé. Le processus de
récupération vérifie chaque entrée des
journaux avant de ne rejouer que celles ne se trouvant pas dans
la base de données (afin de ne rejouer que les "non
transférées"). En d'autres mots, la
récupération fonctionne quand même, elle est
juste un peu plus lente.
Un trou dans la séquence des fichiers-journaux
La récupération rejoue les fichiers-journaux
seulement jusqu'à ce qu'elle rencontre un trou dans la
séquence. N'essayez jamais de duper le système en
tentant de "masquer" le trou. Bien que des procédures pour
le faire ont été définies dans des groupes de
discussions, elles aboutiraient à de sérieuses
corruptions de données.
Dans certains cas, vous pouvez rencontrer un trou en
début de séquence. Cette situation est actuellement
très difficile (voire parfois impossible) à
détecter, et si elle se présente, une tentative de
récupération engendrera certainement une corruption
de la base de données. La seule voie possible dans ce cas
est de supprimer tous les fichiers-journaux avant de
redémarrer la banque.
Retour nécessaire vers une sauvegarde plus
ancienne
Si la nouvelle base de données restaurée est
corrompue, vous aurez sûrement besoin d'une sauvegarde
plus ancienne. À chaque fois que vous retournerez vers la
sauvegarde précédente, vous pourrez encore rejouer
les journaux de transactions (car, avec chaque restauration,
votre logiciel de sauvegarde restaure tous les
fichiers-journaux supprimés pendant l'opération de
sauvegarde, offrant ainsi une séquence complète).
Pour que les fichiers-journaux soient rejoués, vous devez
supprimer EDB.CHK avant de démarrer le service de la
banque d'informations (vous n'avez droit qu'à une seule
tentative).
Si vous escamotez des sauvegardes (par exemple, retour de
deux ou plus de deux jours en arrière, sautant une ou
plusieurs sauvegardes en ligne), vous obtiendrez un trou dans
la séquence des fichiers-journaux et ne pourrez rejouer
les transactions postérieures à ce trou.
Restauration totale d'un serveur
Une reconstruction complète qui nécessite de
restaurer les données à partir d'une bande n'est
probable qu'après un désastre majeur ayant
détruit le serveur d'origine. Si le serveur est
reconstruit sur place (par exemple, suite à une panne de
la carte mère), vous pourrez sûrement transférer
tous les disques de l'ancien serveur sur le nouveau sans
utiliser de bandes de sauvegarde.
Si vous reconstruisez en utilisant du matériel
identique à 100 % à l'ancien, la restauration
pourra être effectuée comme décrite auparavant.
Mais si vous reconstruisez l'ensemble sur du nouveau
matériel à un nouvel emplacement, il y aura
sûrement des différences et l'image système de
l'ancien serveur ne fonctionnera pas si elle est restaurée
directement sur le nouveau matériel. Ce qui suit est une
procédure générale qui a été
testée dans des cas de figure différents. Vous pouvez
également suivre cette technique si la procédure
décrite auparavant, pour reconstruire le disque
système, ne fonctionne pas (dû, par exemple, à
un changement dans la sous-structure matérielle ou bien
pour toute autre raison).
Voici les étapes élémentaires (cette
procédure est décrite avec de plus amples
détails au Chapitre 9) :
1. Supprimez le serveur en panne du domaine
Windows NT.
2. Installez Windows NT sur le nouveau matériel,
en utilisant le même nom de serveur que celui du serveur
qui est en panne et rejoignez le domaine en tant que "nouveau"
CSD ou serveur membre.
3. Installez les Services Packs Windows NT ou tout
autre correctif logiciel.
4. Installez tout éventuel logiciel de sauvegarde
tierce partie.
5. Installez Exchange, en créant une nouvelle
organisation et un nouveau site portant les mêmes noms que
ceux du site existant. S'il n'y avait pas de Service Pack ou de
correctif logiciel sur l'ancien serveur, vous pouvez utiliserez
l'option install /r. S'il y avait un Service Pack ou un
correctif logiciel, exécutez une installation "normale" et
n'utilisez pas install /r.
6. Appliquez tout Service Pack Exchange ou tout autre
correctif logiciel.
7. Arrêtez tous les services sauf le Surveillant du
système.
8. Supprimez tous les fichiers de contrôle et tous les
fichiers-journaux de transactions.
9. Restaurez les bases de données Exchange (annuaire,
plus les deux bases de la banque d'informations) à partir
d'une sauvegarde.
10. Démarrez les services Exchange et vérifiez
qu'ils fonctionnent normalement.
11. Installez tout logiciel complémentaire.
Remarque En aucun cas vous ne devez supprimer le serveur du
site Exchange existant : cela engendrerait de sérieux
problèmes lorsque le serveur de remplacement
démarrerait.
Procédures tierces parties
Un certain nombre de produits tierces parties incluent des
modules de "récupération après désastre"
pour Windows NT. Ils créent une ou deux disquettes
à rajouter au jeu de disquettes d'amorçage de
Windows NT, afin que vous puissiez restaurer un disque
système ou un serveur entier en amorçant simplement
le système sur ces disquettes et en choisissant l'option
de récupération.
Soyez attentif. Il est peu probable que vous trouviez un
produit qui synchronise la sauvegarde de récupération
du désastre avec une sauvegarde en ligne Exchange. Par
conséquent, vous ne serez pas à même de pouvoir
restaurer un serveur Exchange complet en utilisant ce type de
produit. Si vous décidez d'utiliser ces outils de
sauvegarde pour récupérer un disque système
(seulement), vous devez au choix :
vous assurer qu'aucun espace de travail de bases de
données ou tout autre donnée dynamique d'Exchange
ne se trouve sur le disque système ;
configurer les services Exchange pour un démarrage
manuel avant de prendre la sauvegarde qui sera utilisée
avec le produit de récupération en cas de
désastre.
Le danger consiste à démarrer automatiquement
Exchange et à lui fournir des données "fausses", ce
qui peut arrêter le processus de récupération
logicielle et corrompre la base de données.
Dernière
mise à jour le jeudi 6 janvier 2000
Pour en savoir plus