Procédures de sauvegarde et de restauration en mode hors connexion pour Exchange

Traductions disponibles Traductions disponibles
Numéro d'article: 296788 - Voir les produits auxquels s'applique cet article
Cet article peut contenir des liens vers des informations en langue anglaise (pas encore traduites).
Agrandir tout | Réduire tout

Sommaire

Résumé

Cet article décrit les méthodes à utiliser afin de contourner les API de sauvegarde en ligne et de sauvegarder et restaurer manuellement les bases de données de la banque d'informations Exchange. Si vous avez plusieurs groupes de stockage sur un seul serveur Exchange, chacun doit être considéré comme une unité indépendante, autonome, pour les besoins de la restauration et de la sauvegarde hors connexion.Pour plus d'informations sur les sauvegardes hors connexion et instantanées, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
296787 XADM : Procédures de sauvegarde et de restauration hors connexion pour Exchange Server 4.0, 5.0 et 5.5

Plus d'informations

Cet article contient les sections suivantes :

Avant de commencer

Avant d'effectuer une sauvegarde hors connexion, assurez-vous que vous disposez des informations suivantes :
  • Déterminez si l'enregistrement circulaire est activé ou non pour le groupe de stockage. (L'enregistrement circulaire est désactivé par défaut dans Exchange.) Pour ce faire, ouvrez les propriétés de l'objet groupe_stockage dans le Gestionnaire système Exchange, puis consultez la page Général. Pour désactiver l'enregistrement circulaire, décochez la case Enregistrement circulaire. Les modifications apportées à l'enregistrement circulaire n'entrent pas en vigueur tant que vous n'arrêtez pas toutes les bases de données du groupe de stockage.

    Vous n'avez pas besoin de désactiver l'enregistrement circulaire pour effectuer des sauvegardes hors connexion. En revanche, vous devez le désactiver pour pouvoir relire les journaux de transactions dans des sauvegardes hors connexion restaurées.
  • Déterminez les emplacements de chemins d'accès de votre base de données Exchange, de vos fichiers de transmission en continu, de journaux de transactions, de points de contrôle, ainsi que du préfixe de fichier journal pour le groupe de stockage.

    Pour trouver ces informations, ouvrez les propriétés de l'objet groupe_stockage dans le Gestionnaire système Exchange, puis consultez la page Général. Notez les valeurs contenues dans les trois zones suivantes :
    • Préfixe de fichier journal (E0n, E0n pouvant être E00, E01, E02 ou E03)
    • Emplacement du journal des transactions (E0n * .log)
    • Emplacement du chemin d'accès système (E0n.chk)
    Les chemins d'accès à la base de données sont répertoriés dans les propriétés Base de données de chaque objet nom_base_de_données. Enregistrez les valeurs des deux champs suivants pour chaque base de données du groupe de stockage :
    • Base de données Exchange (.edb)
    • Base de données de transmission en continu Exchange (.stm)
Si le Gestionnaire système Exchange n'est pas disponible, vous pouvez rechercher toutes les informations précédentes en lisant directement les attributs bruts d'Active Directory avec un outil tel que ADSIEDIT ou LDIFDE. Vous pouvez utiliser la commande LDIFDE suivante pour afficher ces informations pour tous les serveurs Exchange dans une forêt Active Directory.

REMARQUE : Des retours automatiques à la ligne ont été insérés dans le texte pour en améliorer la lisibilité.
LDIFDE -F EXPATHS.TXT -D "CN=CONFIGURATION,DC=domaine_conteneur_configuration,DC=domaine_niveau_supérieur" -L MSEXCHESEPARAMLOGFILEPATH,MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME,MSEXCHESEPARAMCIRCULARLOG,MSEXCHSLVFILE,
MSEXCHEDBFILE -R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
Voici un exemple de sortie de la commande précédente :
D:\exchsrvr\mdbdata>ldifde -f con -d "cn=configuration,dc=test,dc=com" -l msexch eseparamlogfilepath,msexcheseparamsystempath,msexcheseparambasename,msexchesepar amcircularlog,msexchslvfile,msexchedbfile -r "(|(msexcheseparamlogfilepath=*)(ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*)(msexchedbfi le=*)(msexcheseparamcircularlog=*))"
Connecting to "dc1.child.test.com"
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries...

<sortie tronquée>

