Mode Récupération Eseutil /R

Article
10/25/2013

Dernière rubrique modifiée : 2006-06-09

Le terme récupération désigne la lecture de fichiers journaux de transactions dans une base de données. Il existe deux types de récupération :

Récupération matérielle : processus de relecture des journaux de transactions consécutif à la restauration d'une base de données à partir d'une sauvegarde en ligne.
Récupération logicielle : processus de relecture des journaux de transactions qui se produit lorsqu'une base de données est remontée après un arrêt inattendu ou processus de relecture des journaux de transactions dans une copie de sauvegarde hors connexion d'une base de données.

Pour plus d'informations sur les récupérations matérielles et logicielles, voir le document sur la relecture des fichiers journaux de transactions et la récupération logicielle et matérielle dans Exchange Server 2003 (https://go.microsoft.com/fwlink/?linkid=68147).

Pour plus d'informations sur les instructions d'exécution d'Eseutil en mode Récupération, voir la rubrique sur la procédure d'Procédure d'exécution d'Eseutil /R en mode Récupération.

Récupération matérielle

La récupération matérielle a lieu lorsque les fichiers journaux de transactions doivent être relus dans une sauvegarde en ligne restaurée. Dans tous les autres scénarios de récupération, c'est une récupération logicielle qui est effectuée. La récupération matérielle peut être effectuée à l'aide d'Eseutil en mode Restauration (/C).

Récupération logicielle

Dans le scénario de la récupération logicielle par défaut, un événement externe entraîne l'arrêt imprévu d'une base de données Exchange, mais la base de données et les fichiers journaux sont conservés et intacts. Lors du remontage de la base de données, Exchange lit le fichier de point de contrôle et commence à relire le journal de transactions indiqué comme journal de point de contrôle. S'il n'existe aucun fichier de point de contrôle, la relecture commence par le plus ancien des fichiers journaux disponibles dans le dossier des journaux de transactions du groupe de stockage.

Exchange écrit dans la base de données les transactions terminées qu'il trouve dans le fichier journal et qui n'ont pas encore été écrites et annule les transactions incomplètes. Exchange ne commence jamais à écrire une transaction dans les fichiers de base de données avant que toutes les opérations qui le composent n'aient été inscrites dans les fichiers journaux. Vous ne devez pas annuler physiquement une transaction de la base de données si tous les journaux de transactions non validés présents au moment de l'arrêt imprévu sont présents lors de la relecture.

Important :
Un des principes fondamentaux du processus de récupération logicielle est qu'aucune base de données ni aucun fichier journal ne doit avoir été déplacé, supprimé ou détruit par la panne ou par l'administrateur après la panne.

Différences entre les versions

Eseutil est continuellement amélioré et de nouvelles fonctions lui sont ajoutées version après version. Il existe actuellement trois grandes versions d'Eseutil /R, correspondant aux 3 grandes versions d'Exchange :

Exchange Server version 5.5
Exchange 2000 Server
Exchange Server 2003

Exchange Server 5.5

La syntaxe de la ligne de commande pour la récupération logicielle à l'aide d'Eseutil dans Microsoft® Exchange 2000 Server et Microsoft® Exchange Server 2003 est différente de celle utilisée dans Exchange 5.5. Les règles et méthodes conseillées pour l'exécution de la récupération logicielle à l'aide d'Eseutil ont également été modifiées.

Dans Exchange 5.5, il n'existe presque aucune bonne raison d'effectuer une récupération logicielle à l'aide d'Eseutil. À chaque démarrage de la banque d'informations, la récupération logicielle est exécutée automatiquement et correctement. Dans Exchange 5.5, la fonction de récupération logicielle d'Eseutil était principalement destinée aux environnements de test, dans lesquels il pouvait s'avérer désirable de récupérer une base de données sur un serveur non équipé d'Exchange.
L'exécution d'Eseutil /R dans Exchange 5.5 comporte un risque majeur : après la restauration d'une sauvegarde en ligne, l'exécution de la récupération logicielle corrompt généralement la base de données. Une sauvegarde en ligne nécessite une récupération matérielle et non une récupération logicielle.

Dans Exchange 5.5 ou antérieur, la récupération logicielle ne doit être utilisée à la place de la récupération matérielle que si les deux conditions suivantes sont réunies :

