Microsoft Exchange Server : Notions de base sur la sauvegarde et la restauration

  • Article
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) :

    • avec NTBACKUP : 6 Go/heure ;

    • avec ARCserve ou BackupExec : environ 30 Go/heure.

  • 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.

  • Le disque des bases de données : lettre de lecteur:\exchsrvr\mdbdata qui contient les bases de données des banques, PRIV.EDB et PUB.EDB.

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