Sur cette page
Récupération après incident grave Microsoft
Exchange Server : première partie
VUE D'ENSEMBLE
Introduction
Remarques d'ordre général
Que sauvegarder ?
Étude des types de sauvegarde
Fichiers journaux et enregistrement circulaire
Plus d'informations sur l'architecture de base de
données
Récupération après incident grave Microsoft
Exchange Server : première partie
Version de document : 4.00 (Mis à jour pour
Microsoft Exchange Server version 5.5)
Par Kali Buhariwalla, Microsoft Product Support
Services (PSS)
Joseph Pagano, Microsoft Consulting Services (MCS), New
Jersey
VUE D'ENSEMBLE
Point clé : la formulation, le test, la
certification et le déploiement d'un plan de
récupération après incident grave est une partie
essentielle de la gestion d'un système de messagerie.
Détail :
élevé Tâche :
planification, support
Section de
l'article
Contenu
Introduction
Importance de la
formulation d'un plan avant que celui-ci soit
nécessaire.
Remarques d'ordre
général
Discussion des points
généraux relatifs à Exchange et aux
données devant être
sauvegardées.
Étude des types
de sauvegarde
Comparaison des
méthodes de sauvegarde en ligne et hors
connexion.
Fichiers journaux et
enregistrement circulaire
Présentation de
l'enregistrement et des types de fichiers
journaux.
Sauvegarde d'un
serveur gestionnaire de clés
Recommandations sur la
sauvegarde des données du serveur gestionnaire
de clés.
Informations
supplémentaires sur l'architecture des bases de
données
Présentation des
transactions, du stockage d'instances uniques et de
la sauvegarde sur bande.
Scénarios de
récupération de données
Description
détaillée de scénarios de
récupération : élément
unique, serveur complet, fichiers .PST, .OST et
.PAB.
Pratiques
générales
Conseils et
recommandations sur la création et la
vérification des sauvegardes quotidiennes, la
création d'un laboratoire de
récupération, la préparation d'un kit
d'incident et autres aspects connexes.
Considérations
relatives à la configuration de Microsoft
Exchange
Stratégies de
gestion des rôles de Microsoft Exchange Server,
de localisation des journaux de transactions, de
désactivation de l'enregistrement circulaire et
autres aspects connexes.
Stratégies de
type de sauvegarde
Examen des
caractéristiques de divers types de sauvegarde,
y compris leurs avantages, limitations et
inconvénients.
La question
« Hot Spare »
Considérations
relatives à la maintenance d'un serveur
hot
spare
(de destination) en ligne pour la
récupération Exchange.
Exemple d'automatisme
de sauvegarde en ligne
Étapes à suivre
pour effectuer une sauvegarde en ligne et exemples de
fichiers de commandes.
Planificateur WINAT et
service Planificateur de tâches de
Windows NT
Recommandations relatives
à la configuration du service Planificateur de
tâches.
|
Introduction
Microsoft Exchange est une plate-forme de messagerie
d'entreprise robuste et stable, mais il arrive que des
ordinateurs tombent en panne, qu'il y ait des pannes de courant
et autres incidents graves. Vous devez donc disposer d'un plan
de restauration de Microsoft Exchange qui minimise la perte de
données et le temps d'immobilisation. Il est important de
créer un plan et de pouvoir y accéder rapidement et
simplement. Lorsque vous vous retrouvez dans une situation
d'incident grave, il n'est plus temps de formuler un plan mais
d'exécuter des procédures et des techniques
testées et éprouvées.
Cet article est un supplément à la documentation
en ligne et sur papier qui existe déjà. C'est un
guide qui vous permettra de formuler, de tester, de certifier
et de déployer vos propres plans de récupération
après incidents graves. Il ne traite pas d'utilitaires de
sauvegarde tiers.
Remarques d'ordre général
Microsoft Exchange est une application professionnelle
critique, qui peut gérer plus d'utilisateurs par serveur
et un ensemble de données plus important que les
précédents systèmes de messagerie à
fichiers partagés. Lorsque les configurations Exchange
prennent de l'importance, chaque serveur devient essentiel pour
l'entreprise, et les utilisateurs exigent alors une
disponibilité du système 24 heures sur 24, 7 jours
sur 7. Malgré cela, de nombreuses entreprises mettent en
œuvre des fonctions de maintenance ou de
récupération après incidents graves qui sont
inadéquates.
Exchange utilise la sécurité Windows NT pour
l'authentification, tout plan de sauvegarde Exchange doit donc
incorporer des fonctions de restauration et de sauvegarde
Windows NT. Le programme NTBACKUP.EXE de Windows NT
fournit des services de sauvegarde fichiers et effectue une
sauvegarde du Registre Windows NT. La version
améliorée de NTBACKUP.EXE incluse dans Exchange
Server 4.0 et les versions ultérieures permet
d'effectuer des sauvegardes de l'annuaire et de la banque
d'informations Exchange en temps réel, sans interrompre le
système de messagerie.
Exchange Server a été conçu de telle
manière que les sauvegardes puissent être
effectuées en ligne. En pratique, lorsque vous laissez un
serveur en ligne, vous réduisez le trafic système car
vous n'avez pas besoin de procéder à une nouvelle
authentification, qui aurait été nécessaire si
vous aviez dû reconnecter le serveur. La banque
d'informations, l'annuaire, le MTA et le surveillant
système restent en service durant la sauvegarde en ligne.
Vous pouvez automatiser ce processus et le planifier par
l'intermédiaire du planificateur à interface
graphique WINAT.EXE (voir le
Kit de Ressources Microsoft
Windows NT 4.0
). La section intitulée
« Exemple de fichier de commandes pour la sauvegarde
en ligne », qui se trouve à la fin de la seconde
partie de cet article, contient des exemples d'un fichier de
commandes qui arrête et redémarre les services
Exchange, que vous pouvez utiliser à d'autres fins.
À noter toutefois que Exchange ne doit pas fonctionner
lorsque vous sauvegardez des fichiers dans des répertoires
auxquels accèdent d'autres services Exchange pour
Windows NT (tels que la synchronisation d'annuaire
- DX - ou l'agent de transfert de messages Microsoft
Mail - PCMTA).
Que sauvegarder ?
Les procédures de sauvegarde doivent capturer deux
types de données :
-
Données utilisateur contenues dans la banque
d'informations (PUB.EDB et PRIV.EDB), les fichiers .PST,
.OST, .PAB et les journaux des transactions
-
Données de configuration contenues dans
l'annuaire Exchange (DIR.EDB), le Registre Windows NT et
divers sous-répertoires du répertoire
d'installation Exchange Server (ainsi que, le cas
échéant, dans des chemins d'accès
créés après l'exécution du programme
Assistant Performance Microsoft Exchange).
Le tableau suivant contient les emplacements par défaut
des fichiers de base de données. À partir de la page
Chemins d'accès à la base de données de
l'objet serveur, vous pouvez reconfigurer tous les chemins
d'accès aux fichiers de base de données durant
l'installation, en sélectionnant un chemin d'accès
différent du chemin d'accès par défaut
mentionné dans le tableau (\exchsrvr). Vous pouvez
également utiliser l'Assistant Performance Microsoft
Exchange pour déplacer les journaux des transactions sur
un disque physique différent de celui de la banque
d'informations et des fichiers de répertoire.
Les données du serveur gestionnaire de clés et le
disque de démarrage du serveur gestionnaire de clés
créé lors de l'installation ne sont pas
automatiquement sauvegardés par le programme de sauvegarde
en ligne. Vous devez effectuer leur sauvegarde manuellement.
Les données du serveur gestionnaire de clés de
Exchange 5.5 se trouvent dans exchsrvr\kmsdata. (Dans
Exchange 4.0 et 5.0, elles se trouvent dans un
répertoire nommé \Security).
Emplacement des fichiers de base
de données Exchange
Composant
Fichier
Chemin d'accès par
défaut
Banque
d'informations
Privé
\exchsrvr\mdbdata\PRIV.EDB
Public
\exchsrvr\mdbdata\PUB.EDB
Annuaire
\exchsrvr\dsadata\DIR.EDB
Journaux de
transactions
Banque
d'informations
\exchsrvr\mdbdata\*.LOG
Annuaire
\exchsrvr\dsadata\*.LOG
Serveur gestionnaire
de clés
Exchange 4.0 et
5.0
C:\security
Exchange 5.5
\exchsrvr\kmsdata
|
En plus de ces données, nous vous conseillons de
sauvegarder régulièrement :
-
Le Registre de Windows NT, informations de
configuration relatives aux services Exchange et à la
base de données du Gestionnaire de comptes de
sécurité (SAM), laquelle contient le compte de
service Exchange ;
-
Les données des sous-répertoires
Exchsrvr
, par exemple, le répertoire TRACKING.LOG
contenant les données de suivi des messages, IMCDATA qui
peut contenir des messages Internet archivés, etc.
Fichiers .PST (banque de messages personnelle)
Assurez-vous que les routines de sauvegarde incluent tous
les fichiers .PST stockés sur les serveurs de fichiers
(répertoires de base). En cas de perte ou de corruption
d'un fichier .PST, il suffit pour le récupérer de
restaurer le fichier .PST de l'ajouter à un profil
utilisateur existant. Pour réparer un fichier .PST
endommagé, il vous suffit d'exécuter le programme
SCANPST. Parfois les utilisateurs stockent leurs fichiers .PST
sur des lecteurs locaux qui ne sont pas régulièrement
sauvegardés ou bien protègent ces fichiers par un mot
de passe qu'ils oublient par la suite. Dans ces deux cas de
figure, les données sont irrécupérables. Veillez
à ce que les utilisateurs en soient conscients.
Fichiers .OST (banque de messages en mode hors
connexion)
Les données .OST sont menacées lorsque des
modifications apportées au fichier .OST local n'ont pas
encore été répliquées vers la banque
basée sur le serveur. Lorsqu'une machine utilisateur se
bloque après exécution de la réplication, il est
possible de créer un nouveau fichier .OST sur l'ordinateur
de remplacement et d'envoyer toutes les données
basées sur le serveur dans le fichier .OST à l'aide
de la synchronisation. Pour réparer un fichier .OST
endommagé, il vous suffit d'exécuter le programme
SCANPST.
Fichiers .PAB (carnet d'adresses personnel)
Les fichiers de carnet d'adresses personnel peuvent
être stockés localement ou dans un répertoire de
serveur. Il est plus sûr de les stocker sur un serveur,
car la plupart des serveurs sont régulièrement
sauvegardés. Les utilisateurs stockant leurs fichiers .PAB
localement doivent les sauvegarder eux-mêmes. La perte
d'un fichier .PAB peut coûter des heures de travail et de
productivité.
Outlook : Archivage et AutoArchivage
Outlook permet d'archiver automatiquement les fichiers .PST.
Vous pouvez incorporer cette fonction dans vos stratégies
de sauvegarde.
Comme les feuilles de papier s'accumulent sur votre bureau,
vous devez de temps à autre faire le ménage :
vous devez trier, ranger celles que vous souhaitez garder mais
que vous n'utilisez pas régulièrement, en
déplacer certaines dans d'autres dossiers et en jeter
d'autres.
Pour faire le ménage dans Outlook, vous devez
transférer manuellement les éléments anciens
dans un fichier de stockage en cliquant sur Archiver
dans le menu Fichier, ou en utilisant la fonction
AutoArchivage, qui vous permet de spécifier une durée
au-delà de laquelle les articles sont supprimés ou
déplacés. Outlook peut archiver n'importe quel
fichier, tel qu'une feuille de calcul Excel ou un document
Word, à condition qu'il soit stocké dans un
dossier de messagerie.
L'AutoArchivage est une procédure en deux étapes.
Dans le menu Outils, cliquez sur Options et
sélectionnez l'onglet AutoArchivage.
Définissez les propriétés d'AutoArchivage
pour chaque dossier, en déterminant les éléments
qui sont capturés (dossiers spécifiques, groupes de
dossiers ou ensemble des dossiers) et le moment de la capture.
À chaque démarrage d'Outlook, l'AutoArchivage
vérifie les propriétés de chaque dossier, et les
archive ou les supprime le cas échéant.
Par défaut, l'AutoArchivage gère certains dossiers
Outlook : le Calendrier (6 mois), les Tâches
(6 mois), le Journal (6 mois), les Éléments
envoyés (2 mois) et les Éléments
supprimés (2 mois). Il ne surveille pas la Boîte
de réception, les Notes et les Contacts.
L'archivage conserve la structure de dossiers existante dans
le nouveau fichier archive. Si vous archivez un sous-dossier,
la procédure recrée le dossier supérieur dans le
fichier archive, mais n'archive aucun élément dans ce
dossier. Elle ne recrée que la structure de la boîte
aux lettres dans la structure du dossier archive. Les dossiers
sont laissés en place après leur archivage, même
s'ils sont vides.
Contrairement à l'archivage, qui déplace
les éléments vers des dossiers personnels,
l'exportation laisse les éléments d'origine
dans leur dossier et les copie sous forme de différents
types de fichiers.
N'oubliez pas d'inclure les données Outlook
archivées dans votre stratégie de sauvegarde.
Étude des types de sauvegarde
En ligne ou hors connexion
Sauvegarde en ligne : nécessite
l'exécution du service en question (banque d'informations
ou service Annuaire). Elle ne perturbe pas la messagerie sur le
serveur Exchange. Vous pouvez inclure le Registre
Windows NT dans la sauvegarde, et pouvez sauvegarder le
service Annuaire même si la banque d'informations n'est
pas en cours d'exécution.
Sauvegarde
hors connexion :
nécessite l'arrêt de tous les services Exchange.
Cette sauvegarde est une sauvegarde de fichiers. Il vous suffit
d'exécuter NTBACKUP pour capturer tous les fichiers des
disques sélectionnés, y compris le Registre
Windows NT.
Types de sauvegarde en ligne
Normale (complète)
Toute la banque d'informations et toutes les bases de
données d'annuaires sont sauvegardées. Les journaux
des transactions sont sauvegardés puis purgés. Ils
fournissent un contexte pour les sauvegardes
incrémentielles et différentielles (voir
ci-dessous).
De copie
Les sauvegardes de copie ne suppriment pas les fichiers
journaux et ne modifient pas le contexte pour les sauvegardes
incrémentielles et différentielles. Elles
enregistrent un instantané des bases de données, sans
déclenchement ou effet sur les autres routines de
sauvegarde. Ce type de sauvegarde est utile lorsque vous
souhaitez reproduire l'état d'un système à des
fins de tests.
Incrémentielle
Cette méthode permet de sauvegarder un sous-ensemble de
la banque d'informations ou de l'annuaire, et de n'écrire
que les modifications apportées depuis la dernière
sauvegarde complète ou incrémentielle (suivant celle
qui est la plus récente). Une sauvegarde
incrémentielle écrit les fichiers .LOG (uniquement)
sur bande, puis les purge du disque, définissant un
contexte pour la prochaine tâche de sauvegarde.
Généralement, une restauration incrémentielle
nécessite la bande contenant la dernière sauvegarde
complète ainsi que les bandes de toutes les sauvegardes
incrémentielles effectuées ensuite jusqu'au moment de
la panne du système. Supposons par exemple que vous
effectuez une sauvegarde complète chaque dimanche soir, et
des sauvegardes incrémentielles chaque jour de la semaine.
Si une panne se produit un vendredi matin, vous devez effectuer
une restauration complète (pour restaurer le système
tel qu'il était le dimanche soir), puis toutes les
restaurations incrémentielles qui suivent, pour restaurer
le système jusqu'au jeudi. Vous ne devez pas
redémarrer les services avant la restauration de la
dernière bande incrémentielle.
La sauvegarde incrémentielle est désactivée
lorsque l'enregistrement circulaire est activé. Pour plus
d'informations, consultez ci-dessous la section Fichiers
journaux et enregistrement circulaire.
Différentielle
Cette méthode permet de sauvegarder les modifications
apportées à la banque d'informations et/ou à
l'annuaire depuis la dernière sauvegarde complète
(normale) ou incrémentielle. Toutefois, la plupart des
administrateurs préfèrent ne pas mélanger
sauvegardes différentielles et incrémentielles dans
une même série. Une sauvegarde différentielle
capture uniquement les fichiers .LOG, mais ne les purge pas du
disque. Lorsqu'une restauration du journal des transactions et
de la base de données est nécessaire, seules deux
bandes sont requises : la dernière sauvegarde
complète, et la sauvegarde différentielle la plus
récente. Si les journaux des transactions sont intacts
depuis la dernière sauvegarde complète, seule la
bande de la dernière sauvegarde complète est requise,
car le processus de restauration reproduit tous les journaux
depuis la sauvegarde complète jusqu'au fichier EDB.LOG
actuel, restaurant ainsi toutes les transactions jusqu'à
ce jour. Ne sélectionnez pas
Supprimer
les données existantes
lorsque vous effectuez ce type
de restauration, car vous effaceriez ainsi les fichiers
journaux à jour.
La sauvegarde différentielle est désactivée
lorsque l'enregistrement circulaire est activé. Pour plus
d'informations, consultez ci-dessous la section Enregistrement
circulaire de la base de données.
Fichiers journaux et enregistrement circulaire
Fichiers journaux : définition
Exchange Server conserve plusieurs fichiers de base de
données (banques) dans une structure transparente pour
l'utilisateur final. La banque d'informations, par exemple, est
constituée de deux bases de données : l'une
privée (PRIV.EDB), l'autre publique (PUB.EDB). Ces deux
bases de données sont gérées par le service
Banque d'informations. L'annuaire Exchange est stocké dans
DIR.EDB. Les services Exchange Server utilisent des fichiers
journaux de transactions pour chacune de ces bases de
données.
La technologie de base de données Exchange met en
œuvre des fichiers journaux pour accepter des
données, effectuer leur suivi et leur gestion. Pour
améliorer les performances et les possibilités de
récupération, toutes les transactions de message sont
d'abord écrites dans les fichiers journaux et dans la
mémoire, puis dans les fichiers de base de données
respectifs. Sur l'ordinateur client, les performances sont
sensiblement renforcées, car l'écriture dans les
fichiers journaux est effectuée de manière
séquentielle (éliminant ainsi le temps de recherche),
et Exchange Server écrit immédiatement les
transactions de message dans les fichiers journaux. Toutefois,
les fichiers journaux sont toujours ajoutés à la fin
du fichier, et l'écriture dans les fichiers de base de
données Exchange (PUB.EDB, PRIV.EDB, et DIR.EDB)
s'effectue de manière aléatoire (faisant du temps de
recherche un facteur de performance).
Les possibilités de récupération sont
renforcées car les fichiers journaux peuvent être
utilisés pour récupérer des données de
transactions de message, en cas d'altération de la banque
d'informations ou des fichiers de base de données de
l'annuaire suite à une panne matérielle, à
condition que les journaux aient été sauvegardés
et soient intacts. Les fichiers journaux sont
généralement conservés sur un disque physique
différent de celui qui contient la banque d'informations
et les fichiers de base de données d'annuaire. Une panne
affectant les fichiers de base de données n'a donc le plus
souvent pas d'impact sur les fichiers journaux. Les
données qui n'ont pas été sauvegardées mais
qui ont été enregistrées dans les journaux des
transactions peuvent être "relues" pour restaurer le
fichier de base de données.
Les services d'annuaire et de banque d'informations
utilisent les journaux des transactions, les journaux
précédents, les fichiers de point de contrôle,
les journaux réservés et les fichiers correctifs.
Journaux des transactions
Les journaux des transactions peuvent être
conservés sur un lecteur physique différent de celui
qui contient leurs fichiers .EDB respectifs. Par défaut,
les journaux de la banque d'informations sont conservés
dans \exchsrvr\mdbdata, et les journaux du service Annuaire
sont conservés dans \exchsrvr\dsadata. Chaque
sous-répertoire contient un fichier EDB.LOG qui est le
fichier journal des transactions actuel pour le service en
question. Le sous-répertoire de la banque d'informations
et le sous-répertoire du service Annuaire gèrent tous
deux un fichier EDB.LOG séparé.
La taille des fichiers journaux doit toujours être
5 Mo, une taille différente signifie probablement que
le fichier est endommagé. Les transactions sont tout
d'abord écrites dans les fichiers EDB.LOG, puis dans la
base de données. La taille de la base de données est
donc une combinaison des transactions non validées du
fichier journal de transactions (qui réside également
en mémoire) et du fichier de base de données .EDB
réel. Chaque fois qu'un fichier EDB.LOG est rempli de
données de transaction, il est renommé et un nouveau
fichier EDB.LOG est créé.
Journaux précédents
Lorsqu'un fichier journal EDB.LOG est renommé, il est
stocké dans le même sous-répertoire que le
nouveau fichier EDB.LOG. Les fichiers journaux sont nommés
de manière séquentielle (à savoir, EDB00014.LOG,
EDB00015.LOG, et ainsi de suite en utilisant la notation
hexadécimale). Les fichiers journaux
précédemment validés sont purgés durant une
sauvegarde normale (complète) en ligne ou durant une
sauvegarde incrémentielle en ligne, à l'aide de
NTBACKUP.EXE. Tous les fichiers journaux précédents
ne sont pas purgés. Chaque fois que 5 Mo de
transactions sont écrits, un nouveau journal est
créé, sans être forcément validé.
À tout moment il peut y avoir plusieurs journaux
précédents non validés. Ceux-ci ne sont alors
pas purgés. Si vous activez l'enregistrement circulaire,
aucun historique des journaux précédents n'est
conservé. Ceux-ci ne sont pas purgés par les
opérations de sauvegarde. D'ailleurs, les sauvegardes
incrémentielles et différentielles ne sont pas
autorisées lorsque l'enregistrement circulaire est
activé.
Les transactions des fichiers journaux sont validées
dans les fichiers .EDB respectifs lorsque le service est
arrêté normalement. Par exemple, lorsque le service
banque d'informations subit un arrêt normal (le service
est interrompu sans erreur), toutes les transactions
présentes dans des fichiers journaux mais pas dans
PRIV.EDB ou PUB.EDB sont validées dans les fichiers .EDB.
Vous ne devez pas purger manuellement les fichiers journaux
lorsque des services sont en cours d'exécution. En
général, il vaut mieux purger les journaux durant le
processus de sauvegarde.
Fichiers de point de contrôle
Les fichiers du point de contrôle sont employés
pour récupérer (reproduire) les données des
journaux des transactions dans les fichiers .EDB. Un point de
contrôle est un marqueur d'emplacement dans le fichier
EDB.CHK, pour indiquer les transactions qui ont été
validées. La banque d'informations et le service Annuaire
gèrent des fichiers EDB.CHK séparés. À
chaque fois que des données sont écrites dans un
fichier .EDB depuis le journal des transactions, le fichier
EDB.CHK est mis à jour avec des informations
spécifiant que la transaction a été validée
avec succès dans le fichier .EDB en question. Durant la
récupération, Exchange détermine les
transactions n'ayant pas encore été validées en
lisant le fichier EDB.CHK ou en lisant directement les fichiers
journaux de transactions (dans ce cas EDB.CHK n'est pas
nécessaire). La banque d'informations et le service
Annuaire lisent leur fichier EDB.CHK durant le démarrage,
et utilisent les journaux des transactions pour lire les
transactions non validées dans les fichiers .EDB.
Exemple : si un serveur Exchange subit une panne et que
des transactions ont été inscrites dans le journal
des transactions mais pas encore dans le fichier de base de
données, Exchange tente d'effectuer la
récupération au démarrage en enregistrant
automatiquement dans les fichiers de base de données les
transactions qui sont contenues dans les journaux.
Journaux réservés
Les services Annuaire et Banque d'informations gèrent
indépendamment deux fichiers de réserve, RES1.LOG et
RES2.LOG dans MDBDATA et DSADATA. Si l'un des deux services
vient à cours d'espace disque lorsqu'il renomme le fichier
EDB.LOG et qu'il en crée un nouveau, il utilise les
fichiers journaux de réserve. Ceci est un dispositif de
sécurité uniquement utilisé en cas d'urgence.
Lorsque ce cas de figure se présente, le moteur de base de
données envoie une erreur au service en question, qui
transfère alors dans le journal RES1.LOG (et le RES2.LOG
si nécessaire) toute transaction en mémoire qui n'a
pas encore été écrite dans un journal des
transactions. Le service s'arrête ensuite, et enregistre
un événement dans le journal des événements
de Windows NT. La taille des fichiers journaux de
transactions RES est toujours 5 Mo, comme pour tous les
autres fichiers journaux de transactions.
Fichiers correctifs
Pendant une sauvegarde Exchange en ligne, l'enregistrement
de transactions pour les fichiers .EDB peut continuer. Si une
transaction a lieu pour une partie du fichier .EDB qui n'a pas
encore été sauvegardée, elle est tout simplement
traitée. Si une transaction a lieu pour une partie du
fichier .EDB qui a déjà été
sauvegardée, elle est consignée dans un fichier .PAT
(fichier correctif, ou patch). Un fichier .PAT
différent est utilisé pour chaque base de
données : PRIV.PAT, PUB.PAT et DIR.PAT. Ces fichiers
ne sont visibles que durant le processus de sauvegarde.
Voici comment les fichiers .PAT prennent place dans le
déroulement de la sauvegarde en ligne :
-
un fichier .PAT est créé pour la base de
données actuelle ;
-
la sauvegarde du fichier .EDB actuel commence ;
-
les transactions qui doivent être écrites dans
des parties déjà sauvegardées du fichier .EDB
sont consignées dans les fichiers .EDB et
.PAT ;
-
le fichier .PAT est écrit sur la bande de
sauvegarde ;
-
le fichier .PAT est supprimé de \MDBDATA ou
\DSADATA.
TEMP.EDB
Ce fichier contient les transactions en cours, et est
utilisé à des fins de stockage transitoire lors du
compactage en ligne.
Comment purger les fichiers journaux
Lorsque l'enregistrement circulaire est désactivé,
les fichiers journaux s'accumulent sur le lecteur du journal
des transactions jusqu'à l'exécution d'une sauvegarde
normale (complète) ou incrémentielle.
Voici comment les purges prennent place dans le
déroulement de la sauvegarde en ligne :
-
le processus de sauvegarde copie les fichiers de base de
données spécifiés ;
-
le cas échéant, des fichiers correctifs sont
créés (pour la prise en charge des transactions qui
ont été écrites durant la sauvegarde dans une
partie déjà traitée du fichier
.EDB) ;
-
les fichiers journaux créés lors du processus
de sauvegarde sont copiés sur bande ;
-
les fichiers correctifs sont écrits sur
bande ;
-
les fichiers journaux qui sont antérieurs au point
de contrôle au début de l'opération de
sauvegarde sont purgés. Ces fichiers ne sont pas
nécessaires car les transactions qu'ils contiennent ont
déjà été validées dans les fichiers
.EDB, et les fichiers .EDB ont été écrits sur
bande.
Enregistrement circulaire de la base de données
L'enregistrement circulaire (activé par défaut)
utilise la technologie de journal de transactions mais ne
gère pas de fichiers journaux de transactions
précédents. Au lieu de cela, il gère une
fenêtre de quelques fichiers journaux, lorsque les
transactions contenues dans les fichiers journaux de
transactions sont validées dans la base de données,
il supprime les fichiers journaux existants et annule les
précédentes transactions. Vous pouvez ainsi mieux
gérer l'espace disque et empêcher les journaux des
transactions de s'accumuler, mais vous ne pouvez plus utiliser
la sauvegarde différentielle ou incrémentielle, car
celles-ci nécessitent les fichiers journaux de
transactions passés. Du fait que l'enregistrement
circulaire purge certains fichiers journaux de transactions, il
est possible que vous ne puissiez pas récupérer vos
données jusqu'au point de panne en lisant les fichiers
journaux de transactions les uns après les autres, si l'un
d'entre eux est manquant. C'est pourquoi nous vous conseillons
de désactiver l'enregistrement circulaire sur tous les
serveurs Exchange. Vous pouvez très bien gérer
l'espace disque en effectuant régulièrement des
sauvegardes en ligne, qui purgent les fichiers journaux du
disque dur une fois qu'ils sont sauvegardés.
Si l'enregistrement circulaire est activé, vous
trouverez probablement de nombreux fichiers EDBXXXXX.LOG dans
le sous-répertoire \MDBDATA ou \DSADATA. Ceci est normal,
car Exchange utilise plusieurs fichiers journaux pour
définir sa fenêtre de permutation circulaire. Par
exemple, les journaux EDB00010.LOG, EDB00011.LOG, EDB00012.LOG,
et EDB00013.LOG deviendront EDB00011.LOG, EDB00012.LOG,
EDB00013.LOG, et EDB00014.LOG. Ces nombres observent la
notation hexadécimale.
Exchange tente de gérer une fenêtre de quatre
fichiers journaux pour l'enregistrement circulaire, mais en
utilise davantage si la charge d'E/S du serveur est importante.
Les fichiers journaux créés au-delà des quatre
fichiers d'origine ne sont pas purgés tant que leurs
services respectifs (banque d'informations ou service Annuaire)
sont arrêtés puis redémarrés.
Comment déterminer si l'enregistrement circulaire est
activé
Pour visualiser les paramètres d'enregistrement
circulaire :
-
exécutez le programme Administrateur Microsoft
Exchange Server ;
-
cliquez sur Site, Configuration, sur
l'objet Serveurs, puis sélectionnez le serveur
souhaité ;
-
cliquez sur Fichier,
Propriétés ;
-
cliquez sur l'onglet Fonctions avancées.
À noter que vous pouvez activer l'enregistrement
circulaire séparément pour la banque d'informations
et pour l'annuaire.
Vous pouvez modifier les paramètres d'enregistrement
circulaire « à la volée » à
partir du programme Administrateur Microsoft Exchange, mais
dans ce cas Exchange interrompt le service en question et le
redémarre.
Exemple de récupération : journaux des
transactions
Conditions : l'enregistrement circulaire est
désactivé et les journaux des transactions ne sont
pas stockés sur le même disque que les fichiers de
base de données. La dernière sauvegarde complète
(normale) a eu lieu il y a deux jours. Une panne
matérielle (disque dur défectueux) a endommagé
les bases de données de la banque d'informations mais n'a
pas affecté le lecteur du journal des transactions.
Question : une restauration complète
est-elle possible, ou deux jours de données de production
seront-ils perdus ?
Réponse : toutes les données peuvent
être restaurées. Les journaux des transactions sont
complets, ils contiennent donc toutes les transactions
effectuées depuis la sauvegarde complète. Le
matériel de restauration exécute une restauration
complète. Ne supprimez pas les fichiers journaux existants
(c'est-à-dire ne sélectionnez pasSupprimer toutes les données existantes). La
restauration complète écrit dans les fichiers de base
de données et les fichiers journaux qui ont été
sauvegardés lors de la sauvegarde complète. Les
fichiers journaux restaurés vont jusqu'au premier fichier
journal contenu sur le lecteur courant des journaux de
transactions. Exemple : la sauvegarde complète a
copié les fichiers EDB00012.LOG à EDB00014.LOG. Le
lecteur des journaux de transactions contient les fichiers
EDB00015.LOG et suivants. La restauration complète recopie
les journaux EDB00012.LOG à EDB00014.LOG et les fichiers
de base de données de la banque d'informations qui font
partie du jeu de sauvegarde. Une fois que la banque
d'informations a démarré, elle réexécute
les transactions de EDB00012.LOG jusqu'au dernier fichier
journal (EDB00019.LOG) puis réexécute EDB.LOG, le
fichier journal le plus récent. Le service commence
ensuite, et la base de données est à jour. Les
fichiers journaux contiennent des signatures garantissant
qu'ils font bien partie de la séquence à
exécuter.
Sauvegarde d'un serveur gestionnaire de clés
Nous vous conseillons de sauvegarder les fichiers de
données du gestionnaire de clés (C:\SECURITY\MGRENT
dans les versions 4.0 et 5.0, et \EXCHSRVR\KMSDATA dans la
version 5.5) séparément des autres données, et
de conserver ces bandes de sauvegarde encore plus en
sécurité que les sauvegardes quotidiennes. Toutes les
clés contenues dans ces fichiers sont cryptées CAST
64 bits, et sont donc très sûres. Cependant, il
est nécessaire de faire très attention lors de leur
manipulation car ces fichiers contiennent
les clés de
cryptage privées de chaque utilisateur
et ne sont
pas sauvegardés par le programme NTBACKUP.
Le problème avec les cartouches de bande, c'est
qu'elles sont hors connexion : toute personne
mettant la main sur l'une d'entre elles peut restaurer les
fichiers sur un serveur, puis tenter de percer la clé de
cryptage sans avoir à craindre d'être
détecté suite à une connexion ou autre action en
ligne.
Pour la plupart des pirates informatiques, il est
technologiquement impossible de percer une clé sur
64 bits. On estime actuellement qu'il faudrait plus de 12
ans et $300 000 de matériel cryptographique
dédié, et beaucoup plus avec la technologie PC. (Voir
Business Software Alliance .gif)
.gif)
pour une discussion sur les longueurs de
clé, les estimations des durées de décryptage et
autres aspects connexes.) Malheureusement, la technologie
évolue de jour en jour et il existe des personnes
intelligentes et sans scrupules qui disposent de ressources
importantes. Il importe donc de traiter les bases de
données du gestionnaire de clés comme l'un des actifs
les plus sécurisés de votre système
informatique.
Sauvegarde des données du
serveur gestionnaire de clés
-
Arrêtez le service du serveur gestionnaire de
clés.
Sauvegardez les données :
dans Exchange 4.0 et 5.0, sauvegardez le
répertoire SECURITY\MGRENT ;
dans Exchange 5.5, sauvegardez le répertoire
EXCHSRVR\KMSDATA ;
-
sauvegardez le disque de démarrage du serveur
gestionnaire de clés ;
-
démarrez le service du serveur gestionnaire de
clés.
Utilisez régulièrement l'utilitaire
Windows NT Backup pour sauvegarder les fichiers et
sous-répertoire de sécurité avancée. Les
utilisateurs dont les fichiers de sécurité sont
altérés ou qui oublient leur mot de passe ne peuvent
ouvrir aucun message crypté, y compris les messages
archivés. L'administrateur peut récupérer la
clé (la procédure à suivre est décrite dans
la documentation de Microsoft Exchange Server, dans la section
« récupération des clés de
sécurité avancée »), mais uniquement
si les données de sécurité avancée sont
actuelles.
Plus d'informations sur l'architecture de base de
données
Banque de données fiable avec journaux des
transactions
Empruntant un principe mis en œuvre par les bases de
données relationnelles telles que Microsoft SQL Server, la
banque d'informations et le service Annuaire de Microsoft
Exchange Server utilisent des fichiers journaux différents
pour une amélioration des performances et de
l'intégrité des données. Toutes les
modifications sont rapidement enregistrées dans des
journaux de transactions séquentiels, puis validées
dans le fichier de base de données sous-jacent. En cas de
coupure de courant ou d'arrêt inattendu du serveur, les
données demeurent intactes et récupérables
jusqu'à la dernière transaction complète. Une
telle architecture empêche que les données ne soient
altérées ou incohérentes.
Les principes sous-jacents à l'intégrité des
transactions de bases de données sont bien compris depuis
les années 1970. C'est à cette époque que le
test d'intégrité des transactions de bases de
données ACID (atomicité, cohérence, isolement et
durabilité) a été développé. La base
de données sous-jacente à la banque d'informations
prend en charge toutes les propriétés ci-dessous.
-
Atomicité : les résultats d'une
transaction sont tous validés ou tous annulés. Dans
Exchange Server, les opérations atomiques sont
réalisées au moyen de journaux des transactions.
Comme décrit ci-dessus, les transactions du journal qui
n'ont pas encore été validées dans le fichier
de base de données principal sont soit validées,
soit annulées si incomplètes. Ce processus a lieu
rapidement et automatiquement lors du redémarrage du
système.
-
Cohérence : une ressource partagée
(telle qu'une base de données) est toujours
transformée d'un état valide en un autre. Toutes
les opérations effectuées sur la banque
d'informations de Microsoft Exchange Server sont atomiques,
garantissant ainsi la cohérence constante des
données. La mise à jour d'un journal des
transactions pour indiquer qu'une transaction a été
entièrement validée au sein du fichier de base de
données principal constitue une opération
atomique.
-
Isolement : les transactions peuvent
être sérialisées. Dans un système qui
gère plusieurs transactions simultanément, chaque
transaction produit le même résultat que si elle
était la seule exécutée par le système.
Ceci permet à plusieurs utilisateurs d'accéder aux
données de manière sécurisée et
simultanée. Les opérations simultanées
d'utilisateurs ne peuvent pas interférer de manière
à rendre la base de données non valide. La
propriété d'isolement est mise en œuvre par la
base de données sous-jacente à la banque
d'informations de Microsoft Exchange Server.
-
Durabilité : les résultats des
transactions sont permanents et survivent aux pannes
ultérieures du système ou des supports. En cas
d'altération ou d'illisibilité d'une partie d'un
fichier journal des transactions de Microsoft Exchange Server
(par exemple à cause d'un disque physique
endommagé), ces transactions sont simplement
restaurées. Le format physique des journaux des
transactions est soigneusement conçu de façon
à réduire l'impact, même lorsque le support de
stockage est endommagé. Ceci est réalisé
grâce à une combinaison d'écritures
séquentielles, grâce à la création de
nouveaux fichiers journaux tous les 5 Mo et à des
techniques de bas niveau telles que l'enregistrement
ping-pong, qui permettent d'optimiser la durabilité des
transactions, même dans un fichier journal partiellement
altéré.
Même si la charge et le temps système induits par
les journaux des transactions peuvent sembler importants, car
les données sont d'abord écrites dans les journaux,
puis dans le fichier de base de données principal, un bon
fichier journal améliore en fait le rendement du
système pour différentes raisons. Lorsque les
fichiers journaux de transactions sont conservés sur un
disque séparé, ils sont écrits de manière
séquentielle plutôt qu'aléatoire.
La tête du disque n'ayant pas à se positionner de
manière aléatoire, ceci est plus rapide que pour un
accès aléatoire en écriture dans le fichier de
base de données principal, même avec les
sous-systèmes très rapides de lecteur qui existent
aujourd'hui. Les transactions consignées dans le journal
sont ensuite validées et réintégrées
"tranquillement" dans le fichier de base de données
principal. Cette opération peut se dérouler très
efficacement, car de manière asynchrone (lors des cycles
d'inactivité du serveur), et parce que les systèmes
de mémoire cache disque NTFS et FAT de Windows NT
Server commandent automatiquement l'écriture pour qu'elle
soit le plus efficace possible, par l'emploi de techniques
classiques pour minimiser les déplacements effectués
par la tête physique. Les techniques de
récupération de Microsoft Exchange Server sont aussi
performantes pour les gros enregistrements que pour les petits,
car ses journaux des transactions n'écrivent que les
parties modifiées des données.
Récupération automatique rapide grâce à
la restauration des transactions
Lors du démarrage du service Annuaire ou de la banque
d'informations Exchange Server à la suite d'un arrêt
anormal du serveur, le fichier journal des transactions est
examiné pour voir s'il contient des transactions
incomplètes. Si c'est le cas, ces transactions sont
restaurées automatiquement à leur état d'origine
(c'est-à-dire avant l'arrêt). Cette opération de
récupération automatique est relativement rapide car
seules les transactions les plus récentes du journal
doivent être vérifiées.
Ces différences dans les possibilités de
récupération sont comparables à celles entre les
serveurs SGBD de production tels que Microsoft SQL Server ou
Oracle et les bases de données des utilisateurs finaux
telles que Microsoft Access ou Lotus Approach.
Stockage d'instances uniques avec intégrité
référentielle automatique
Le stockage d'instances uniques est une exigence
fondamentale des clients souhaitant stocker le courrier des
utilisateurs de manière centralisée, sur le serveur.
Si 100 utilisateurs sur le même serveur reçoivent le
même message, une seule instance du message est
stockée sur le serveur : des pointeurs vers le
message sont placés dans les boîtes aux lettres des
utilisateurs. Le stockage d'instances uniques peut
économiser de l'espace et améliorer grandement les
performances du serveur.
La banque d'informations de Microsoft Exchange Server
dispose du stockage d'instances uniques
intégré : il est toujours activé et n'exige
aucune configuration ou administration particulière.
Lorsqu'un message ou la boîte aux lettres d'un utilisateur
est supprimé(e), les messages ne peuvent pas être
isolés ou perdus. Les pointeurs ne peuvent pas être
désynchronisés entre les fichiers, car tout est
stocké dans un fichier unique et l'intégrité
référentielle est gérée de manière
interne par le moteur de base de données. Exchange Server
est optimisé pour le stockage efficace et fiable des
messages sur le serveur.
Stockage d'instances uniques avec limites de stockage par
utilisateur.
Des recherches montrent que l'une des causes les plus
courantes de panne de système de messagerie est tout
simplement l'incapacité à limiter la quantité de
stockage par utilisateur, qui finit par provoquer un
"débordement" du serveur, et sa défaillance. Pour
prévenir ce problème, Exchange Server permet aux
administrateurs de définir et de faire respecter des
quotas de disque à tous les niveaux, des utilisateurs
jusqu'au système. Les utilisateurs peuvent recevoir un
avertissement, ainsi qu'une limitation "sévère" qui
les empêche d'envoyer du courrier avant qu'ils n'aient
nettoyé leur boîte aux lettres. Ceci leur évite
de manquer des messages entrants critiques, sans pour autant
pénaliser les autres utilisateurs qui peuvent toujours
leur envoyer des messages.
Sauvegarde en ligne et en direct sur bande, pour une
opération en continu
Exchange Server dispose d'une prise en charge
intégrée des sauvegardes en ligne directement sur
bande. Il n'est pas nécessaire d'arrêter le serveur,
ni que les utilisateurs soient déconnectés. De plus,
la sauvegarde Exchange Server est intégrée à la
sauvegarde Windows NT Server, ce qui vous permet de
sauvegarder ces deux types de serveur du même emplacement.
Vous pouvez effectuer des sauvegardes complètes,
incrémentielles ou différentielles directement sur un
large éventail de périphériques à bande,
depuis les cartouches quart de pouce jusqu'aux systèmes
DAT à haute capacité.
Dernière
mise à jour le jeudi 21 septembre 2000