Les chemins d'accès aux bases de données n'ont pas été modifiés depuis la sauvegarde.
La taille des fichiers .pat de la sauvegarde en ligne est de 8 Ko exactement (c'est-à-dire qu'ils ne sont composés que de deux pages d'en-tête et ne contiennent aucune page de bases de données).
Dans tous les autres cas, l'exécution de la récupération logicielle au lieu de la récupération matérielle endommagera la base de données dans une mesure proportionnelle à la taille des fichiers .pat.

Remarque :
Pour connaître le nombre de pages qui seront endommagées à la suite de l'éxécution incorrecte de la récupération logicielle, divisez la taille en octets d'un fichier .pat par 4096 et soustrayez 2.

Exchange 2000 Server

Dans Exchange 2000, des mesures de prévention ont été mises en place afin de toujours éviter l'exécution de la récupération logicielle lorsque la récupération matérielle est requise.

Il existe un autre risque inhérent à l'exécution de la récupération logicielle à l'aide d'Eseutil. Ce risque subsiste dans Exchange 2000 et Exchange 2003 : si les chemins d'accès aux fichiers journaux, aux fichiers de point de contrôle ou aux fichiers de base de données sont incorrects, la récupération peut modifier les fichiers de base de données ou les fichiers journaux et empêcher l'exécution ultérieure de la récupération.

Si Eseutil ne trouve pas les journaux de transactions existants lorsqu'il tente d'exécuter la récupération, il créera une nouveau fichier journal de transactions et tentera d'y attacher la base de données. Si la base de données est dans l'état Incohérent ou Arrêt brutal, il sera impossible de la lancer. Si la base de données est dans l'état Cohérent, elle sera attachée au nouveau fichier journal puis détachée de celui-ci.

Dans les deux cas, vous risquez d'apporter des modifications à la base de données ou d'ajouter au serveur des fichiers journaux qui rendront impossible le lancement de la base de données ou qui compliqueront la résolution des problèmes de récupération.

Remarque :
Le simple fait qu'Eseutil indique que la récupération a été effectuée avec succès ne signifie pas que la base de données peut être montée. La récupération est considérée comme ayant été effectuée avec succès dès lors que toutes les données du journal des transactions ont été appliquées aux fichiers de base de données. La réussite de la récupération n'indique pas si les données disponibles ont permis de restaurer la cohérence des bases de données.

Le simple fait qu'Eseutil indique que la récupération a été effectuée avec succès ne signifie pas que la base de données peut être montée. La récupération est considérée comme ayant été effectuée avec succès dès lors que toutes les données du journal des transactions ont été appliquées aux fichiers de base de données. La réussite de la récupération n'indique pas si les données disponibles ont permis de restaurer la cohérence des bases de données.

Pour obtenir une récupération satisfaisante dans Exchange 5.5, il était pratiquement toujours préférable de placer les fichiers au bon endroit puis de démarrer la banque d'informations. Dans Exchange 2003, deux améliorations ont été apportées à la fonction de récupération d'Eseutil et offrent des avantages appréciables au montage d'une base de données et à l'exécution de la récupération de celle-ci :

Eseutil peut forcer la récupération à s'exécuter même lorsqu'il manque une base de données. Cette fonctionnalité est également disponible dans Exchange 2000.
Si un groupe de stockage subit un arrêt imprévu, toutes les bases de données ouvertes au moment de l'arrêt seront en l'état Incohérent ou Arrêt brutal. Supposons que le groupe de stockage s'est arrêté parce qu'un lecteur de base de données est tombé en panne et est de ce fait devenu inaccessible. Dans ce cas, une base de données est manquante.

Si la récupération est exécutée alors que cette base de données est manquante, il est possible que l'état des journaux de transactions soit modifié de telle manière que, si le lecteur de base de données redevient accessible, la récupération ne s'exécutera pas avec succès pour cette base de données.

Remarque :
Si vous restaurez la base de données depuis une sauvegarde, la récupération pourra s'exécuter avec succès (ce scénario ne s'applique qu'à la récupération d'une base de données attachée au journal actuel au moment de l'arrêt imprévu).

Si vous savez que la base de données perdue ne sera pas récupérée, vous pouvez récupérer les autres bases de données du groupe de stockage sans restaurer préalablement la base de données manquante depuis une sauvegarde à l'aide du commutateur Eseutil /I (ignorer).

Avant d'employer ce commutateur pour récupérer le reste du groupe de stockage, veillez à effectuer une sauvegarde de tous les fichiers journaux de transaction, y compris le journal en cours (Enn.log). Cette copie du journal en cours et de tous les autres journaux vous permettra de récupérer la base de données manquante si elle redevenait accessible. Une fois que vous avez récupéré les autres bases de données et donc écrit des informations supplémentaires dans le journal Enn.log, vous ne serez en effet plus en mesure de récupérer la base de données manquante à l'aide de ce fichier.

Exchange Server 2003

Le mode Récupération d'Eseutil peut récupérer une base de données dont le chemin d'accès a été modifié. Cette fonctionnalité est uniquement disponible dans Exchange 2003.

La récupération matérielle peut toujours être exécutée avec succès, même si les bases de données Exchange ont été déplacées depuis la sauvegarde. Toutefois, dans Exchange 2003, la récupération logicielle ne pouvait fonctionner que si les chemins d'accès aux fichiers de la base de données étaient identiques à ceux définis dans les journaux de transactions devant être relus.

Dans Exchange 2003, le commutateur /D a été ajouté au mode Récupération afin de pouvoir passer outre le chemin d'accès à la base de données indiqué dans les fichiers journaux de transactions. Cette nouvelle fonctionnalité est très utile lors de la restauration de copies hors connexion de bases de données dans des groupes de stockage de récupération ou lors de la récupération d'une base de données « manquante », comme dans le scénario mentionné ci-dessus.

Il est maintenant possible de copier une base de données et un groupe de journaux de transactions dans n'importe quel dossier et d'exécuter avec succès une récupération logicielle. Dès lors que la base de données est cohérente, il est possible de la placer où vous le désirez et de l'attacher à un flux de journal différent.

Pour plus d'informations

Pour plus d'informations, voir les rubriques suivantes du Guide de l'Utilitaire de base de données d'Exchange Server :

Partager via