.dn: CN=First Storage Group,CN=InformationStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Excha nge,CN=Services,CN=Configuration,DC=Test,DC=com
changetype: add
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.dn: CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=Informati onStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Tes t,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.dn: CN=Private Information Store (Exchange1),CN=First Storage Group,CN=Informat ionStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Te st,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Pour pouvoir relire les journaux de transactions, vous devez restaurer les fichiers de base de données (.edb et .stm) aux mêmes emplacements de chemin d'accès que ceux où ils ont été sauvegardés. Par exemple, si vous sauvegardez le fichier de base de données à partir du dossier E:\Mdbdata et le fichier de base de données de transmission en continu à partir du dossier F:\Mdbdata, vous devez restaurer les fichiers sur E:\Mdbdata et F:\Mdbdata, respectivement. Cette limitation s'applique même si vous souhaitez restaurer la base de données sur un serveur complètement différent (par exemple, en cas de récupération d'une seule boîte aux lettres).

Si vous modifiez un chemin d'accès à la base de données après la dernière sauvegarde, vous pouvez seulement relire les journaux des transactions partiellement. Pour ce faire, vous devez modifier le chemin d'accès à l'emplacement d'origine. Si vous rétablissez l'ancien chemin d'accès, vous pouvez relire des journaux jusqu'au point auquel le chemin d'accès a été modifié.

Vous pouvez restaurer des fichiers de journaux de transactions (E0n * .log) sur un chemin d'accès différent de l'emplacement de sauvegarde d'origine. La raison en est que les journaux de transactions enregistrent les emplacements des bases de données auxquelles les journaux de transactions sont joints, mais qu'en revanche les bases de données n'enregistrent pas les emplacements de journaux des transactions. Pendant la lecture, les journaux « trouvent » les bases de données grâce aux informations relatives au chemin d'accès stockées dans les en-têtes des journaux de transactions. (L'API de sauvegarde en ligne compensant en interne les changements de chemin d'accès à la base de données, cette limitation ne s'applique pas.)

Vous ne sauvegardez ni ne restaurez le fichier de point de contrôle (E0n.chk), mais vous devez connaître l'emplacement actuel du fichier de point de contrôle parce que vous pouvez avoir besoin de le consulter ou de le supprimer pendant la récupération.

Retour à la liste des sections

Relations entre les fichiers de base de données Microsoft Exchange

Les fichiers .edb et .stm sont les derniers référentiels pour toutes les informations sur la base de données. Dans la plupart des cas, traitez ces deux fichiers comme s'ils constituaient un fichier unique ; sauvegardez-les et restaurez-les en tandem. Ces fichiers doivent rester synchronisés chronologiquement l'un avec l'autre ; un fichier .edb sauvegardé un jour ne peut pas être mis en correspondance avec un fichier de transmission en continu sauvegardé un autre jour.

Un serveur Exchange 2000 ou Exchange 2003 peut prendre en charge jusqu'à quatre groupes de stockage, chacun pouvant prendre en charge jusqu'à cinq bases de données. Un groupe de stockage est un ensemble de bases de données qui partagent un jeu commun de fichiers de journaux de transactions. Microsoft Exchange Server 5.5 peut prendre en charge un seul groupe de stockage qui prend en charge jusqu'à deux bases de données (banques d'informations privées et publiques).

À mesure que les modifications sont apportées à la base de données, elles sont écrites d'abord dans le fichier de journal de transactions actuel, puis dans un cache interne. Dès que les modifications se trouvent dans le cache, elles deviennent visibles pour les utilisateurs. Les pages du cache sont vidées dans le fichier de base de données à un moment propice. Le point de contrôle marque le point dans la séquence du fichier journal jusqu'auquel toutes les transactions ont été vidées physiquement dans le fichier de base de données. Il est normal que le point de contrôle soit en retard d'au moins trois fichiers journaux par rapport au fichier journal en cours.

Pour éviter toute confusion à propos des fichiers journaux appartenant à chaque groupe de stockage, les journaux Exchange qui appartiennent à un groupe de stockage donné sont nommés avec un préfixe de journal unique, constitué des trois premiers caractères du nom de fichier. Les préfixes de journal valides pour les quatre groupes de stockage pris en charge sur un serveur Exchange 2000 ou Exchange 2003 sont E00, E01, E02 et E03. Partout dans cet article, le préfixe de journal d'un groupe de stockage est désigné par E0n. Le fichier journal en cours pour un groupe de stockage est toujours E0n.log.

Les journaux de transactions font tous 5 mégaoctets (Mo). Lorsque le fichier journal en cours est saturé, il est renommé avec un numéro de séquence hexadécimal, appelé numéro de création de journal, et un nouveau fichier journal est généré. Les fichiers journaux sont numérotés E0n00001.log, E0n00002.log et ainsi de suite. Partout dans cet article, les fichiers journaux numérotés sont désignés génériquement par E0nxxxxx.log.

Si une base de données est arrêtée anormalement, le fichier de point de contrôle (E0n.chk) enregistre le journal de transactions à partir duquel la récupération doit commencer la lecture pour restaurer la cohérence de la base de données. Ce processus est appelé la « récupération logicielle ». Elle constitue le pendant de la « récupération matérielle », qui consiste à relire les fichiers journaux après la restauration d'une sauvegarde en ligne. La différence la plus importante entre ces deux types de récupération est l'interpolation des données de fichiers de correctifs dans le processus de relecture du fichier journal au cours de la récupération matérielle.

Un fichier de base de données Microsoft Exchange incohérent est un fichier dans lequel toutes les transactions en suspens n'ont pas encore été écrites. Normalement, les fichiers de base de données Microsoft Exchange sont incohérents parce que certaines informations se trouvant dans le cache n'ont pas encore été écrites physiquement dans le fichier. En général, un fichier de base de données Exchange peut être considéré comme étant cohérent uniquement après un arrêt normal du service de base de données. Néanmoins, la base de données prise dans son ensemble (en tant que somme des informations stockées à la fois dans les journaux de transactions et les fichiers de bases de données) est toujours cohérente à moins que des fichiers journaux nécessaires soient supprimés prématurément.

Retour à la liste des sections

Sauvegarde d'une base de données Exchange en mode hors connexion

Pour sauvegarder une base de données Exchange en mode hors connexion :
  1. Démontez la base de données à sauvegarder. Vous n'avez pas besoin de démonter toutes les bases de données se trouvant dans le groupe de stockage, seulement celle(s) à sauvegarder.
  2. Vérifiez que les fichiers de base de données (les fichiers .edb et .stm) sont cohérents et concordants. Pour ce faire, exécutez la commande suivante pour chaque fichier :
    eseutil /mh database file | find /i "DB Signature"
    REMARQUE : Le Service Pack 2 Exchange 2000 et les versions ultérieures ne signalent pas l'état de la base de données comme étant « Consistent » (Cohérent) ou « Inconsistent » (Incohérent), mais comme « Clean shutdown » (Arrêt normal) ou « Dirty shutdown » (Arrêt intempestif). Le premier correspond à « Consistent » et le second à « Inconsistent ». Si vous possédez Exchange 2000 Service Pack 2 ou une version ultérieure, exécutez cette commande supplémentaire pour déterminer l'état de chaque base de données :
    eseutil /mh nom_base_de_données | find /i "Shutdown"
    Voici un exemple du texte de sortie de la commande précédente :
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    Dans l'exemple précédent, les signatures DB (DB signature) sont identiques, ce qui prouve que les fichiers .edb et .stm appartiennent au même jeu. (Les deux lignes de signature doivent correspondre au caractère près dans leur intégralité pour constituer une correspondance de signature.)

    Non seulement les signatures DB doivent correspondre, mais les fichiers doivent également être synchronisés et cohérents entre eux. Exécutez la commande suivante pour chaque fichier :
    eseutil /mh database file | find /i "consistent"
    Voici un exemple de sortie de la commande précédente :
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    Dans l'exemple précédent, les deux fichiers signalent « State: Consistent » (état cohérent). Les nombres hexadécimaux entre parenthèses pour chaque fichier (0x2CC7,1F14,1F7) doivent également correspondre. Le dernier horodatage cohérent n'a pas besoin de correspondre. Ces fichiers sont à la fois cohérents et concordants.

    Si l'un des fichiers signale « State: Inconsistent » (état incohérent) ou si les dernières positions de journal cohérentes ne sont pas synchronisées, la base de données n'a pas été démontée correctement. Montez la base de données puis démontez-la à nouveau. Si les fichiers ne correspondent toujours pas ou sont incohérents, contactez les Services de support technique Microsoft (PSS) pour obtenir une aide supplémentaire.
  3. Copiez tous les fichiers de base de données .edb et les fichiers de base de données de transmission en continu .stm correspondants vers un emplacement de sauvegarde.
  4. Montez les bases de données sauvegardées.
  5. Si l'enregistrement circulaire est activé, ignorez cette étape. Si l'enregistrement circulaire est désactivé et que vous souhaitez « restaurer par progression » plus tard, vous devez sauvegarder tous les fichiers de journaux de transactions numérotés (fichiers E0nxxxxx.log). Ne sauvegardez pas les fichiers E0n.log, Res1.log et Res2.log.

    Vous pouvez sauvegarder des fichiers journaux numérotés à tout moment, même immédiatement après leur création, car, une fois qu'un fichier journal a été renommé de E0n.log en E0nxxxxx.log, Exchange ne le modifie plus. Toutefois, respectez les instructions présentées à l'étape 6 pour supprimer définitivement les fichiers journaux sauvegardés.

    Vos sauvegardes de fichiers journaux ne correspondent pas unilatéralement à vos sauvegardes de base de données. Chaque sauvegarde de fichier journal est un chaînon dans une chaîne de fichiers journaux qui peut être lu sur l'une des différentes sauvegardes de la base de données. Vous pouvez restaurer par progression à partir d'une sauvegarde de base de données particulière tant que vous avez un flux continu de journaux commençant par le journal répertorié dans la ligne « Last Consistent » (dernière ligne cohérente) de l'en-tête de la base de données. Dans cet article, le dernier journal cohérent est désigné par le terme « journal d'ancrage inférieur ».

    Si vous vous référez à l'exemple précédent, la dernière entrée cohérente est (0x2CC7,1F14,1F7). Les trois nombres désignent un fichier journal, une page dans ce fichier journal et un décalage d'octet dans cette page. Chaque fichier journal contient approximativement 10 000 pages de 512 octets chacune. Le décalage de page vous donne une indication du taux de remplissage du fichier journal (le fichier journal dans l'exemple précédent est plein à environ 80 %, car 0x1F14 est équivalent à 7956 décimal), mais cela n'est pas pertinent pour la récupération. La récupération démarre toujours au début d'un fichier journal.

    Dans cet exemple, le fichier journal d'ancrage inférieur est E0n02cc7.log.

    Le dernier journal cohérent sur disque n'est pas toujours visible sous la forme d'un journal numéroté, car il est possible qu'il soit toujours nommé E0n.log. Vous pouvez consulter le numéro d'ordre qu'E0n.log portera en examinant l'en-tête du fichier journal pendant que la base de données est arrêtée (l'accès à l'en-tête E0n.log est refusé pendant que la base de données est en cours d'exécution).

    Pour consulter le numéro de création de journal interne, exécutez la commande suivante :
    eseutil /ml [log file] | find /i "lGeneration"
    Voici un exemple de sortie de la commande précédente :
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    Dans de nombreux cas, il est plus important de s'assurer que les sauvegardes de fichiers journaux sont correctes que de s'assurer que toutes les sauvegardes de bases de données sont correctes. La raison en est que chaque sauvegarde de base de données peut fournir une redondance pour les autres, mais la récupération complète de toute sauvegarde de base de données dépend de la conservation de chaque fichier journal après cette sauvegarde.
  6. Ignorez cette étape si l'enregistrement circulaire est activé. Examinez l'en-tête du fichier de point de contrôle pour déterminer le fichier journal portant le numéro le plus élevé qui peut être supprimé sans risque. Le point de contrôle suit le fichier journal portant le numéro le plus bas nécessaire à la récupération automatique si la base de données est arrêtée anormalement. Pour examiner le fichier de point de contrôle, exécutez la commande suivante :
    eseutil /mk E0n.chk
    Voici un exemple de sortie de la commande précédente :
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    La troisième ligne, la ligne concernant le point de contrôle, contient les informations pertinentes (l'entrée LastFullBackupCheckpoint est utilisée par la sauvegarde en ligne et conserve tous les zéros si une sauvegarde en ligne n'est jamais effectuée sur la base de données). Le format de la position du journal de point de contrôle est identique à la dernière entrée cohérente dans l'en-tête de la base de données. Dans cet exemple, le point de contrôle se trouve dans E0002cc7.log.

    Si l'enregistrement circulaire est désactivé, les fichiers journaux s'accumulent jusqu'à ce qu'ils soient supprimés manuellement ou automatiquement par le processus de sauvegarde en ligne. Si l'enregistrement circulaire est activé, aucune gestion spéciale des anciens fichiers journaux n'est nécessaire, car le service de base de données supprime automatiquement les anciens fichiers journaux une fois que le point de contrôle est passé par eux.

    Après avoir sauvegardé tous les fichiers journaux numérotés, vous pouvez récupérer l'espace disque en supprimant tous les fichiers journaux numérotés jusqu'au journal de point de contrôle, non inclus.

    IMPORTANT : Ne supprimez pas le journal de point de contrôle.

    Dans cet exemple, vous pouvez supprimer tous les journaux jusqu'à E0002cc6.log.
  7. Cette étape est facultative. Vous pouvez faire appel à l'utilitaire Esefile pour vérifier l'intégrité des pages des bases de données copiées.

    Le fichier Esefile.exe est disponible dans le dossier Support sur le CD-ROM du Service Pack 3 d'Exchange Server 5.5, le CD-ROM d'installation Exchange 2000 Server ou le CD-ROM d'installation Exchange Server 2003. Vous pouvez également obtenir le fichier Esefile.exe auprès des Services de support technique Microsoft. L'utilitaire Esefile fonctionne pour les fichiers .edb d'Exchange Server 5.0 et 5.5, Exchange 2000 et Exchange 2003.

    Il n'existe actuellement aucune méthode autre que la sauvegarde en ligne pour vérifier les sommes de contrôle pour chaque page d'un fichier .stm. Le fichier .stm contient des données brutes. Tous les index et pointeurs qui organisent ces données sont dans le fichier .edb. Un problème dans le fichier .stm entraîne la perte de certaines données spécifiques du client, mais ne compromet pas l'intégrité structurelle ou logique de la base de données dans son ensemble.

    Pour vérifier les sommes de contrôle de page pour une base de données Exchange, exécutez la commande d'utilitaire Esefile suivante :
    esefile /s nom_base_de_données
    Voici un exemple de sortie de la commande précédente :
    E:\mdbdata>esefile /s priv.edb
    
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    
    esefile completes successfully after 10 seconds
    							
    Les pages non initialisées sont acceptables, mais dans une base de données sans problèmes, il y a 0 somme de contrôle incorrecte et 0 numéro de page incorrect.

    Si une base de données ne réussit pas le contrôle d'intégrité de l'utilitaire Esefile, la meilleure solution est de restaurer une sauvegarde précédente que vous savez être correcte et de restaurer par progression la base de données. Si aucune sauvegarde n'est disponible, demandez conseil au Services de support technique Microsoft en matière de réparation ou de récupération de la base de données.
  8. Cette étape est facultative. Vous pouvez utiliser la commande suivante pour vérifier l'intégrité des fichiers journaux sauvegardés :
    eseutil /ml E0n
    Voici un exemple de sortie de la commande précédente :
    k:\backups>eseutil /ml E00
    							
    Vous devez exécuter cette commande à partir d'un dossier qui contient les fichiers journaux sauvegardés. Vous pouvez également exécuter cette commande sur le dossier de journaux en cours, mais si Eseutil tente de lire l'en-tête d'E0n.log alors qu'une base de données du groupe de stockage s'exécute, vous recevez une erreur -1032 (JET_errFileAccessDenied).

    Cette commande détecte une éventuelle corruption des fichiers journaux et vous prévient si un fichier journal manque dans le milieu d'une séquence ou si une incompatibilité de signature existe entre certains fichiers journaux.
Retour à la liste des sections

Restauration d'une sauvegarde hors connexion d'une base de données Exchange

Cette section présente deux méthodes de restauration d'une sauvegarde hors connexion :
  • La restauration « dans le temps ». Aucun fichier journal n'est relu dans la base de données. Toutes les données créées après la sauvegarde sont perdues.
  • La restauration « par progression ». Les fichiers journaux créés après la sauvegarde sont lus dans la base de données. Si tous les fichiers journaux sont disponibles, toutes les données créées après la sauvegarde peuvent être conservées. Si l'enregistrement circulaire est activé, vous devez effectuer une restauration « dans le temps » de votre sauvegarde hors connexion ; vous ne pouvez pas choisir la restauration « par progression ».
Le jeu de fichiers que vous restaurez doit répondre aux critères minimums suivants :
  • Dans le cas d'une restauration dans le temps, toutes les bases de données arrêtées du groupe de stockage doivent être cohérentes et un fichier de point de contrôle valide doit exister. Ne supprimez pas le fichier de point de contrôle actuel ni aucun des fichiers journaux existants.
  • Dans le cas d'une restauration par progression, toutes les bases de données du groupe de stockage doivent être arrêtées et cohérentes. Tous les fichiers journaux créés après la sauvegarde doivent exister (y compris le fichier E0n.log en cours). Le fichier de point de contrôle doit être supprimé.
Si le jeu de fichiers ne correspond pas aux conditions précédentes, la restauration et la lecture n'échouent pas nécessairement, mais il est probable que vous receviez un message d'erreur -1216 (JET_errAttachedDatabaseMismatch) pendant la récupération logicielle.

Retour à la liste des sections

Résolution d'une erreur -1216

Des dispositifs de récupération logicielle supplémentaire dans Exchange 2000 et les versions ultérieures entraînent l'erreur -1216 lorsqu'Exchange détecte des fichiers de données qui ont été altérés manuellement et détermine que l'exécution d'une récupération avec le jeu de données actuel entraînerait la perte de données existantes.

Dans les versions antérieures d'Exchange, si le jeu de fichiers est incomplet, mais qu'il est valide pour une lecture, la récupération logicielle démarre sans en avertir l'administrateur. Dans Exchange 2000 et les versions ultérieures, l'administrateur doit ignorer spécifiquement l'erreur -1216 à l'aide d'Eseutil. Retour à la liste des sections

Restauration dans le temps d'une sauvegarde hors connexion

Pour effectuer une restauration dans le temps d'une sauvegarde hors connexion :
  1. Si la base de données à restaurer est montée, démontez-la. Si d'autres bases de données dans le groupe de stockage sont démontées, la base de données et les fichiers de transmission en continu (.edb et .stm) de ces bases de données doivent tous être cohérents et concordants. (Pour en vérifier la cohérence et la concordance, consultez l'étape 2 à la section « Sauvegarde d'une base de données Exchange en mode hors connexion » de cet article.)

    Si toutes les bases de données du groupe de stockage sont démontées, elles doivent toutes être cohérentes et un fichier de point de contrôle valide doit exister. Un fichier de point de contrôle valide est un fichier de point de contrôle qui était utilisé lors de la dernière exécution de l'une des bases de données du groupe de stockage, qui contient un en-tête qui répertorie E0n.log comme point de contrôle. Si certaines bases de données du groupe de stockage sont toujours montées, le fichier de point de contrôle valide est celui qui est utilisé par le système. Si l'une des bases de données du groupe de stockage est en cours d'exécution, un point de contrôle valide existe.

    Pour vérifier le fichier de point de contrôle lorsque toutes les bases de données sont arrêtés, exécutez les commandes suivantes :
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    Voici un exemple de sortie de l'une des commandes précédentes :
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    Dans l'exemple précédent, le point de contrôle se trouve dans le journal, avec le numéro de création (lGeneration) 0x2cc7, qui est e00.log. Par conséquent, le point de contrôle peut être considéré comme valide.

    Si le point de contrôle n'est pas valide, vous pouvez recevoir un message d'erreur -1216 (JET_errAttachedDatabaseMismatch) lorsque vous tentez de monter une base de données du groupe de stockage. Ce problème peut se produire même si toutes les bases de données du groupe de stockage sont cohérentes.
  2. Copiez les fichiers .edb et .stm sauvegardés dans la base de données et les emplacements de fichiers de transmission en continu correspondants. (Pour localiser ces emplacements, reportez-vous à la section « Avant de Commencer » de cet article.) Vérifiez que les fichiers restaurés sont cohérents et concordants.

    REMARQUE : Si les copies des fichiers de base de données à restaurer existent déjà sur le serveur, sauvegardez-les avant de restaurer la base de données, même si les fichiers existants ne peuvent pas être démarrés. En effet, il est possible qu'ils soient réparables et que vous puissiez y récupérer des données grâce à l'utilitaire Exmerge.
  3. Montez la base de données restaurée. La base de données se joint à la fin du fichier E0n.log. Une fois la base de données redémarrée, aucun fichier journal existant ne peut jamais être relu dans la base de données. Les bases de données de dossiers publics qui contiennent des milliers de dossiers dans la hiérarchie peuvent être longues à démarrer. Prévoyez au moins une minute pour chaque millier de dossiers contenu dans la hiérarchie.

    Dans les versions antérieures d'Exchange Server, vous deviez généralement exécuter la commande ISINTEG -patch après avoir restauré une sauvegarde hors connexion d'une base de données de banque d'informations, afin de la synchroniser avec l'annuaire. Lorsqu'il est nécessaire d'appliquer un correctif pour une base de données Exchange, cette application est effectuée automatiquement par le système, à moins que la base de données soit restaurée sur un serveur, un groupe de stockage ou un objet de base de données logique différent ou que l'objet Active Directory pour la base de données ait été supprimé et recréé dans Active Directory. Dans ces cas, le message d'erreur suivant est consigné dans le journal d'événements d'applications.
    Type d'événement : Erreur
    Source de l'événement : Banque de boîtes aux lettres MSExchangeIS
    Catégorie d'événement : Général
    ID de l'événement : 1087
    Date : 5/4/2001
    Heure : 20:33:42
    Utilisateur : N/A
    Ordinateur : EXCHANGE1
    Description : La banque d'informations a été restaurée à partir d'une sauvegarde hors connexion. Dans le Gestionnaire système Microsoft Exchange, indiquez que la base de données « Premier groupe de stockage\Banque d'informations privée » (First Storage Group\Private Information Store) peut être restaurée, de manière qu'un correctif puisse lui être appliqué.
    Pour résoudre ce problème, vous devez cocher la case Cette base de données peut être écrasée par une restauration dans le Gestionnaire système Exchange, dans les propriétés Database de l'objet de base de données.
Retour à la liste des sections

Restauration par progression d'une sauvegarde hors connexion

Pour de meilleures chances de succès lors de la relecture des fichiers journaux dans une base de données restaurée :
  • Conservez une copie de tous les journaux de transactions créés après la sauvegarde complète la plus ancienne.
  • Ne modifiez pas le chemin d'accès à une base de données sans effectuer de suite une nouvelle sauvegarde complète.
  • N'exécutez pas ESEUTIL /p ni ESEUTIL /d sans effectuer immédiatement après une nouvelle sauvegarde.
  • N'ajoutez pas ou ne supprimez pas de base de données dans un groupe de stockage sans effectuer immédiatement une sauvegarde complète de toutes les bases de données du groupe de stockage.
Pour démarrer le processus de restauration :
  1. Si la base de données à restaurer est montée, démontez-la, puis copiez les fichiers de la base de données à restaurer vers les chemins d'accès appropriés sur le serveur. Si les copies des fichiers de base de données à restaurer existent déjà sur le serveur, sauvegardez-les avant de restaurer la base de données, même si les fichiers existants ne peuvent pas être démarrés. Les fichiers peuvent être réparables et vous pourrez peut-être faire appel à l'utilitaire Exmerge pour y récupérer des données.
  2. Démontez toutes les bases de données du groupe de stockage, puis exécutez la commande suivante sur chaque base de données du groupe de stockage actuel, puis sur chaque fichier de base de données restauré :
    eseutil /mh nom_fichier_base_données | find /i "consistent"
    REMARQUE : Le Service Pack 2 Exchange 2000 et les versions ultérieures ne signalent pas l'état de la base de données comme étant « Consistent » (cohérent) ou « Inconsistent » (incohérent), mais comme « Clean shutdown » (arrêt normal) ou « Dirty shutdown » (arrêt intempestif). Le premier correspond à « Consistent » et le second à « Inconsistent ». Si vous possédez Exchange 2000 Service Pack 2 ou une version ultérieure, exécutez cette commande supplémentaire pour déterminer l'état de chaque base de données :
    eseutil /mh nom_base_de_données | find /i "Shutdown"
    Voici un exemple du texte de sortie de la commande précédente :
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    
    
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    L'objectif de cette commande est triple :
    • Vérifier que les fichiers de base de données sont tous cohérents.
    • Vérifier que les fichiers .edb et .stm pour chaque base de données forment une paire concordante.
    • Identifier les fichiers journaux d'ancrage inférieur et supérieur, qui sont les premiers et les derniers fichiers journaux nécessaires pour récupérer toutes les données sans générer d'erreur -1216. La dernière valeur la plus basse cohérente dans toutes les bases de données est le journal d'ancrage inférieur et la dernière valeur la plus élevée cohérente est le journal d'ancrage supérieur.
    Dans l'exemple précédent, le fichier journal d'ancrage inférieur est E0002ac8.log et le fichier journal d'ancrage supérieur est E0002cc7.log.
  3. Vérifiez que la signature de journal enregistrée dans chaque en-tête de base de données est la signature du journal d'ancrage inférieur. Exécutez les commandes suivantes :
    eseutil /mh nom_base_de_données | find /i "Log Signature"
    eseutil /ml journal_ancrage_inférieur | find /i "Signature"
    Voici un exemple de sortie de la commande précédente :
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:06:40:00 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:06:41:00 Rand:58314 Computer:
    							
    Un fichier journal peut contenir plusieurs signatures. La première signature est toujours la signature du fichier journal ; les autres correspondent à des bases de données qui s'exécutaient au moment de la création du fichier journal. Dans l'exemple précédent, les signatures de journaux enregistrées dans les fichiers de base de données correspondent à la signature du journal d'ancrage inférieur.

    Si vous ne trouvez pas le journal d'ancrage inférieur, vous ne pouvez pas lire les journaux pour effectuer une reprise dans cette base de données. Si vous ne trouvez pas le fichier journal d'ancrage inférieur, vous ne pouvez relire de fichiers journaux dans aucune base de données. Il existe deux méthodes que vous pouvez utiliser pour contourner l'absence de journal d'ancrage inférieur :
    • Vous pouvez supprimer tous les fichiers journaux. Les bases de données étant toutes cohérentes, vous pouvez les démarrer sans qu'aucun fichier journal ne soit présent, mais vous perdez toute chance de récupérer les données qui ne sont pas déjà dans les fichiers de base de données.
    • Vous pouvez supprimer les bases de données dotées des dernières valeurs cohérentes les plus basses, jusqu'à ce que vous puissiez créer une série continue de journaux d'ancrage inférieur à supérieur, puis exécuter la récupération sur les bases de données restantes. Lorsque vous remettez les bases de données supprimées dans le groupe de stockage, vous ne pouvez pas y relire de données supplémentaires.
  4. Vérifiez que les emplacements de chemin d'accès aux bases de données en cours sont les mêmes que lorsque vous avez effectué la sauvegarde.

    Bien que vous puissiez modifier le chemin d'accès au journal des transactions ou le chemin d'accès actif après avoir effectué une sauvegarde, vous pouvez relire le fichier journal uniquement si les fichiers de base de données se trouvent dans l'emplacement dans lequel ils ont été sauvegardés. Si vous n'êtes pas sûr des emplacements d'origine, exécutez la commande suivante :
    eseutil /ml journal_"Last_Consistent" | find /i "nom de la base de données ou du modèle"
    Voici un exemple de sortie de la commande précédente :
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    REMARQUE : Si le journal d'ancrage inférieur est E0n00001.log, son en-tête ne contient pas d'informations relatives au chemin d'accès, car l'en-tête du premier journal d'une série est créé avant que la première base de données soit jointe au journal. Dans ce cas, vous devez consulter dans l'en-tête du journal suivant les informations de chemin d'accès à la base de données. Dans de rares cas, cela peut arriver aussi pour des journaux autres que le premier, car une base de données a été créée ou jointe à la transmission en continu du journal après la création du journal.
  5. Rassemblez tous les journaux, à partir du numéro d'ancrage inférieur le plus loin possible dans une séquence ininterrompue et copiez ces journaux vers le chemin d'accès des journaux de transactions en cours. Ne remplacez pas les journaux qui sont déjà en place sur le serveur sans les sauvegarder au préalable. Pour ce faire, vous devrez peut-être restaurer les fichiers journaux à partir de plusieurs types de support de sauvegarde.

    Dans l'exemple précédent, l'ancrage inférieur est E0002ac8.log et l'ancrage supérieur E0002cc7.log. Lorsque vous examinez les journaux disponibles, le journal au numéro le plus élevé peut être un numéro au-dessous du numéro nécessaire (par exemple, E0002cc6.log, au lieu de 2cc7). Cela est généralement dû au fait que E0n.log n'a pas encore été rempli et renommé à son numéro dans la séquence. Pour déterminer si E0n.log est bien le journal d'ancrage supérieur, vous devez utiliser la commande suivante pour examiner la valeur lGeneration dans l'en-tête du fichier journal :
    eseutil /ml E0n.log | find /i "lGeneration"
    Voici un exemple de sortie de la commande précédente :
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    REMARQUE : Pour consulter l'en-tête d'un fichier journal grâce à l'utilitaire Eseutil, utilisez le commutateur /ml ; pour consulter un en-tête de fichier de base de données, utilisez le commutateur /mh. Si vous confondez les commutateurs, la sortie des commandes est inexacte.

    En général, le journal d'ancrage supérieur est également le plus élevé des journaux disponibles, sauf si :
    • Les fichiers journaux ont été détruits lors d'un incident grave.

      - ou -
    • Vous restaurez toutes les bases de données d'un groupe de stockage en même temps.
    Dans le premier cas, vous êtes susceptible de rencontrer des erreurs -1216 pendant la récupération ; dans le second cas, vous pouvez lire les fichiers journaux, même au-delà du journal d'ancrage supérieur, tant qu'ils continuent la séquence de lGeneration.
  6. Vérifiez que tous les journaux partagent la même signature de journal et forment une séquence continue. Exécutez la commande suivante :
    eseutil /ml E0n > filename.txt
    Voici un exemple de sortie de la commande précédente :
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    
    d:\mdbdata>type logverify.txt
    
    Microsoft (R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.
    
    Initiating FILE DUMP mode...
    
    Verifying log files...
          Base name: e00
    
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    
    No damaged log files were found.
    
    Operation completed successfully in 3.305 seconds.
    							
    Cette commande Eseutil fait trois choses : elle vérifie chaque fichier journal pour déterminer s'il a été endommagé, elle signale tout écart dans la séquence du fichier journal et elle détecte d'éventuelles incohérences dans la signature de journal.

    Toutes les signatures de journal doivent correspondre dans tous les fichiers journaux susceptibles d'être utilisés pour la relecture. Vous devez supprimer tous les journaux qui n'ont pas de signature concordante avant le début de la lecture.

    À ce stade, après avoir supprimé les fichiers qui n'ont pas réussi les tests de vérification, les seuls fichiers de journaux de transactions qui se trouvent dans le dossier de journaux de transactions sont des fichiers qui :
    • forment une séquence continue de lGeneration, du fichier journal d'ancrage inférieur au moins jusqu'au fichier d'ancrage supérieur et au-delà, si possible ;
    • ont des signatures de journal concordantes.
  7. Si le journal d'ancrage supérieur ne porte pas encore le nom E0n.log, renommez-le.
  8. Supprimez le fichier E0n.chk du dossier du chemin d'accès système.

    En l'absence d'un fichier de point de contrôle, Exchange Server commence à relire les journaux à partir du fichier journal au numéro le plus bas dans le dossier des journaux de transactions : le journal d'ancrage inférieur. Si le fichier E0n.chk existe, Exchange Server commence la lecture au point de contrôle qui est enregistré dans ce fichier. Si E0n.chk pointe au-delà du journal d'ancrage inférieur, la relecture échoue entièrement pour le jeu de fichiers restaurés. Dans de nombreux cas, si vous faites une erreur au niveau du fichier de point de contrôle, vous devez recommencer l'opération après avoir restauré les fichiers de base de données à partir de la sauvegarde.
  9. À titre de dernier contrôle avant de monter le groupe de stockage, vérifiez que :
    • Tous les fichiers de base de données sont présents dans leurs chemins d'accès actifs.
    • Les seuls fichiers journaux dans le chemin d'accès au journal des transactions actif sont des fichiers qui commencent au journal d'ancrage inférieur et continuent au moins jusqu'au journal d'ancrage supérieur, le journal disponible le plus élevé étant nommé E0n.log.
    • Il n'y a aucun fichier E0n.chk dans le dossier du chemin d'accès système.
    Vous devriez maintenant parvenir à monter le groupe de stockage et à commencer à relire des journaux de transactions avec ce jeu de fichiers. Même une fois la récupération terminée et la base de données démarrée, toutes les données dans tous les fichiers journaux peuvent ne pas être récupérées véritablement à cause de problèmes liés à la signature DB et au chemin d'accès pendant la relecture. La section « Résolution des incompatibilités entre signature de base de données et chemin d'accès » propose des informations complémentaires relatives à ces problèmes.
  10. Si la banque d'informations n'est pas déjà en cours d'exécution, démarrez-la, puis montez au moins une base de données dans le groupe de stockage. Cela entraîne l'exécution de la récupération logicielle sur toutes les bases de données du groupe de stockage.

    Dans les versions antérieures d'Exchange Server, vous deviez généralement exécuter la commande ISINTEG -patch après avoir restauré une sauvegarde hors connexion d'une base de données de banque d'informations, afin de la synchroniser avec l'annuaire. Lorsqu'il est nécessaire d'appliquer un correctif pour une base de données Exchange, cette application est effectuée automatiquement par le système, à moins que la base de données soit restaurée sur un serveur, un groupe de stockage ou un objet de base de données logique différent ou que l'objet Active Directory pour la base de données ait été supprimé et recréé dans Active Directory. Dans ces cas, le message d'erreur suivant est consigné dans le journal d'événements d'applications.
    Type d'événement : Erreur
    Source de l'événement : Banque de boîtes aux lettres MSExchangeIS
    Catégorie d'événement : Général
    ID de l'événement : 1087
    Date : 5/4/2001
    Heure : 20:33:42
    Utilisateur : N/A
    Ordinateur : EXCHANGE1
    Description : La banque d'informations a été restaurée à partir d'une sauvegarde hors connexion. Dans le Gestionnaire système Microsoft Exchange, indiquez que la base de données « Premier groupe de stockage\Banque d'informations privée » (First Storage Group\Private Information Store) peut être restaurée, de manière qu'un correctif puisse lui être appliqué.
    Pour résoudre ce problème, vous devez cocher la case Cette base de données peut être écrasée par une restauration dans le Gestionnaire système Exchange, dans les propriétés Database de l'objet de base de données.
Vérifiez si le journal d'événements d'applications dans l'Observateur d'événements Microsoft Windows NT contient des erreurs ou anomalies qui peuvent se produire lors du démarrage de la base de données. Un événement 301 s'affiche pour chaque fichier journal qui est relu. Soyez attentif aux éventuelles erreurs et avertissements pendant le processus de récupération.

Retour à la liste des sections

Résolution des incompatibilités entre signature de base de données et chemin d'accès

Les bases de données, tout comme les fichiers journaux, possèdent leurs propres signatures. Mais bien que les signatures de journal ne changent pas après la création du fichier E0n000001.log, les signatures de base de données changent à chaque fois que la topologie physique de la base de données est modifiée, sans que les modifications soient suivies dans les fichiers journaux. La défragmentation hors ligne ou la réparation d'une base de données à l'aide d'Eseutil modifie la signature DB. Après un tel événement, la base de données peut être jointe au même journal de transmission en continu qu'avant, mais elle n'accepte pas la relecture des transactions qui ont été effectuées lorsque la base de données avait sa signature précédente. Une copie précédente de la base de données n'accepte pas la relecture de transactions effectuées après modification de la signature de la base de données.

Étant donné cette réinitialisation des signatures de base de données, Microsoft vous conseille vivement de faire des sauvegardes complètes de la base de données immédiatement après la défragmentation ou la réparation hors connexion d'une base de données. Si vous restaurez plus tard une copie de la base de données avec la signature ancienne, la lecture réussit jusqu'au moment de la modification de signature, mais vous perdez tous les changements effectués au-delà.

Si les chemins d'accès à la base de données sont modifiés au milieu d'une transmission en continu de journal, l'effet est semblable à celui de la modification de signatures : la relecture est interrompue au point de changement. (L'API de sauvegarde en ligne fournit une fonctionnalité destinée au remappage des chemins d'accès pendant la récupération ; par conséquent, l'API de sauvegarde en ligne peut relire le journal dans son intégralité, même si un chemin d'accès a été modifié depuis que la sauvegarde a été effectuée.)

Si des problèmes de signature DB ou de chemins d'accès BDD sont rencontrés pendant la lecture, ils sont signalés dans le journal d'événements d'application en ligne avec les événements 301 de relecture pour chaque fichier journal. La relecture des fichiers journaux se trouvant après le point posant problème peut sembler réussie, mais c'est seulement parce qu'un même avertissement de non-concordance n'est enregistré qu'une seule fois. En règle générale, la relecture dans une base de données particulière est tronquée à partir du point où la première signature DB ou l'erreur de chemin d'accès référençant cette base de données se trouve.

Retour à la liste des sections

Propriétés

Numéro d'article: 296788 - Dernière mise à jour: lundi 3 décembre 2007 - Version: 4.4
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Mots-clés : 
kberrmsg kbhowto kbproductlink KB296788
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com