Récupération de Microsoft Exchange après un sinistre
Sur cette page
Récupération de Microsoft Exchange après un sinistre : deuxième partie
Version 4.00 du document (mis à jour pour la version 5.5 de Microsoft Exchange Server)
Par Kali Buhariwalla, Services de Support Technique
de Microsoft (PSS)
Joseph Pagano, Services de Consultation Microsoft
(MCS), New Jersey
Vue d'ensemble
Point clé : réponses techniques aux questions courantes sur la récupération après un sinistre et sur la sauvegarde.
Détail : élevé Tâche : planification, support technique
|
Introduction
Le présent article, seconde partie du document Récupération de Microsoft Exchange après un sinistre, propose des réponses aux questions fréquentes que vous pouvez vous poser sur la reprise après un sinistre, la sauvegarde et la planification de ces deux opérations. Vous trouverez une liste similaire dans le Guide de Ressources de Microsoft Exchange Server 5.5.
Utilitaires de base de données Microsoft Exchange Server
Question 1 : quelles améliorations ont été apportées aux utilitaires de base de données livrés avec Exchange 5.5 ?
Réponse : le nouveau ESEUTIL de Exchange Server 5.5 remplace le programme EDBUTIL.EXE fourni avec les précédentes versions. ESEUTIL contient les éléments suivants :
| • | Nouveau vérificateur d'intégrité (ESEUTIL /G) : permet de contrôler l'intégrité d'une base de données à une vitesse qui avoisine les 10 Go/heure. |
| • | Processus de réparation amélioré (ESEUTIL /P) : se déroule à présent en trois étapes : réalise un contrôle d'intégrité pour localiser les pages altérées, recherche les tables dans lesquelles se trouvent ces pages à l'intérieur de la base de données, puis répare uniquement les tables altérées. Les deux premières étapes se déroulent très rapidement, à une vitesse proche de 10 Go/heure. En outre, le fait de ne réparer que les tables altérées permet de gagner du temps et nécessite moins d'espace disque. Selon une estimation prudente, ESEUTIL requiert un espace libre compris entre 20 et 25 pour cent de la taille du fichier de base de données en cours de réparation. Avec EDBUTIL, cette proportion atteint 110 pour cent. |
| • | Processus de défragmentation plus rapide (ESEUTIL /D) : la défragmentation (compression) en mode autonome traite 4 à 5 Go/heure. |
Les vitesses prévues dépendent naturellement du matériel et du chargement. Exchange 5.5 inclut également un vérificateur d'intégrité de la banque d'informations amélioré (ISINTEG.EXE) avec des commutateurs de ligne de commande qui permettent de réaliser des tests individuels, réduisant ainsi le temps nécessaire au contrôle de la banque d'informations. Pour plus d'informations sur ISINTEG, voir le fichier ISINTEG.RTF situé dans le répertoire \SERVER\SUPPORT\UTILS du CD-ROM Exchange Server 5.5.
Question 2 : dans quels cas EDBUTIL/ESEUTIL doit-il être exécuté ? Existe-t-il un article consacré aux problèmes de démarrage de la banque d'informations ?
Réponse : soyez très prudent lorsque vous exécutez EDBUTIL ou ESEUTIL en mode réparation. Avant de réparer une base de données, assurez-vous systématiquement que vous avez sauvegardé vos bases de données et que l'espace disque disponible est suffisant. Nous vous conseillons de contacter le Support Technique Microsoft.
Pour rechercher les derniers articles dans la Librairie
d'Informations Techniques Microsoft, visitez le site du Support Microsoft 
. Lancez
une recherche sur Exchange, puis tapez vos mots-clés.
Question 3 : quelle différence y a-t-il entre l'exécution de la commande isinteg - fix et celle de la commande edbutil /d /r ou eseutil /p ?
Réponse : tout d'abord, la commande edbutil /d /r (Exchange 4.0 et 5.0) ou eseutil /p (Exchange 5.5) ne doit être exécutée qu'en dernier ressort pour réparer un fichier de base de données ; elle ne corrige que les altérations de la base de données de bas niveau (pages incorrectes). La commande isinteg -fix opère, quant à elle, au niveau de la banque d'informations ; elle répare les objets, les modèles et résout les autres problèmes de données/structure de haut niveau. Si, pour une raison quelconque, vous ne disposez pas de sauvegarde à restaurer ou de fichiers journaux à reconstituer et que vous devez exécuter edbutil /d /r ou eseutil /p, veillez à exécuter ensuite isinteg -fix.
Lorsque cela est possible, vous avez intérêt à effectuer la restauration à partir d'une sauvegarde, puis à lire les journaux, dans la mesure où cette méthode restaure l'intégralité de vos données. Si vous n'avez aucune sauvegarde à restaurer et devez exécuter edbutil/eseutiletisinteg, vous perdrez le contenu de toutes les pages incorrectes dans la base de données (messages, pièces jointes, dossiers, etc.).
Question 4 : quand faut-il utiliser edbutil /d /r ou eseutil /p ?
Réponse : il s'agit d'une option de dernier ressort, qui risque de supprimer des données ; utilisez cette commande pour réparer les bases de données uniquement lorsque vous ne pouvez pas effectuer de restauration et qu'aucune autre option n'est disponible.
Avant d'exécuter edbutil /d /r (Exchange 4.0 et 5.0) ou eseutil /p (Exchange 5.5), vérifiez les points suivants :
| • | Vous avez sauvegardé les fichiers de base de données que vous essayez de réparer. |
| • | Vous disposez d'un espace disque suffisant. EDBUTIL nécessite un espace libre équivalent à 110 pour cent (25 pour cent pour ESEUTIL) de la taille du fichier de base de données en cours de réparation. |
| • | Vous utilisez l'option de ligne de commande /t (avec l'un ou l'autre utilitaire) pour désigner le lecteur contenant l'espace disque libre nécessaire. |
| • | Vous exécutez isinteg –fix après l'exécution de l'utilitaire. |
Nous vous conseillons de contacter le Support Technique Microsoft avant de lancer un processus complexe qui peut s'avérer dangereux pour votre système.
Question 5 : j'ai bien compris que je devais exécuter isinteg -patch après la restauration d'une banque d'informations en mode autonome pour corriger les GUID (Globally Unique Identifier), mais qu'est-ce qu'un GUID ?
Réponse : un GUID est une chaîne hexadécimale de 64 bits qui caractérise un objet de manière unique dans le temps et dans l'espace. Les banques d'informations privée et publique possèdent des GUID de base à partir desquels elles génèrent des GUID pour tous les objets qu'elles contiennent, y compris les dossiers, les messages, les pièces jointes, etc. La commande isinteg -patch change les GUID de base de la banque d'informations. Vous devez impérativement exécuter le correctif, car lorsque vous restaurez une banque d'informations, vous remontez en fait dans le temps sur le serveur. De ce fait, si vous ne changez pas les GUID de base, les nouveaux objets créés dans la banque d'informations pourraient avoir des GUID identiques à ceux d'autres objets existants au sein de l'organisation. Cela engendrerait des problèmes lors du référencement des objets, qui ne pourraient plus être identifiés de manière unique.
Si votre organisation possède un seul serveur, vous ne rencontrerez pas ce problème. En effet, lorsque vous effectuez la restauration, vous savez qu'il n'existe pas d'objets sur d'autres serveurs avec des ID qui pourraient être attribués aux nouveaux objets.
Vous n'êtes pas obligé d'exécuter formellement isinteg -patch après la restauration d'une sauvegarde en ligne, car le programme de sauvegarde compatible avec Exchange exécute automatiquement le code requis pour mettre à jour les GUID après la restauration.
Question 6 : pourquoi dois-je exécuter isinteg -patch après la restauration d'une banque d'informations en mode autonome et avant de lancer le service Banque d'informations ?
Réponse : parce que vous devez garantir l'unicité des identificateurs globaux uniques (GUID).
Si vous restaurez une copie de la banque d'informations (PUB.EDB et PRIV.EDB) à partir d'une sauvegarde en mode autonome et n'exécutez pas isinteg -patch, vous obtiendrez l'erreur 1011 lorsque vous essayerez de redémarrer le service. Une entrée sera créée dans le journal d'application de l'Observateur d'événements Windows NT (ID source 2048) avec le message suivant :
Banque d'informations restaurée à partir d'une sauvegarde en mode autonome. Exécutez le patch ISINTEG avant de démarrer la banque d'informations.
Si vous n'exécutez pas isinteg -patch, la banque d'informations restaurée utilise les anciens GUID. Cela ne pose aucun problème s'ils sont uniques, mais ils peuvent provoquer des dégâts s'ils correspondent à des GUID qui sont restés sur le système. La banque d'informations restaurée doit posséder de nouveaux GUID uniques.
Pour corriger la banque d'informations, exécutez isinteg -patch afin de remplacer les GUID. En mode patch, cette commande est exécutée sur l'intégralité de la banque d'informations (PUB.EDB et PRIV.EDB), génère de nouveaux GUID et crée les informations de réplication du correctif qui empêchent les erreurs de “ backfilling".
Pour exécuter isinteg -patch :
1. | Assurez-vous que les services Annuaire et Surveillance du système sont actifs. Si l'un ou l'autre est inactif, l'exécution de la commande isinteg échoue et le message DS_COMMUNICATIONS_ERROR s'affiche. |
2. | Accédez au répertoire EXCHSRVR\BIN et tapez isinteg -patch. La commande remplace les GUID et vous avertit lorsque la banque d'informations a été mise à jour. |
3. | Redémarrez le service Banque d'informations. |
Pour en savoir plus, reportez-vous à l'article Q154032 en anglais de la Librairie d'Informations Techniques Microsoft, Titre : XADM : Error 1105 - EcBadVersion, Restoring Off-Line Store.
Question 7 : lorsque je tente d'exécuter la commande isinteg -patch , l'exécution échoue et j'obtiens le message d'erreur suivant : DS_E_COMMUNICATIONS_PROBLEM. Comment puis-je résoudre ce problème ?
Réponse : veillez à démarrer le service Annuaire avant d'exécuter isinteg -patch.
Question 8 : dois-je exécuter le Vérificateur de cohérence SA/BI après avoir restauré l'annuaire et la banque d'informations ?
Réponse : normalement non. Exécutez-le lorsque vous restaurez uniquement la banque d'informations. Le Vérificateur de cohérence SA/BI analyse la banque d'informations et vérifie que tous les objets qu'il y trouve existent dans l'annuaire. Si un objet n'existe pas dans l'annuaire, il le crée. Il parcourt également l'annuaire pour vérifier que ses objets existent dans la Banque d'informations (s'ils n'y sont pas, ils sont détruits dans l'annuaire). Il vérifie enfin la liste de contrôle d'accès (ACL) de chaque objet et élimine les entrées incorrectes. Un excellent moyen de visualiser le Vérificateur de cohérence SA/BI consiste à régler le niveau d'enregistrement des diagnostics pour la Synchronisation SA/BI sur la valeur maximum (sous les services MSExchange BI Privée et MSExchangeSA Publique) et à examiner le journal de l'application.
Si vous avez restauré la banque d'informations sur un serveur qui a été ajouté récemment à un site Exchange existant, patientez jusqu'à la fin de la réplication. À ce stade, le nouveau serveur devrait connaître tous les serveurs et sites de l'organisation et sa liste d'adresses globale devrait être remplie. Une fois la réplication terminée, exécutez le Vérificateur de cohérence SA/BI. Si vous exécutez le Vérificateur de cohérence SA/BI avant la fin de la réplication, les dossiers publics risquent d'être renvoyés vers ce nouveau serveur et les permissions des dossiers publics seront perdues.
Question 9 : dois-je éviter d'exécuter le Vérificateur de cohérence SA/BI ?.
Réponse : il existe deux situations dans lesquelles vous devez être vigilant lorsque vous exécutez le Vérificateur de cohérence SA/BI.
Lorsque vous avez interrompu temporairement une connexion de réplication d'annuaire entre deux sites, n'exécutez pas le Vérificateur de cohérence SA/BI si vous prévoyez de reconnecter les sites. En effet, si vous exécutez le Vérificateur de cohérence SA/BI dans ces circonstances, tous les dossiers publics hébergés sur des serveurs extérieurs au site courant sont renvoyés vers le serveur local et toutes les boîtes aux lettres appartenant aux autres sites sont supprimées des listes de permissions des dossiers publics. Lorsque vous ajoutez de nouveau le connecteur de réplication d'annuaire, toutes les modifications apportées aux dossiers publics sur le site courant sont répliquées à travers l'organisation, les dossiers publics sont redomiciliés et les permissions sont perdues.
Si vous avez restauré la banque d'informations sur un serveur qui a été ajouté récemment à un site Exchange, n'exécutez pas le Vérificateur de cohérence SA/BI avant que le nouveau serveur n'ait procédé à la réplication avec le restant du site et identifié les autres serveurs et sites de l'organisation.
Pour plus d'informations, reportez-vous aux articles suivants dans la Librairie d'Informations Techniques Microsoft (en anglais) :
| • | Q156705, Titre : XADM : Site Tear Down Causes Public Folders to be Re-homed |
| • | Q141342, Titre : XADM : Public Folders Automatically get New Home Site/Server |
Défragmentation et compression
Question 10 : quelle différence y a-t-il entre la compression, la défragmentation et la maintenance de la banque d'informations ?
Réponse : la maintenance de la banque d'informations a lieu entre 1h00 et 6h00. Elle comprend les tâches suivantes : compression des indicateurs de suppression, datage des colonnes, datage des index, lecture de nettoyage par utilisateur et expiration des messages. Vous pouvez changer les heures de maintenance de la banque d'informations pour éviter les conflits avec le processus de sauvegarde, pour réduire la charge du serveur ou pour d'autres raisons. Pour afficher ce paramètre à partir du programme Administrateur Exchange, mettez en surbrillance le serveur sous Org, Site, Configuration. Cliquez ensuite sur Fichier , puis sur Propriétés dans le menu déroulant et cliquez sur l'onglet Maintenance de BI. Pour en savoir plus, reportez-vous à l'article en anglais Q159196 de la Librairie d'Informations Techniques Microsoft, Titre : XADM : Tasks Controlled by the IS Maintenance Schedule.
La compression consiste à effectuer une défragmentation et à récupérer de l'espace disque en mode autonome. Le processus réorganise les éléments, consolide les données et récupère de l'espace disque. Exécutée avec la commande EDBUTIL /D (ESEUTIL /D dans Exchange 5.5), elle récupère de l'espace et réduit la taille du fichier de base de données, augmentant ainsi l'espace libre sur le disque. La défragmentation consiste à récupérer de l'espace disque et à effectuer une défragmentation de la base de données en mode connecté.
Question 11 : quelles sont les méthodes disponibles pour défragmenter les bases de données de la banque d'informations ?
Réponse : Exchange Server défragmente automatiquement la banque d'informations et les bases de données de l'annuaire sans interrompre la messagerie. La défragmentation en ligne, qui se déroule toujours en arrière-plan, marque les éléments à supprimer et défragmente les fichiers de base de données, sans compresser les fichiers. Vous pouvez également exécuter l'utilitaire EDBUTIL (ESEUTIL dans Exchange 5.5), mais vous devez l'exécuter avec l'option /D (défragmenter), qui nécessite l'arrêt du service Banque d'informations. EDBUTIL /D compresse la banque d'informations et défragmente la base de données.
Question 12 : comment fonctionne la compression/défragmentation en arrière-plan ?
Réponse : lorsqu'un utilisateur supprime un message qui n'a pas d'autres pointeurs, il est marqué pour suppression et un thread d'arrière-plan restitue son espace à la base de données. Par exemple, un message envoyé à cinq utilisateurs est supprimé de la banque d'informations privée (et l'espace est marqué pour récupération) seulement après qu'il a été supprimé par le dernier des cinq destinataires.
Pour en savoir plus, reportez-vous à l'article Q151495 en anglais de la Librairie d'Informations Techniques Microsoft, Titre : Priv.edb not smaller After Running Edbutil /D.
Question 13 : Exchange réalisera-t-il la compression de la banque d'informations à la volée ? Les administrateurs doivent-ils effectuer une compression manuelle régulièrement ?
Réponse : non. Exchange réalise la défragmentation en ligne, mais cette opération diffère de la compression. Aucun compresseur ne fonctionne en permanence, mais une certaine compression est effectuée. L'enregistrement des messages (instance simple), par exemple, s'effectue sous le format .RTF compressé. La compression d'une base de données ne provoque aucune réduction de celle-ci ; si votre PRIV.EDB s'étend au-delà de 1,2 Go et que vous supprimez certains éléments, la taille de PRIV.EDB ne diminue pas, même si de l'espace disque est libéré. Exchange réutilise l'espace avant d'ajouter des données au fichier, et c'est pour cette raison que la défragmentation de la base de données se déroule en arrière-plan sur un serveur actif.
Si vous voulez récupérer physiquement de l'espace disque, vous devez arrêter le serveur pour procéder à la compression en mode autonome. Si vous souhaitez simplement réduire la taille des fichiers de base de données, arrêtez les services et exécutez edbutil (eseutil dans Exchange 5.5) avec l'option /d.
Question 14 : quelle est la durée de la défragmentation d'une base de données avec EDBUTIL/ESEUTIL ?
Réponse : les bases de données sont défragmentées automatiquement en arrière-plan ; à moins que vous ne soyez obligé de réduire la taille des fichiers de base de données, vous n'aurez donc pas à exécuter une compression en mode autonome (défragmentation avec réduction de la taille du fichier).
Par exemple, l'exécution de EDBUTIL sur un IBM 720 à deux processeurs Pentium, RAID5 sur une banque privée de 3,4 Go nécessite environ 150 minutes, soit approximativement 45 minutes/Go. Des calculs approximatifs donnent : 16 Go x 45 minutes/Go = 720 minutes = 12 heures. Les variables du système peuvent changer ces valeurs ; 45 minutes/Go est une vitesse rapide, calculée sur un serveur haut de gamme, et il est préférable de se baser sur des chiffres inférieurs. Vous pouvez cependant tester assez facilement votre équipement et obtenir des chiffres plus fiables.
Le nouvel utilitaire de base de données Exchange 5.5, ESEUTIL, est plus efficace que EDBUTIL et peut normalement défragmenter une base de données à une vitesse de 4 à 6 Go/heure.
La durée de la compression est proportionnelle à la quantité de données dans la base de données. Une base de données de 15 Go peut ne comporter que 2 Go de données si un déplacement ou une suppression en bloc a eu lieu récemment. Pour cette base de données, la durée de la compression est basée sur 2 Go, et non sur 15 Go. Sur certains systèmes Exchange 4.0, on a signalé des durées de compression comprises entre 6 et 10 heures pour 10 à 12 Go. Cela dépend du taux de fragmentation et d'autres facteurs.
Certains systèmes Exchange 5.5, fonctionnant sur des ordinateurs avec un seul processeur Pentium Pro 200-MHz, donnent des vitesses de défragmentation égales à 5 Go/heure.
ESEUTIL et EDBUTIL lisent les pages des fichiers de la base de données de production et les copient dans un fichier temporaire. Si le processus aboutit, le fichier temporaire est renommé et utilisé comme base de données de production. Vous pouvez rediriger ce fichier vers un autre lecteur si de l'espace disque est requis. Pour éviter une copie physique d'un lecteur physique sur un autre à la fin de l'exécution de ESEUTIL/EDBUTIL, redirigez-le vers un lecteur logique sur le même disque physique que les fichiers .EDB.
Question 15 : qu'est-ce que le fichier TEMP.EDB et pourquoi est-il créé ?
Réponse : ce fichier contient les transactions longues en cours et sert parfois pour le stockage temporaire pendant la compression en ligne.
Question 16 : comment puis-je déterminer la quantité d'espace libre dans les bases de données de ma banque d'informations ?
Réponse : avec Microsoft Exchange Server version 5.5, Service Pack 1, pendant la maintenance de la banque d'informations, le service enregistre un événement dans le journal d'événements Windows NT en indiquant la quantité d'espace libre disponible dans les bases de données privée et publique. Cet événement vous permet de déterminer si vous devez effectuer une défragmentation des fichiers de base de données de la banque d'informations (PRIV.EDB et PUB.EDB) en mode autonome pour récupérer l'espace disque libre.
Cet événement est illustré dans l'exemple suivant
ID d'événement : 1221
Source : BI MSExchange Privée
Type : Information
Catégorie : Général
Description :
La base de données possède 95 mégaoctets d'espace libre une fois que la défragmentation en ligne est terminée.
Problèmes relatifs aux fichiers journaux et à l'enregistrement circulaire
Question 17 : quel est le rôle des journaux ?
Réponse : les banques d'informations publique et privée et le service Annuaire sur un serveur Exchange possèdent des journaux où sont consignées toutes les transactions qui interviennent dans la base de données. Ces journaux sont indispensables pour effectuer une reconstitution logicielle (lorsque le service Exchange n'a pas été arrêté correctement et que les fichiers de base de données sont incohérents au démarrage) ou matérielle (blocage du système, panne du disque dur, coupure de l'alimentation, etc.), ainsi que la restauration après une sauvegarde. Le fichier PRIV.EDB du serveur actif est toujours incohérent parce que le cache de la base de données est en mémoire RAM sur le serveur. L'état cohérent du serveur est obtenu à partir des données du fichier .EDB et des données en mémoire cache sur le serveur. Si le serveur tombe en panne et que le cache est vidé, les journaux des transactions relisent automatiquement les transactions qui avaient été saisies, mais pas encore enregistrées dans le fichier .EDB au moment de la panne. Les journaux permettent de restaurer la base de données sans altération.
Un fichier de points de contrôle (EDB.CHK) conserve une trace du point correspondant à la transaction courante (dans les fichiers journaux enregistrés sur le disque). Le processus est relativement simple : l'utilisateur demande une opération sur le serveur (distribuer le courrier, supprimer le courrier, lire le courrier, etc.), les transactions associées à cette opération sont entrées dans les journaux et l'opération est exécutée dans la mémoire cache de la base de données. Plus tard, la transaction est enregistrée sur le disque en arrière-plan et le point de contrôle correspondant au fichier journal est déplacé vers l'avant. La taille réelle de la base de données correspond alors au contenu du fichier .EDB plus les transactions du fichier journal situées après le point de contrôle courant. Lors de l'arrêt du serveur, toutes les données sont enregistrées proprement dans le fichier .EDB et la taille réelle de la base de données est ainsi conservée.
Les fichiers journaux, y compris lorsqu'ils ont été enregistrés sur le disque, demeurent utiles pour les tâches telles que la sauvegarde et la restauration. Supposons, par exemple, que vous avez effectué une sauvegarde hier, que vous n'avez pas cessé de travailler depuis lors et que vous perdez le disque dur de la base de données. Pour une récupération intégrale, vous devez restaurer la sauvegarde de la journée d'hier, puis relire tous les fichiers journaux depuis la sauvegarde.
Les fichiers journaux consomment beaucoup d'espace disque. Effectuez l'une des opérations suivantes pour arrêter la consommation d'espace disque :
| • | Sauvegarde du serveur (en ligne, complète ou incrémentielle) : tous les journaux sont copiés sur la bande jusqu'au point de contrôle, puis tous les originaux sont supprimés du disque dur. Vous pouvez restaurer la base de données intégralement en copiant le fichier de base de données à partir de la bande, en relisant les journaux sur la bande, puis en relisant les journaux sur le disque. |
| • | Enregistrement circulaire : cette option est déconseillée. Elle permet d'économiser de l'espace disque, mais au détriment des possibilités de récupération. L'enregistrement circulaire recycle les fichiers journaux de transactions (quatre fichiers par défaut) : ainsi, vous ne pouvez restaurer qu'une toute petite partie des événements survenus depuis la dernière sauvegarde. La plupart des personnes considèrent cela comme insuffisant. |
Si vous souhaitez ne jamais perdre aucune donnée, choisissez la première option et effectuez de fréquentes sauvegardes. Vous économiserez ainsi de l'espace disque et bénéficierez d'une possibilité de récupération complète.
Dernier point : si vous examinez les répertoires des fichiers .EDB, vous y trouverez également des fichiers *.PAT (corrections). Créés pendant les sauvegardes, ces derniers contiennent toutes les modifications intervenues depuis le début de la sauvegarde. La dernière étape de la sauvegarde consiste à écrire les fichiers de corrections pour obtenir une restauration à l'état le plus récent possible.
Le tableau suivant donne la liste des fichiers contenus dans le répertoire \exchsrvr\mdbdata :
|
Question 18 : à quoi servent les fichiers RES1.LOG et RES2.LOG ?
Réponse : ces fichiers journaux sont réservés pour les transactions qui peuvent être nécessaires à l'arrêt de la banque d'informations, et sont utilisés uniquement lorsque le disque dur qui contient les journaux de transactions est plein. Il s'agit d'une fonction de sécurité : si le disque dur est plein, ces fichiers fournissent suffisamment d'espace pour enregistrer les transactions de la mémoire sur le disque. Ils occupent chacun 5 Mo, quelles que soient les transactions qu'ils contiennent.
Question 19 : quelle est l'importance de la redondance des fichiers journaux de transactions ?
Réponse : en général, les transactions sont rapidement reportées dans les bases de données, mais dans le cas d'un système très chargé, elles peuvent s'accumuler en attendant d'être enregistrées dans les fichiers de base de données. Si le disque des journaux de transactions tombe en panne avant leur enregistrement, ces données seront perdues. Or les fichiers journaux sont au moins aussi importants que la base de données proprement dite. Si une base de données n'a pas été arrêtée correctement (n'est pas cohérente) et que les fichiers journaux sont perdus, la base risque d'être altérée. Dans ce cas, même si vous restaurez la base de données à partir de la sauvegarde, vous perdrez certains messages, car vous ne pourrez pas lire tous les fichiers journaux. En général, si vous effectuez des sauvegardes régulières, il est préférable de perdre le disque de la base de données plutôt que celui des fichiers journaux.
Question 20 : qu'est-ce qui distingue les remises différées des remises non différées, et comment Exchange s'en sert-il ?
Réponse : une fois que les fichiers journaux ont été vidés sur le disque, la transaction est durable ; en cas de panne, vous pourrez relire les journaux et procéder à une restauration. Les remises non différées sont utilisées pour les transactions que les utilisateurs souhaitent verrouiller sur le disque rapidement. Par exemple, lorsqu'un utilisateur clique sur le bouton Envoyer, le contrôle repasse au client et le message est verrouillé dans le système via une transaction non différée. Les remises différées sont utilisées pour les transactions dont la perte n'est pas réellement grave en cas de panne de l'ordinateur. La réplication du dossier public offre un exemple de ce processus : si ce dossier est perdu à la suite d'une panne, la perte de synchronisation est détectée et un renvoi est effectué automatiquement.
Question 21 : à quel moment une transaction est-elle enregistrée dans la base de données et comment cela fonctionne-t-il ? La transaction est-elle d'abord mise en mémoire cache de façon à être virtuellement disponible ou est-il nécessaire de la lire dans les fichiers journaux avant de la transférer dans les fichiers de base de données ?
Réponse : les transactions sont présentes à la fois dans les fichiers journaux et dans les pages de la mémoire cache. Les têtes du disque contenant les journaux de transactions ne reviennent jamais sur les anciennes données ; seules des écritures séquentielles sont effectuées dans les fichiers journaux. Une fois que les transactions sont écrites dans le fichier journal, l'opération est considérée comme complète et les données sont immédiatement disponibles dans la mémoire du serveur, avant d'être réellement enregistrées dans les fichiers de base de données. N'oubliez pas qu'une opération n'est pas complète (autrement dit, le client ne reçoit pas d'accusé de réception) tant que toutes les transactions n'ont pas été enregistrées dans le journal de transactions (sur le disque).
Question 22 : lorsqu'une banque d'informations est récupérée après une panne du système, Exchange est-il assez intelligent pour ne pas dupliquer les transactions existantes de la base de données et récupérer uniquement les transactions qui n'ont pas été enregistrées ?
Réponse : absolument ! La lecture des fichiers journaux est très rapide et si le numéro de version de la transaction se trouve déjà dans la base de données, celle-ci n'est pas enregistrée dans la base. Exchange détecte un éventuel arrêt incorrect de la base de données et, au démarrage, relit toutes les transactions à partir du point de contrôle.
Question 23 : comment puis-je mesurer les performances du processus de journalisation des transactions ?
Réponse : utilisez l'Analyseur de performances et sélectionnez l'objet MSExchangeDB. Configurez les compteurs suivants :
| • | Octets journal écrits/s : vitesse à laquelle les octets sont écrits dans le journal. |
| • | Profondeur du point de contrôle d'enregistrement : valeur numérique proportionnelle au délai nécessaire à la récupération après une panne du système ; cette valeur varie selon les performances des systèmes. Une page de données peut rester pendant longtemps en mémoire cache, sans être vidée dans le fichier .EDB, si elle est utilisée par un grand nombre de threads. Les premières opérations enregistrées sur la page peuvent être relativement anciennes. La profondeur du point de contrôle est définie pour éviter la relecture d'un trop grand nombre de journaux lors de la récupération après un sinistre. Les pages sont vidées si elles contiennent des opérations antérieures à la profondeur du point de contrôle. |
| • | Sessions en attente d'enregistrement : nombre de sessions en attente d'un enregistrement dans le fichier journal pour terminer une transaction. |
Question 24 : lorsque l'enregistrement circulaire est actif, quel est le nombre de fichiers journaux ?
Réponse : le paramètre par défaut correspond à quatre fichiers, mais si la charge du serveur est élevée (importation/migration importante, remplissage d'un dossier public, etc.), le point de contrôle (et donc la fenêtre) peut augmenter. Le paramètre par défaut (quatre fichiers) est restauré lorsque la banque d'informations ou le service Annuaire est arrêté et redémarré.
Question 25 : lorsque l'enregistrement circulaire est actif, peut-on reconstituer les journaux (ceux qui sont présents dans la fenêtre de l'enregistrement circulaire) ?
Réponse : non. L'enregistrement circulaire ne vous permet pas d'effectuer une restauration à partir d'une sauvegarde et de tout remettre à jour. La restauration n'est possible qu'à partir de la sauvegarde, c'est-à-dire uniquement jusqu'au point où la sauvegarde a été réalisée. Exchange Server est configuré avec l'enregistrement circulaire activé par défaut. Vous avez intérêt à le désactiver, à protéger le chargement du disque par des sauvegardes et des suppressions plus régulières, et à vous assurer une marge de sécurité plus large que les quatre transactions de l'enregistrement circulaire.
Question 26 : quel intérêt y a-t-il à désactiver l'enregistrement circulaire ?
Réponse : la désactivation de l'enregistrement circulaire augmente les possibilités de récupération dans la mesure où l'enregistrement non-circulaire conserve un historique des journaux de transactions pour toutes les transactions. Ces fichiers journaux sont vidés seulement lorsqu'une sauvegarde en ligne complète ou incrémentielle enregistre toutes les transactions dans les bases de données et sauvegarde ces dernières. Supposons, par exemple, que votre dernière sauvegarde correcte remonte au lundi et que votre lecteur de base de données tombe en panne le jeudi suivant. Si l'enregistrement circulaire est désactivé et que vos journaux de transactions se trouvent sur un lecteur physique différent de celui qui est tombé en panne, vous pouvez restaurer la sauvegarde du lundi. Si vous ne sélectionnez pasEffacer les données existantes, les fichiers journaux depuis la sauvegarde du lundi sont relus dans la base de données pour assurer sa mise à jour jusqu'au moment de la panne.
L'enregistrement circulaire conserve une fenêtre des journaux de transactions (en général, quatre). Lorsque le fichier4 est plein, un fichier5 est créé et le fichier1 est supprimé. Par conséquent, les seuls fichiers journaux de transactions disponibles pour une restauration sont ceux inclus dans la fenêtre, car les autres ont été purgés.
L'enregistrement circulaire a été développé pour réduire la charge du disque dur. Si vous sauvegardez régulièrement votre système (cela est recommandé), vous n'avez pas besoin de l'enregistrement circulaire.
Question 27 : si l'enregistrement circulaire est désactivé, comment peut-on récupérer, si cela s'avère nécessaire, le contenu des journaux de transactions ?
Réponse : lorsque l'enregistrement circulaire est désactivé, vous pouvez reconstituer le contenu des journaux à partir de la dernière sauvegarde complète. Le point jusqu'où la récupération est possible dépend de votre programme de sauvegarde. Supposons, par exemple, que vous effectuez une sauvegarde complète hebdomadaire le dimanche et des sauvegardes incrémentielles du lundi au samedi. Si vous perdez un disque dur le jeudi, voici l'ordre dans lequel vous devez restaurer les bandes pour un résultat optimal :
1. | Restauration complète le dimanche : ne pas démarrer les services. |
2. | Restauration incrémentielle le lundi : ne pas démarrer les services. |
3. | Restauration incrémentielle le mardi : ne pas démarrer les services. |
4. | Restauration incrémentielle le mercredi : ne pas démarrer les services. |
5. | Après avoir effectué toutes ces opérations, démarrer le service de la banque d'informations. |
Si vous restaurez tous ces jeux de sauvegarde ensemble, puis sélectionnez Démarrer les services, NTBACKUP ne démarrera pas les services avant que tous les jeux n'aient été restaurés. NTBACKUP restaure les données et les fichiers journaux du dimanche, puis ajoute aux fichiers journaux les informations du lundi au mercredi. Lorsque les services redémarrent, NTBACKUP relit tous les fichiers journaux postérieurs à la sauvegarde complète du dimanche jusqu'au moment présent (du lundi au mercredi), ainsi que tous les fichiers journaux créés après la sauvegarde du mercredi.
Les sauvegardes incrémentielles suppriment les fichiers journaux une fois qu'ils ont été sauvegardés. Les sauvegardes différentielles enregistrent les fichiers sur bande, mais ne les suppriment pas. Dans l'exemple précédent, si vous aviez effectué des sauvegardes différentielles, vous n'auriez pas besoin de restaurer les sauvegardes du lundi au mercredi parce que les fichiers journaux correspondants seraient encore présents dans le système (la sauvegarde ne les aurait pas supprimé).
Les sauvegardes incrémentielles et différentielles copient tous les fichiers journaux depuis la dernière sauvegarde, ainsi que le fichier EDB.CHK ; la sauvegarde différentielle ne supprime pas les originaux.
Question 28 : quel est le meilleur compromis en ce qui concerne l'emplacement des fichiers journaux ? Mes ordinateurs possèdent cinq unités de disque. Les deux premières sont en miroir et les trois autres constituent un agrégat par bandes RAID5. Gagnerai-je en performances si je ne mets pas le système d'exploitation en miroir, et si je réserve l'une de ces unités aux journaux de transactions ?
Réponse : avec un serveur Exchange, les meilleures performances sont obtenues en employant un disque dédié aux journaux de transactions. En effet, les enregistrements dans ces fichiers s'effectuent de façon séquentielle et les têtes de lecture/d'écriture sur un lecteur dédié ne rivalisent pas avec les autres processus. Il semble cependant excessif de sacrifier la sécurité d'un système d'exploitation en miroir pour gagner des performances. Dans ce cas, la meilleure solution consisterait à conserver le fichier d'échange Windows NT et les fichiers de base de données Exchange sur les trois disques de l'agrégat par bandes (RAID5) et les journaux de transactions sur les disques en miroir . Si votre système possède suffisamment de RAM, les sollicitations des têtes de disques par le système d'exploitation seront modérées et les performances des journaux de transactions resteront élevées.
Question 29 : comment puis-je libérer de l'espace disque lorsque mon lecteur de fichiers journaux est plein ?
Réponse : si le manque d'espace disque empêche la banque d'informations de démarrer, un événement d'application est enregistré dans l'Observateur d'événements Windows NT. La source de l'événement enregistré est EDB et le test d'erreur inclut l'ID d'erreur 1808. Nous indiquons ci-dessous comment libérer de l'espace disque pour permettre à la banque d'informations de redémarrer et comment utiliser l'Analyseur de performances Windows NT pour suivre l'utilisation de l'espace disque et éviter ainsi que cette situation ne se reproduise.
Surveillance de l'espace disque : utilisez l'Analyseur de performances Windows NT pour suivre l'utilisation de l'espace disque sur le lecteur contenant la banque d'informations. L'objet LogicalDisk, ainsi que les compteurs " % Espace libre" et " Mégaoctets libres" sont utilisés pour surveiller et déclencher des alarmes lorsque l'espace disque est faible.
Récupération de l'espace occupé par les fichiers journaux : en raison de la croissance des fichiers journaux, il peut arriver que la banque d'informations ou l'annuaire ne dispose pas d'un espace suffisant pour fonctionner. Afin d'éviter ce problème, vous pouvez enregistrer les fichiers sur un lecteur différent :
1. | Ouvrez la page de propriétés Objet Serveur et cliquez sur l'onglet Chemins d'accès à la base de données. |
2. | Changez le chemin des journaux de transactions de la banque d'informations et de l'annuaire, puis cliquez sur OK. |
3. | Sauvegardez le serveur Exchange. |
Vous pouvez également utiliser l'utilitaire de sauvegarde Windows NT fourni avec Exchange Server pour exécuter une sauvegarde en ligne normale (complète) ou incrémentielle. Cette opération supprime automatiquement les journaux de transactions qui ont été enregistrés sur disque. Si vous n'exécutez jamais l'utilitaire de sauvegarde, les fichiers journaux continuent de croître, et de consommer de l'espace disque.
L'enregistrement circulaire préserve l'espace disque en supprimant les journaux de transactions une fois qu'ils ont dépassé un point de contrôle (en général, quatre fichiers). Normalement, la plus grande partie des données potentiellement consignées est supprimée. La taille totale des transactions actives est inférieure à la quantité totale de RAM sur un ordinateur donné ; par conséquent l'enregistrement circulaire assure des possibilités de récupération complète du système pour les problèmes liés au matériel et aux logiciels, mais pas pour les pannes de support Ainsi, en cas de coupure de courant ou de panne du serveur, si le serveur peut redémarrer, le service reprendra, même si vous avez activé l'enregistrement circulaire ; par contre, si vous avez perdu le disque dur et devez effectuer la restauration à partir de la sauvegarde, vous ne pourrez pas récupérer toutes les transactions si l'enregistrement circulaire est activé. Les sauvegardes incrémentielle et différentielle utilisent les journaux de transactions et ne sont donc pas prises en charge sur les serveurs où l'enregistrement circulaire est activé.
Le cas échéant, vous pouvez également libérer davantage d'espace disque en supprimant tous les exemples d'applications que vous avez installés.
Pour en savoir plus, reportez-vous à l'article Q163913 en anglais de la Librairie d'Informations Techniques Microsoft, Titre : IS or DS Stops Due to Lack of Drive Space for Log Files.
Sauvegarde et restauration
Question 30 : quelles Options : puis-je choisir pour la sauvegarde et la restauration d'une boîte aux lettres unique ?
Réponse :
| • | utilisez les procédures décrites dans la section Récupération d'une boîte aux lettres unique, dans la première partie de l'article intitulé Récupération de Microsoft Exchange après un sinistre. Cet article explique comment restaurer la banque d'informations sur un serveur de réserve. |
| • | Utilisez des fichiers .PST pour le stockage des boîtes aux lettres, et sauvegardez ces fichiers. |
| • | Utilisez des fichiers .OST pour répliquer les boîtes aux lettres utilisateur. |
| • | Utilisez un programme de sauvegarde tiers qui permet la restauration de boîtes aux lettres isolées. |
Question 31:si je souhaite conserver un serveur de secours en ligne pour pouvoir restaurer des boîtes aux lettres individuelles, dois-je sélectionner Rejoindre un site existant ou Créer un nouveau site lors de l'installation du serveur Exchange ?
Réponse :ne sélectionnez pas Rejoindre un site existant. Configurez un serveur de restauration de boîtes aux lettres individuelles avec les mêmes noms d'organisation et de site que le site depuis lequel vous envisagez de récupérer les données, mais ne sélectionnez pasRejoindre un site existant pendant l'installation. Sélectionnez Créer un nouveau site et utilisez un nom d'ordinateur unique lors de l'installation de Windows NT. Si vous joignez un site, puis exécutez les procédures de restauration d'une boîte aux lettres unique, un comportement de duplication indésirable en résultera après l'exécution du Vérificateur de cohérence SA/BI parce que vous aurez deux jeux de boîtes aux lettres correspondant aux mêmes utilisateurs dans un même site dès que la banque d'informations privée aura été restaurée.
Question 32 : certains utilisateurs utilisent des fichiers .PST et restent connectés la nuit. Comment puis-je sauvegarder leurs fichiers .PST ?
Réponse : le client se déconnecte automatiquement du fichier .PST après 30 minutes d'inactivité et se reconnecte lorsque l'activité reprend. Cette caractéristique vous permet de sauvegarder les fichiers .PST pendant les périodes d'inactivité (généralement pendant la nuit), même si le client reste connecté au serveur Exchange.
Question 33 : ai-je besoin d'une sauvegarde de la base de données de l'annuaire pour récupérer un serveur ?
Réponse : vous devez possédez au moins une sauvegarde du service Annuaire de chaque ordinateur pour pouvoir restaurer un serveur. Quel que soit l'âge de la sauvegarde ; l'annuaire se reconstitue sur l'ordinateur et, après la restauration, dérive les informations courantes des autres annuaires sur le site. Une fois que vous avez installé, répliqué et mis à jour un nouveau serveur sur un site, nous vous conseillons de créer une sauvegarde de l'annuaire.
Lorsque l'annuaire est de nouveau synchronisé après une restauration, exécutez le Vérificateur de cohérence SA/BI pour vous assurer que tous les objets de la banque d'informations sur ce serveur ont été restaurés dans l'annuaire. Si vous ne possédez aucune sauvegarde de l'annuaire à partir duquel un serveur puisse effectuer une restauration (l'ordinateur ayant, par exemple, été détruit dans un incendie) ou si vous perdez l'annuaire et ne disposez d'aucune sauvegarde, la seule option consiste à supprimer le serveur du site et à le réinstaller. Cette solution n'est pas recommandée car vous perdrez toutes les données de votre banque d'informations et une réinstallation est plus longue qu'une restauration.
Il est donc préférable de créer une sauvegarde du service Annuaire dès que possible après l'installation d'un nouveau serveur. Conservez cette sauvegarde dans un endroit sûr. Effectuez régulièrement (chaque mois, chaque semaine ou selon la fréquence qui vous convient) une autre sauvegarde complète et remplacez l'ancienne copie. Cela permet de réduire le temps nécessaire à la resynchronisation de l'annuaire après une restauration, et de remettre rapidement le serveur en fonction.
Question 34 : lorsque je restaure un serveur sur un site, si je ne possède pas une sauvegarde de l'annuaire (DIR.EDB) pour ce serveur, puis-je reconstituer l'annuaire à partir d'une réplique située sur un autre serveur du site ?
Réponse : non. Vous devez impérativement posséder une sauvegarde de l'annuaire pour chaque serveur Exchange, car chaque annuaire est unique. Même si vous ne possédez que la sauvegarde de l'annuaire d'origine, vous pourrez la restaurer, puis récupérer les modifications à partir d'un autre serveur du site.
Question 35 : si je possède une sauvegarde correcte de l'annuaire et de la banque d'informations, et si je restaure un serveur sur un site existant en réinstallant Exchange, dois-je sélectionner Créer un nouveau site ou Rejoindre un site existant pendant l'installation de Microsoft Exchange ?
Réponse : veillez à sélectionner Créer un nouveau site. Ne sélectionnez pasRejoindre un site existant. Lorsque vous redémarrez le serveur après avoir restauré les bases de données, le serveur restauré se synchronise automatiquement avec les serveurs existant sur le site, même lorsque vous sélectionnez Créer un nouveau site. Si vous essayez de Rejoindre un site existant, vous obtiendrez une erreur, car les autres serveurs du site connaîtront déjà le serveur que vous restaurez (son nom correspondant au nom du serveur tombé en panne).
Question 36 : pourquoi ai-je besoin de sauvegarder le système après avoir transféré des utilisateurs sur le serveur ou après une défragmentation ou une réparation en mode autonome ?
Réponse : parce que si un serveur tombe en panne après une migration et que vous n'avez pas sauvegardé le système, vous devrez effectuer de nouveau la migration et cela vous fera perdre du temps.
Une nouvelle signature est enregistrée pour une base de données lorsque celle-ci est défragmentée ou réparée. Ainsi, tous les journaux générés après une défragmentation ou une réparation sont incompatibles avec une base de données antérieure à l'opération. Si un sinistre survient entre une défragmentation ou une réparation et la prochaine sauvegarde en ligne complète, vous ne pourrez pas restaurer la dernière sauvegarde en ligne complète ni lire les fichiers journaux générés après la défragmentation ou la réparation, dans la mesure où leur signature enregistrée aura changé. Un moyen simple de vous protéger en cas de panne consiste à exécuter une sauvegarde en ligne complète immédiatement après une défragmentation ou une réparation.
Question 37 : je ne trouve pas le jeu de sauvegardes sur ma bande. Quelle peut être l'origine du problème ?
Réponse : veillez à charger le catalogue de la bande avant de restaurer les données. Ce processus vous permet d'obtenir des informations relatives aux fichiers sur la bande et de lancer le processus de restauration.
Pour charger le catalogue des jeux de sauvegardes sur bande :
1. | Dans la fenêtre Bandes, sélectionnez la bande dont vous voulez charger le catalogue. |
2. | Choisissez Catalogue en double-cliquant sur l'icône de la bande, puis en cliquant sur le bouton Catalogue dans la barre d'outils ou sur la commande Catalogue dans le menu Opérations. |
Une recherche est lancée sur la bande et la liste complète des jeux de sauvegardes s'affiche dans la fenêtre Bandes ; un point d'interrogation (?) apparaît en regard de chacune des icônes pour indiquer que les catalogues individuels n'ont pas été chargés.
Question 38 : mon lecteur de bande est inutilisable et j'ai absolument besoin de sauvegarder les bases de données. Comment faire ?
Réponse : la méthode proposée nécessite de l'espace disque. Arrêtez les services. Copiez les fichiers PRIV.EDB et PUB.EDB à partir de \exchsrvr\mdbdata (emplacement d'installation par défaut) et le fichier DIR.EDB à partir de \exchsrvr\dsadata (emplacement d'installation par défaut). Il est inutile de copier les fichiers des journaux de transactions, dans la mesure où toutes les transactions sont transférées dans la base de données lorsque les services sont arrêtés normalement. Si vous avez besoin d'effectuer une restauration à partir de ce type de sauvegarde, supprimez les fichiers journaux et EDB.CHK de leurs répertoires respectifs, recopiez les fichiers .EDB et suivez la procédure pour exécuter isinteg -patch. Lorsque les services démarrent, un nouveau fichier EDB.CHK est créé en même temps que les nouveaux journaux de transactions. Veillez à sauvegarder tous les fichiers avant de les purger. Nous vous conseillons, pour de telles opérations, de contacter le Service de Support Technique de Microsoft.
Question 39 : comment puis-je sauvegarder un serveur Exchange à partir d'un serveur de sauvegarde Windows NT sur lequel ni Exchange Server ni le programme Administrateur Exchange ne sont installés ?
Réponse : si vous copiez des fichiers à partir d'un serveur Exchange existant :
1. | Renommez ou supprimez le fichier WINNT-WINNT-ROOT\SYSTEM32\NTBACKUP.EXE courant du serveur de sauvegarde Windows NT. |
2. | Copiez Winnt-Winnt-Root\System32\NTBACKUP.EXE, EDBBCLI.DLL et MSVCRT40.DLL d'un serveur de messagerie Exchange dans le sous-répertoire Winnt- Root\System32 du serveur de sauvegarde Windows NT. |
3. | Copiez Exchsrvr\Bin\EDBBACK.DLL du serveur Exchange dans le sous-répertoire Winnt Root\System32 du serveur de sauvegarde Windows NT. |
Si vous copiez des fichiers à partir du CD-ROM Exchange Server :
1. | Renommez ou supprimez le fichier Winnt-Winnt-Root\System32\NTBACKUP.EXE courant du serveur de sauvegarde Windows NT. |
2. | Copiez les fichiers NTBACKUP.EXE, EDBBCLI.DLL, EDBBACK.DLL et MSVCRT40.DLL, situés dans Setup\I386 (ou MIPS ou Alpha) sur le CD-ROM Exchange Mail Server dans le sous-répertoire Winnt Root\System32 du serveur de sauvegarde Windows NT. |
Question 40 : est-il conseillé d'exporter régulièrement l'annuaire ?
Réponse : c'est une bonne idée, car l'exportation est rapide et vous permettra d'économiser beaucoup de temps en cas de perte de toutes les sauvegardes d'annuaire, de destruction d'un serveur ou d'incapacité, pour une raison quelconque, à restaurer la base de données de l'annuaire. En principe, vous n'aurez jamais besoin de recourir à l'annuaire exporté, mais le cas échéant, vous ne regretterez pas d'avoir consacré du temps à cette opération.
Question 41 : faut-il désactiver le tampon d'écriture des contrôleurs SCSI ?
Réponse : oui. À moins que votre contrôleur SCSI ne dispose d'une batterie de secours, cette mesure réduit les risques de perte de données. Si le paramètre write-through est activé au niveau de la programmation, Windows NT n'utilise pas de tampons ; ainsi, lorsqu'un programme reçoit un signal écriture terminée de Windows NT, il est assuré que l'écriture a bien été effectuée sur le disque. Cela est déterminant pour la journalisation des transactions Exchange. Si le tampon d'écriture est activé et que des données y sont placées, Windows NT informe, à tort, l'application appelante que l'écriture est terminée. Si une panne se produit avant la fin de l'écriture, une altération des données est possible.
Question 42 : à quoi sert la commande install /r ?
Réponse :install /r permet de reconstituer un serveur Exchange existant sur une autre machine. Cette commande suppose que vous disposez d'une sauvegarde correcte des bases de données Exchange, et ne génère aucune base de données par défaut (vide). Après l'exécution de install /r, vous devez restaurer les bases de données Exchange à partir de la sauvegarde.
Install /r est une mise à niveau utilisée pour déplacer un serveur sur une autre machine ou pour effectuer une restauration sur un autre ordinateur. Supposons, par exemple, que votre serveur est détruit (astéroïde) et que vous devez vous procurer un nouvel ordinateur pour le remplacer. À cette occasion, vous envisagez de choisir un ordinateur x86 plus récent et plus rapide, ou encore un Alpha. Une fois la machine acquise, vous avez besoin d'une sauvegarde complète du service Annuaire et de la banque d'informations. S'il s'agit simplement d'une mise à niveau, vous pouvez arrêter le serveur d'origine et continuer. Si votre ancien serveur a été détruit suite à une catastrophe naturelle et que vous ne disposez pas d'une bande avec une sauvegarde complète (il se peut que vous l'ayez conservée à proximité de l'ordinateur et qu'elle ait été détruite en même temps que ce dernier), il ne vous reste plus qu'à rentrer chez vous.
Si, en revanche, vous possédez la sauvegarde complète, vous pouvez continuer. Commencez par configurer le nouvel ordinateur avec Windows NT. Exécutez ensuite install /r pour installer le logiciel Exchange sans démarrer de service ni initialiser le service Annuaire sur un site, etc. Restaurez à présent la sauvegarde sur le nouveau serveur et démarrez les services. Le nouvel ordinateur démarre et se comporte exactement comme l'ancienne machine.
Figure 1 Premier écran lors de l'exécution de
install /r
Remarque Si vous effectuez une récupération après un sinistre sur un serveur Exchange 4.0 et avez besoin de charger des Service Packs, n'utilisez pas install /r pour installer le serveur. Le chargement de Service Packs sur un serveur Exchange installé avec install /r nécessite l'exécution de la commande update /r et celle-ci n'est pas prise en charge par les Service Packs Exchange 4.0.
Question 43 : quelles implications la récupération d'un serveur Exchange selon ce scénario a-t-elle sur Windows NT ? Le serveur Exchange est physiquement détruit (suite à une catastrophe naturelle, telle une inondation). Nous sommes obligé de recréer un ordinateur identique et de le recharger à partir de la dernière sauvegarde (les bandes sont stockées à un emplacement situé en hauteur). Le serveur Exchange est un serveur membre, non un contrôleur de domaine.
Réponse : reportez-vous à la documentation de Microsoft Exchange Server.
Vous devez régénérer l'identificateur de sécurité (SID). Chaque ordinateur Windows NT requiert un SID unique. Étant donné que l'inondation a détruit votre serveur d'origine, son SID n'est plus correct. Sur le contrôleur principal du domaine (CPD) où résidait le serveur Exchange, supprimez la définition du serveur qui est tombé en panne et créez-en une avec le même nom (à cet effet, utilisez le Gestionnaire de serveur). Un nouveau SID et un nouveau compte d'ordinateur sont alors initialisés dans le Gestionnaire des comptes de sécurité (SAM) du domaine. Lorsque vous installez Windows NT sur le serveur de récupération et associez le nouveau serveur au domaine, un objet secret de l'autorité de sécurité locale (LSA) est créé pour ce serveur de récupération et un nouveau SID est assigné. Un mot de passe associé à l'objet secret est généré et synchronisé avec le mot de passe du compte d'ordinateur dans le Gestionnaire des comptes de sécurité. NETLOGON utilise ce mot de passe chaque fois que le serveur démarre et se connecte au domaine. Si vous ne commencez pas par supprimer, puis rajouter la définition du serveur tombé en panne dans le domaine, vous ne pourrez pas associer un serveur de même nom au domaine, car NETLOGON échouera.
Tant que vous avez accès au Gestionnaire des comptes de sécurité du domaine d'origine (vous ajoutez le nouvel ordinateur en tant que serveur dans le même domaine), vous pouvez restaurer l'annuaire Exchange. Si le serveur récupéré n'a pas accès au Gestionnaire des comptes de sécurité d'origine et que vous restaurez l'annuaire, vous ne pourrez pas accéder aux données Exchange après la restauration. En effet, l'annuaire Exchange utilise les informations SID pour authentifier l'accès aux objets et les informations SID restaurées ne correspondront pas aux informations SID du Gestionnaire des comptes de sécurité dans le nouveau domaine.
Reportez-vous à l'article en anglais Q163686 de la Librairie d'Informations Techniques Microsoft, intitulé : XADM : What to do if the Service Account is Deleted ?
Question 44 : est-il vrai que si un nom d'ordinateur est effacé du domaine, puis recréé, et que le Registre Windows NT est ensuite restauré à partir de la bande, le SID local du Registre Windows NT restauré ne correspondra pas au nouveau SID créé dans le domaine ?
Réponse : oui. Vous ne devez supprimer et recréer le nom d'ordinateur d'un serveur Exchange dans le domaine que si un nouveau serveur Exchange est requis pour la récupération. Le Registre Windows NT contient des informations spécifiques à l'ordinateur ; vous devez donc le restaurer sur le même ordinateur physique (la restauration sur un autre ordinateur physique n'est pas prise en charge). Voir Q139822, intitulé en anglais : How to Restore a Backup to Computer with Different Hardware. Cette situation peut survenir si, par exemple, vous remplacez le disque dur du système d'exploitation (uniquement), puis restaurez Windows NT.
Autre problème : la base de données de l'annuaire Exchange gère les informations sur les ID Windows NT dans le domaine (informations ACL). Si vous ne pouvez pas accéder au Gestionnaire des comptes de sécurité (SAM) à partir du domaine d'origine et que vous en créez un nouveau en installant un nouveau domaine, puis restaurez le service Annuaire, vous créez une discontinuité entre la sécurité des objets dans l'annuaire (compte de service Exchange, boîtes aux lettres utilisateur, compte administrateur) et le nouveau Gestionnaire des comptes de sécurité du domaine. Vous ne pourrez accéder à aucun objet dans l'annuaire Exchange.
Question 45 : que se passe-t-il si mon serveur Exchange est un contrôleur principal de domaine (CPD), et qu'il est détruit ou doit être mis à jour sur un nouvel ordinateur ?
Réponse : dans ce cas, transformez l'un des contrôleurs secondaires de domaine (CSD) en contrôleur de domaine principal (CPD). Déployez le serveur de récupération et suivez les procédures décrites dans la section Récupération complète d'un serveur du chapitre 9.
Question 46 : la restauration complète d'un serveur sur un autre ordinateur physique exige-t-elle une configuration CSD ou CPD ?
Réponse : pas nécessairement. L'important est de supprimer le compte de l'ordinateur, puis de le recréer dans le domaine de production afin que l'ordinateur de secours puisse obtenir un nouveau SID qui emploie le même nom que le serveur de production d'origine.
Question 47 : une restauration différentielle est-elle nécessaire uniquement lorsque la récupération est requise à la fois sur le disque des transactions et le disque des fichiers .EDB ?
Réponse : oui. Si l'enregistrement circulaire est désactivé et que les journaux de transactions sont intacts, vous pouvez restaurer la dernière sauvegarde complète. Au démarrage du service, les journaux postérieurs au point de la dernière sauvegarde complète sont repris dans le fichier EDB.LOG courant pour mettre à jour la base de données. Dans ce cas, ne sélectionnez pasSupprimer les données existantes pendant la restauration car les journaux de transactions seraient effacés et il vous faudrait restaurer le dernier jeu de sauvegardes différentielles.
Question 48 : pourquoi ne puis-je pas démarrer les services entre la restauration d'une bande complète et celle d'une bande différentielle ou incrémentielle, ou entre la restauration de bandes séquentielles ?
Réponse : à la fin d'une restauration, Exchange récupère les données des journaux dans un ordre séquentiel, puis active un nouvel état pour la base de données. Supposons que vous poursuivez votre travail et envisagez d'exécuter une restauration de la bande incrémentielle du lundi, suivie de celle du mardi. Si vous démarrez les services après la bande du lundi, un nouvel état est défini. Si, maintenant, vous essayez d'exécuter la restauration incrémentielle du mardi, celle-ci échoue. En effet, l'état de la base de données doit être exactement tel qu'il était au point de la sauvegarde du mardi ; or, ce n'est plus le cas, car un nouvel état a été défini au démarrage des services. Cette fonctionnalité de Microsoft Exchange évite l'écrasement des opérations qui ont eu lieu sur la base de données après le démarrage des services.
Questions générales
Question 49 : comment puis-je arrêter rapidement les services Exchange sans passer par le Panneau de configuration ? Les services mettent quelquefois beaucoup de temps à s'arrêter.
Réponse : vous pouvez arrêter les services par l'intermédiaire de la ligne de commande ou utiliser l'exemple de fichier de commandes suivant. Pour arrêter l'ensemble du système à partir d'un fichier de commandes, employez la commande shutdown du Kit de ressources Windows NT (que vous trouverez dans le Kit de ressources Microsoft Windows NT). Cette commande permet d'arrêter les services dans l'ordre inverse de dépendances. Pour arrêter un service MTA dont le nom comporte des espaces, utilisez des guillemets.
REM // arrêt de tous les services
echo Stopping Services...
net stop MSExchangeMSMI
net stop MSExchangePCMTA
net stop MSExchangeFB
net stop MSExchangeDX
net stop MSExchangeIMC
net stop MSExchangeMTA
net stop MSExchangeIS
net stop MSExchangeDS
net stop MSExchangeSA
REM : placez ici l'appel de la commande shutdown
(requiert le Kit de Ressources Techniques de Windows NT)
Question 50 : lorsque j'arrête les services, ils tentent de redémarrer. Pourquoi, et que dois-je faire ?
Réponse : ce problème est le plus souvent provoqué par une session de superviseur de serveur configurée pour le serveur sur lequel vous essayez d'arrêter les services. Si vous activez admin /t (mode maintenance) au moins un intervalle d'interrogation avant d'arrêter les services, le superviseur de serveur est averti que les prochaines interrogations du serveur en mode maintenance ne devront plus provoquer d'alertes ou d'alarmes. Vous pouvez alors arrêter les services et effectuer la maintenance. Lorsque vous avez terminé, réexécutez admin /t pour réactiver la supervision. Pour obtenir la liste des commutateurs de la commande admin, tapez admin /? à partir du sous-répertoire exchsrvr\bin.
Question 51 : Exchange 5.5 prend en charge les bases de données d'une taille supérieure à 16 Go. Pourrai-je diminuer la taille des serveurs avec la consolidation ?
Réponse : absolument. La consolidation simplifie l'administration et permet aux utilisateurs de disposer de quotas de stockage supérieurs ; tenez cependant compte des facteurs suivants lorsque vous programmez l'opération :
| • | Temps nécessaire à la sauvegarde et à la restauration avec votre matériel existant. |
| • | Temps nécessaire à la maintenance de la base de données en mode autonome (contrôle d'intégrité, défragmentation et réparation). |
Ces facteurs ont également une incidence sur la durée d'immobilisation en cas de sinistre. Testez votre matériel pour déterminer les conditions en matière de délai et utilisez ces informations pour déterminer la taille optimale de la base de données.
Enfin, lorsque vous calculez les utilisateurs par serveur, n'oubliez pas la durée de rétention des éléments supprimés (la fonction "Récupérer les éléments supprimés" dans Outlook), qui permet aux utilisateurs de récupérer les messages supprimés. La fonction de récupération des éléments, en conservant les messages après qu'ils ont été marqués pour suppression, provoque une augmentation en taille des bases de données des banques d'informations privée et publique. Exchange ne comptabilise pas ces messages dans le calcul de la quantité de mémoire utilisée par une boîte aux lettres.
Question 52 : quel avantage y a-t-il à créer des contrôleurs de domaine secondaires pour les serveurs Exchange ?
Réponse : le fait de configurer les serveurs Exchange en tant que CSD permet d'augmenter les possibilités de récupération et de réduire les coûts. Cette méthode va cependant de paire avec une augmentation des besoins en mémoire du serveur Exchange.
Examinez les scénarios suivants :
| • | Dans un environnement avec un seul serveur, le serveur Exchange est un contrôleur de domaine principal (CPD) et doit être remplacé. Vous pouvez recréer un contrôleur de domaine Windows NT Server et restaurer la banque d'informations, mais vous ne pouvez pas restaurer le service Annuaire sur un domaine qui ne possède pas le Gestionnaire des comptes de sécurité (SAM) d'origine . |
| • | Dans un environnement avec deux serveurs, il existe un CPD et l'ordinateur Exchange est un serveur membre. Le CPD tombe en panne. Il n'y a pas de SAM. Même situation que plus haut : vous ne pouvez pas restaurer le SAM (registre) sur un autre ordinateur physique à partir d'une sauvegarde sur bande, chaque Registre Windows NT étant spécifique à un ordinateur. |
| • | Dans un environnement avec deux serveurs, il existe un CPD et l'ordinateur Exchange est un CSD. Le CPD tombe en panne. Vous pouvez transformer le serveur Exchange en CPD. Si le serveur Exchange tombe en panne, vous pouvez créer un nouveau CSD ou serveur membre avec le même nom que le serveur Exchange et restaurer la banque d'informations et l'annuaire, car vous avez la possibilité d'accéder au SAM d'origine. |
La configuration d'un serveur Exchange en tant que CSD risque de provoquer une diminution des performances de la mémoire, mais reste une tactique efficace pour les bureaux à distance : elle augmente les possibilité de récupération et permet de réduire les coûts, dans la mesure où le serveur Exchange peut authentifier les utilisateurs Windows NT et fournir des services de messagerie. Pour plus d'informations sur la programmation des domaines et sur les besoins en mémoire des CPD et CSD, consultez le Guide Réseau de Microsoft Windows NT Server 4.0 (inclus dans le Kit de Ressources).
Question 53 : que font les sociétés tierces et en quoi apportent-elles de la valeur ajoutée ?
Réponse : vous pouvez rechercher des
solutions tierces pour Exchange sur le site Microsoft Exchange
Dernière mise à jour le mercredi 27 septembre 2000