Gérer les copies de la base de données de boîtes aux lettres

Article
04/04/2023

Dans Exchange Server, vous pouvez utiliser le console de gestion Exchange (EAC) ou l’environnement de ligne de commande Exchange Management Shell pour ajouter des copies de base de données de boîtes aux lettres une fois qu’un groupe de disponibilité de base de données (DAG) a été créé, configuré et rempli avec les membres du serveur de boîtes aux lettres.

Gestion des copies de base de données

Une fois que plusieurs copies d'une base de données ont été créées, vous pouvez utiliser le CAE ou l'Environnement de ligne de commande Exchange Management Shell pour contrôler l'intégrité et l'état de chaque copie, et effectuer les autres tâches de gestion associées aux copies de bases de données. Par exemple, vous pourrez être amené à interrompre ou reprendre la copie d'une base de données, amorcer la copie d'une base de données, contrôler les copies de base de données, configurer les paramètres de copie de base de données ou supprimer une copie de base de données.

Interruption et reprise des copies de base de données

Vous pouvez être amené à interrompre et à reprendre la réplication continue de la copie d’une base de données pour plusieurs raisons, notamment pour effectuer une opération de maintenance planifiée. De plus, certaines tâches administratives, comme l'amorçage, nécessitent d'interrompre la copie d'une base de données. Nous vous recommandons de suspendre toute activité de réplication en cas de modification du chemin ou des fichiers journaux de la base de données. Vous pouvez interrompre et reprendre l'activité de copie de base de données à l'aide du CAE ou en exécutant les cmdlets Suspend-MailboxDatabaseCopy et Resume-MailboxDatabaseCopy dans l'Environnement de ligne de commande Exchange Management Shell. Pour savoir en détail comment interrompre ou reprendre l'activité de réplication continue d'une copie de base de données, consultez la rubrique Interruption ou reprise d'une copie de base de données de boîtes aux lettres.

Amorçage d’une copie de base de données

L’amorçage, ou mise à jour, est le processus au cours duquel une base de données vide ou la copie d’une base de données de production est ajoutée à l’emplacement de copie cible sur un autre serveur de boîtes aux lettres dans le même groupe de disponibilité de base de données que la base de données active. Ainsi, elle devient la base de données de base pour la copie gérée par ce serveur.

Selon la situation, vous pouvez amorcer une base de données automatiquement ou manuellement. Quand une copie de base de données est ajoutée, la copie est automatiquement amorcée si le serveur cible et son stockage sont correctement configurés. Si vous souhaitez amorcer manuellement une copie de base de données et ne souhaitez pas que l’amorçage automatique se produise lors de la création de la copie, vous pouvez utiliser le paramètre SeedingPostponed lors de l’exécution de l’applet de commande Add-MailboxDatabaseCopy .

Les copies de base de données doivent rarement être réemployées après l’amorçage initial. Toutefois, si une nouvelle installation est nécessaire ou si vous souhaitez amorcer manuellement une copie de base de données au lieu que le système amorce automatiquement la copie, vous avez deux options. Vous pouvez réinsérer une base de données à l’aide de l’Assistant Mise à jour de la copie de base de données de boîtes aux lettres dans le CENTRE d’administration Exchange ou à l’aide de l’applet de commande Update-MailboxDatabaseCopy dans Exchange Management Shell. Avant d’amorcer une copie de base de données, vous devez d’abord suspendre la copie de la base de données de boîtes aux lettres. Pour obtenir des instructions détaillées sur la façon d’amorcer une copie de base de données, consultez Mettre à jour une copie de base de données de boîtes aux lettres.

Après une opération d'amorçage manuel, la réplication de la copie de base de données de boîtes aux lettres amorcée reprend automatiquement. Si vous ne souhaitez pas que la réplication reprenne automatiquement, utilisez le paramètre ManualResume lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Choix des éléments à amorcer

Durant un amorçage, vous pouvez choisir d'amorcer la copie de la base de données de boîtes aux lettres, son catalogue d'index de contenu ou les deux. Par défaut, l'Assistant Mise à jour de la copie de base de données de boîtes aux lettres et la cmdlet Update-MailboxDatabaseCopy amorcent la copie de la base de données de boîtes aux lettres et la copie du catalogue d'index de contenu. Pour amorcer uniquement la copie de la base de données de boîtes aux lettres sans amorcer le catalogue d’index de contenu, utilisez le paramètre DatabaseOnly lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy . Pour amorcer le catalogue d’index de contenu uniquement, utilisez le paramètre CatalogOnly pendant l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Sélection de la source d’amorçage

Toute copie de base de données en bon état peut être utilisée comme source d’amorçage pour une copie supplémentaire de cette base de données. Cela s'avère particulièrement utile quand un groupe de disponibilité de base de données a été étendu sur plusieurs emplacements physiques. Par exemple, imaginez le déploiement d'un groupe de disponibilité de base de données de quatre membres, dont deux membres (MBX1 et MBX2) sont situés à Portland dans l'Oregon et deux membres (MBX3 et MBX4) sont situés à New York. Une base de données de boîtes aux lettres appelée DB1 est active sur MBX1 et des copies passives de DB1 se trouvent sur MBX2 et MBX3. Lorsque vous ajoutez une copie de DB1 à MBX4, vous avez la possibilité d'utiliser la copie sur MBX3 comme source pour l'amorçage. Ce faisant, vous évitez l'amorçage sur le réseau étendu (WAN) qui relie Portland à New York.

Pour utiliser une copie spécifique comme source d'amorçage quand vous ajoutez une nouvelle copie de base de données, procédez comme suit :

Utilisez le paramètre SeedingPostponed lors de l’exécution de l’applet de commande Add-MailboxDatabaseCopy pour ajouter la copie de base de données. Si vous n’utilisez pas le paramètre SeedingPostponed , la copie de base de données est explicitement amorcée à l’aide de la copie active de la base de données comme source.
Vous pouvez spécifier le serveur source que vous souhaitez utiliser dans le cadre de l’Assistant Mise à jour de la base de données de boîte aux lettres dans le CENTRE d’administration Exchange, ou vous pouvez utiliser le paramètre SourceServer lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy pour spécifier le serveur source souhaité pour l’amorçage. Dans l'exemple précédent, vous indiqueriez MBX3 comme serveur source. Si vous n’utilisez pas le paramètre SourceServer, la copie de base de données sera explicitement amorcée à partir de la copie active de la base de données.

Amorçage et réseaux

En plus de choisir un serveur source spécifique pour l'amorçage d'une copie de base de données de boîtes aux lettres, vous pouvez aussi utiliser l'Environnement de ligne de commande Exchange Management Shell pour indiquer les réseaux DAG à utiliser. Vous pouvez également remplacer les paramètres de compression et de chiffrement du réseau DAG pendant l'opération d'amorçage.

Vous pouvez spécifier les réseaux que vous souhaitez utiliser pour l’amorçage à l’aide du paramètre Network lors de l’exécution de l’applet de commande Update-MailboxDatabaseCopy et spécifier les réseaux DAG que vous souhaitez utiliser. Si vous n’utilisez pas le paramètre Network , le système utilise le comportement par défaut suivant pour sélectionner un réseau à utiliser pour l’opération d’amorçage :

Si le serveur source et le serveur cible sont sur le même sous-réseau et qu'un réseau de réplication a été configuré incluant le sous-réseau, le réseau de réplication sera utilisé.
Si le serveur source et le serveur cible sont sur différents sous-réseaux, même si un réseau de réplication contenant ces sous-réseaux a été configuré, le réseau client (MAPI) sera utilisé pour l'amorçage.
Si le serveur source et le serveur cible se trouvent dans des centres de données différents, le réseau client (MAPI) sera utilisé pour l'amorçage.

Au niveau du groupe de disponibilité de base de données (DAG), les réseaux DAG sont configurés pour le chiffrement et la compression. Les paramètres par défaut utilisent le chiffrement et la compression uniquement pour les communications sur des sous-réseaux différents. Si la source et la cible sont sur différents sous-réseaux et que le DAG est configuré avec les valeurs par défaut pour NetworkCompression et NetworkEncryption, vous pouvez remplacer ces valeurs en utilisant les paramètres NetworkCompressionOverride et NetworkEncryptionOverride, respectivement, pendant l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Processus d’amorçage

Quand vous lancez le processus d'amorçage à l'aide de la cmdlet Add-MailboxDatabaseCopy ou Update-MailboxDatabaseCopy, les tâches suivantes sont effectuées :

Les propriétés de base de données d’Active Directory sont lues pour valider la base de données et les serveurs spécifiés, et pour vérifier que les serveurs source et cible s’exécutent Exchange Server, ils sont tous les deux membres du même DAG et que la base de données spécifiée n’est pas une base de données de récupération. Les chemins d'accès aux fichiers de base de données sont également lus.
Il y a une préparation aux contrôles de réamorçage à partir du service de réplication Microsoft Exchange sur le serveur cible.
Le service de réplication Microsoft Exchange du serveur cible contrôle la présence de fichiers journaux des bases de données et des transactions dans le répertoire de fichiers lu lors des contrôles Active Directory à l'étape 1.
Le service de réplication Microsoft Exchange renvoie les informations sur l'état du serveur cible à l'interface d'administration à partir de l'emplacement d'exécution de la cmdlet.
Si tous les contrôles préliminaires ont été effectués avec succès, vous serez invité à confirmer l'opération avant de continuer. Si vous confirmez l'opération, le processus se poursuit. Si une erreur se produit lors des contrôles préliminaires, elle est signalée et l'opération échoue.
L'opération d'amorçage est lancée à partir du service de réplication Microsoft Exchange sur le serveur cible.
Le service de réplication Microsoft Exchange suspend la réplication de base de données de la copie de base de données active.
Les informations sur l'état de la base de données sont mises à jour par le service de réplication Microsoft Exchange pour rendre compte de l'état de l'amorçage.
Si le serveur cible ne contient pas déjà les répertoires pour les fichiers journaux et de base de données cibles, ils sont alors créés.
Une demande d'amorçage de la base de données est transmise du service de réplication Microsoft Exchange du serveur cible au service de réplication Microsoft Exchange du serveur source à l'aide du protocole TCP. Cette demande et les communications qui suivent pour l'amorçage de la base de données ont lieu sur un réseau DAG qui a été configuré comme réseau de réplication.
Le service de réplication Microsoft Exchange du serveur source lance une sauvegarde en continu ESE (Extensible Storage Engine) via l'interface du service de banque d'informations Microsoft Exchange.
Le service de banque d'informations Microsoft Exchange transmet les données de la base de données au service de réplication Microsoft Exchange.
Les données de la base sont transférées du service de réplication Microsoft Exchange du serveur source au service de réplication Microsoft Exchange du serveur cible.
Le service de réplication Microsoft Exchange sur le serveur cible écrit la copie de la base de données dans un répertoire temporaire situé dans le répertoire de base de données principal appelé amorçage temporaire.
L'opération de sauvegarde en continu sur le serveur source se termine à la fin de la base de données.
L'écriture sur le serveur cible se termine et la base de données est déplacée du répertoire temp-seeding à l'emplacement final. Le répertoire temp-seeding est supprimé.
Sur le serveur cible, le service de réplication Microsoft Exchange traite la demande et la communique au service de recherche Microsoft Exchange pour monter le catalogue d'index de contenu de la copie de base de données, s'il existe. S'il y a des fichiers du catalogue qui n'ont pas été mis à jour depuis la fois précédente sur la copie de base de données, l'opération de montage échoue, ce qui entraîne la nécessité de répliquer le catalogue du serveur source. De la même manière, si le catalogue n'existe pas et qu'il n'existe pas sur un nouvel exemplaire de la copie de base de données du serveur cible, il faut une copie du catalogue. Le service de réplication Microsoft Exchange dirige le service de recherche Microsoft Exchange pour qu'il interrompe l'indexation de la copie de base de données pendant qu'un nouveau catalogue est copié à partir de la source.
Le service de réplication Microsoft Exchange du serveur cible envoie alors une demande d'amorçage du catalogue au service de réplication Microsoft Exchange du serveur source.
Sur le serveur source, le service de réplication Microsoft Exchange demande les informations de répertoire du service de recherche Microsoft Exchange et demande la suspension de l'indexation.
Le service de recherche Microsoft Exchange du serveur source renvoie les informations du répertoire du catalogue de recherche au service de réplication Microsoft Exchange.
Le service de réplication Microsoft Exchange du serveur source lit les fichiers de catalogue du répertoire.
Le service de réplication Microsoft Exchange du serveur source déplace les données de catalogue vers le service de réplication Microsoft Exchange du serveur cible à l'aide d'une connexion sur le réseau de réplication. Une fois la lecture finie, le service de réplication Microsoft Exchange envoie une demande au service de recherche Microsoft Exchange pour qu'il reprenne l'indexation de la base de données source.
Si des fichiers de catalogue existent déjà sur le serveur cible du répertoire, le service de réplication Microsoft Exchange sur le serveur cible les supprime.
Le service de réplication Microsoft Exchange sur le serveur cible écrit les données du catalogue dans un répertoire temporaire appelé CiSeed.Temp jusqu’à ce que les données soient complètement transférées.
Le service de réplication Microsoft Exchange déplace les données de catalogue complètes vers l'emplacement final.
Le service de réplication Microsoft Exchange du serveur cible reprend l'indexation de recherche sur la base de données cible.
Le service de réplication Microsoft Exchange du serveur cible renvoie un état d'exécution.
Le résultat final de l'opération est transmis à l'interface d'administration à partir de laquelle la cmdlet a été exécutée.

Configuration de copies de base de données

Après la création d’une copie de base de données, vous pouvez afficher et modifier ses paramètres de configuration, si nécessaire. Vous pouvez afficher certaines informations de configuration sur la page Propriétés d'une copie de base de données dans le CAE. Vous pouvez aussi utiliser les cmdlets Get-MailboxDatabase et Set-MailboxDatabaseCopy dans l'Environnement de ligne de commande Exchange Management Shell pour afficher et configurer les paramètres de copie de base de données, tels que le décalage de relecture, le décalage de troncation et l'ordre de préférence d'activation. Pour savoir en détail comment afficher et configurer les paramètres de copie de base de données, consultez la rubrique Configurer les propriétés des copies de la base de données de boîtes aux lettres.

Utilisation des options de délai d’attente de relecture et de troncation

Les copies de base de données de boîtes aux lettres prennent en charge l’utilisation d’un délai d’attente de relecture et d’un délai d’attente de troncation ; les deux sont définis en minutes. Le paramétrage d’un délai d’attente de relecture vous permet de renvoyer la copie de base de données à un certain moment dans le temps. Le paramétrage d'un délai d'attente de troncation vous permet d'utiliser les fichiers journaux sur une copie passive de base de données à récupérer après la perte de fichiers journaux sur la copie active de base de données. Parce que ces deux fonctionnalités entraînent l’accumulation temporaire des fichiers journaux, leur utilisation aura des répercussions sur votre conception de stockage.

Délai d’attente de relecture

Le décalage de relecture est une propriété de la copie de base de données de boîtes aux lettres qui indique la durée, en minutes, du retard de relecture du journal de la copie de base de données. Le minuteur de décalage de relecture se déclenche quand un fichier journal est répliqué dans la copie passive et passe l'inspection avec succès. En retardant la relecture des journaux de la copie de base de données, vous pouvez récupérer la base de données à un certain moment dans le temps passé. Une copie de base de données de boîtes aux lettres configurée avec un décalage de relecture supérieur à 0 s’appelle une copie retardée de base de données de boîtes aux lettres ou simplement une copie retardée.

Une stratégie qui utilise des copies de base de données et les fonctionnalités de conservation pour litige dans Exchange Server peut fournir une protection contre toute une série de défaillances qui entraîneraient généralement une perte de données. Toutefois, ces fonctionnalités ne peuvent pas fournir de protection contre la perte de données en cas d'altération logique qui, bien que rare, peut entraîner une perte de données. Les copies retardées sont faites pour éviter la perte de données en cas d'altération logique. En règle générale, il existe deux types d'altération logique :

Corruption logique de la base de données : la somme de contrôle des pages de base de données correspond, mais les données sur les pages sont incorrectes logiquement. Cela peut arriver quand l’ESE tente d’écrire sur une page de base de données et, même si le système d’exploitation envoie un message de succès, soit les données ne sont pas écrites sur le disque soit elles sont écrites à la mauvaise place. Il s’agit d’un vidage perdu. Afin d’éviter la perte de données par les vidages perdus, l’ESE comporte un mécanisme de détection des vidages perdus dans la base de données ainsi qu’une fonctionnalité de mise à jour corrective (restauration d’une seule page).
Corruption logique du magasin : les données sont ajoutées, supprimées ou manipulées d’une manière non attendue par l’utilisateur. Ces cas sont généralement provoqués par des applications tierces. Ce n'est généralement de la corruption que dans le sens où l'utilisateur voit cela comme une altération. La banque d'informations Exchange considère la transaction qui est à l'origine de l'altération logique comme une série d'opérations MAPI valides. La fonctionnalité de conservation pour litige dans Exchange Server offre une protection contre l’altération logique du magasin (car elle empêche la suppression définitive du contenu par un utilisateur ou une application). Toutefois, dans certains cas, une boîte aux lettres d'utilisateur est si endommagée qu'il serait plus facile de la restaurer à un point antérieur à l'altération, et d'exporter ensuite la boîte aux lettres de l'utilisateur pour récupérer les données intactes.

La combinaison des copies de base de données, de la stratégie de rétention et de la restauration ESE des pages uniques ne laisse que les cas rares mais catastrophiques d'altération logique de banque d'informations. Votre choix d'utiliser une copie de base de données avec retard de relecture (une copie retardée) dépendra des applications tierces que vous utilisez et de l'historique de votre organisation quant à l'altération logique de banque d'informations.

Si vous choisissez d'utiliser des copies retardées, prenez en compte les conséquences suivantes lors de leur utilisation :

Le délai d'attente de relecture est une valeur configurée par l'administrateur qui est désactivée par défaut.
Par défaut, le paramètre de délai d'attente de relecture est défini sur 0 jour et le paramètre maximal sur 14 jours.
Les copies retardées ne sont pas considérées comme des copies hautement disponibles. Elles sont plutôt prévues à des fins de récupération d'urgence pour éviter l'altération logique de la banque d'informations.
Plus le délai d'attente de relecture est important, plus le processus de récupération de base de données est long. Selon le nombre de fichiers journaux qui doivent être relus pendant la récupération, et selon la vitesse à laquelle votre matériel peut les relire, le processus peut mettre plusieurs heures à récupérer une base de données.
Nous vous recommandons de déterminer si les copies retardées sont essentielles à votre stratégie générale de récupération d'urgence. Si elles sont essentielles à votre stratégie, nous vous recommandons d'utiliser plusieurs copies retardées ou un RAID (Redundant array of independant disks) pour protéger une seule copie retardée, si vous n'avez pas plusieurs copies retardées. Si vous perdez un disque ou si une altération se produit, vous ne perdez pas votre moment retardé dans le temps.
Les copies en retard ne peuvent pas être corrigées avec la fonctionnalité de restauration d’une page unique ESE. Si une copie en retard rencontre une altération de la page de base de données (par exemple, une erreur -1018), la copie doit être réinsérée. La réinseration perdra l’aspect décalage de la copie.

Si vous voulez que la base de données relise tous les fichiers journaux et actualise la copie de la base de données, vous pouvez facilement activer et récupérer la copie de base de données de boîtes aux lettres retardée. En revanche, il est plus difficile de relire les fichiers journaux jusqu'à un moment spécifique dans le temps car vous devez manipuler manuellement les fichiers journaux et exécuter les utilitaires de base de données d'Exchange Server (Eseutil.exe).

Pour obtenir des instructions détaillées sur l’activation d’une copie de base de données de boîtes aux lettres avec décalage, consultez Activer une copie de base de données de boîtes aux lettres avec décalage.

Délai d’attente de troncation

Le décalage de troncation est une propriété de la copie de base de données de boîtes aux lettres qui indique la durée, en minutes, du retard de suppression de la copie de base de données après relecture du fichier journal dans la copie de base de données. Le minuteur de décalage de troncation se déclenche quand un fichier journal est répliqué dans la copie passive, a passé l'inspection avec succès et a été relu avec succès dans la copie de la base de données. En retardant la troncation des fichiers journaux de la copie de base de données, vous pouvez effectuer des récupérations à la suite des échecs ayant affecté les fichiers journaux de la copie active de la base de données.

Copies de la base de données et troncation de journaux

La troncation du journal fonctionne de la même façon dans Exchange 2016 et Exchange 2019 que dans Exchange 2010. Le comportement de troncation est déterminé par les paramètres de délai d'attente de relecture et de délai d'attente de troncation de la copie.

Les critères suivants doivent être remplis pour que le fichier journal d'une copie de base de données soit tronqué lorsque les paramètres sont laissés par défaut sur 0 (désactivé) :

Le fichier journal doit avoir été sauvegardé ou la journalisation circulaire doit être activée.
Le fichier journal doit être en-dessous du point de contrôle (fichier journal minimum nécessaire pour la récupération) de la base de données.
Toutes les autres copies retardées doivent avoir inspecté le fichier journal.
Toutes les autres copies (à l'exception des copies retardées) doivent avoir relu le fichier journal.

Pour la troncation d'une copie retardée de base de données, les critères suivants doivent être remplis :

Le fichier journal doit être inférieur au point de contrôle de la base de données.
Le fichier journal doit être plus ancien que ReplayLagTime + TruncationLagTime.
Le fichier journal doit avoir été tronqué sur la copie active.

Dans Exchange Server, la troncation du journal ne se produit pas sur une copie de base de données de boîtes aux lettres active lorsqu’une ou plusieurs copies passives sont suspendues. Si des activités de maintenance planifiées doivent être effectuées sur une période prolongée (par exemple, plusieurs jours), la création de fichiers journaux risque d'être considérable. Pour éviter de remplir le lecteur avec des journaux de transactions, vous pouvez supprimer la copie de base de données passive concernée au lieu de l'interrompre. Une fois la maintenance planifiée terminée, vous pouvez rajouter la copie de base de données passive.

Exchange Server dispose désormais d’une fonctionnalité appelée troncation libre qui est désactivée par défaut. En temps normal, chaque copie de base de données conserve les journaux devant être envoyés vers d'autres copies de base de données jusqu'à ce que toutes les copies d'une base de données confirment qu'elles ont relu (copies passives) et reçu (copies retardées) les fichiers journaux. Il s'agit du comportement de troncation de journal par défaut. Si une copie de base de données est hors ligne pour une raison quelconque, les fichiers journaux s'accumulent sur les disques utilisés par les autres copies de la base de données. Si la copie de base de données concernée reste déconnectée pendant une période prolongée, les autres copies de base de données risquent d'arriver à court d'espace disque.

Le comportement de troncation est différent lorsque la troncation libre et la journalisation circulaire sont activées. Chaque copie de base de données suit la disponibilité de son propre espace disque et applique le comportement de troncation souple si l'espace disponible devient faible.

Pour la copie active, la copie de base de données passive la plus en retard dans la relecture du journal est ignorée et la troncation respecte les copies passives restantes les plus anciennes. La troncation globale est calculée dans la copie de base de données active.
Pour une copie passive, si l’espace est faible, elle tronque indépendamment ses fichiers journaux à l’aide des paramètres configurés décrits plus loin dans la table Valeur du Registre. Les copies passives tenteront de respecter la décision de troncation prise sur la copie active. Malgré l’implication du nom MinCopiesToProtect, Exchange ignore uniquement le plus ancien straggler connu au moment de l’exécution de la troncation.

Les fichiers journaux ayant été supprimés des autres copies saines seront manquants sur la base de données déconnectée lorsque celle-ci sera remise en ligne, et son statut sera FailedAndSuspended. Dans ce cas, si Autoreseed est configuré, la copie concernée sera réamorcée automatiquement. Si Autoreseed n'est pas activé, la copie de base de données devra être amorcée manuellement par un administrateur.

Si la journalisation circulaire est désactivée, la troncation libre respecte les sauvegardes si elles ont été effectuées. Par conséquent, si les journaux n’ont pas été sauvegardés, ils ne seront pas supprimés par troncation libre.

la troncation est une fonctionnalité recommandée pour l’architecture préférée où les sauvegardes ne sont pas utilisées et où la journalisation circulaire est activée.

Le nombre requis de copies saines, le seuil d'espace disque libre et le nombre de journaux à conserver sont tous des paramètres configurables. Par défaut, le seuil d'espace disque disponible est de 204 800 Mo (200 Go) et le nombre de journaux à conserver est de 100 000 (100 Go) pour les copies passives et de 10 000 (10 Go) pour les copies actives.

Pour activer la troncation souple et en configurer les paramètres, vous devez modifier le Registre Windows sur chaque membre du DAG. Trois valeurs de registre peuvent être configurées ; elles sont toutes stockées sous HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. La clé BackupInformation et les valeurs DWORD suivantes n'existent pas par défaut et doivent être créées manuellement. Les valeurs du registre DWORD sous BackupInformation sont décrites dans le tableau suivant :

Valeur de Registre	Description	Valeur par défaut
LooseTruncation_MinCopiesToProtect	Cette clé permet d'activer la troncation souple. Elle représente le nombre de copies passives à protéger de la troncation souple sur la copie active d'une base de données. Si la valeur de cette clé est définie sur 0, la troncation souple est désactivée.	0
LooseTruncation_MinDiskFreeSpaceThresholdInMB	Seuil d'espace disque disponible (en Mo) pour le déclenchement de la troncation souple. Si l'espace disque disponible descend en dessous de cette valeur, la troncation souple est déclenchée.	Si cette valeur de registre n'est pas configurée, la valeur par défaut utilisée par la troncation souple est 200 Go.
LooseTruncation_MinLogsToProtect	Nombre minimal de fichiers journaux à conserver sur les copies saines dont les journaux sont tronqués. Si cette valeur de registre est configurée, la valeur configurée s'applique alors aux copies actives et passives.	Si cette valeur de registre n'est pas configurée, les valeurs par défaut 100 000 pour les copies de base de données passives et 10 000 pour les copies de base de données actives sont utilisées.

Lorsque vous utilisez la valeur de Registre LooseTruncation_MinLogsToProtect, notez que le comportement est différent pour les copies de base de données actives et passives. Sur la copie de base de données active, il s’agit du nombre de journaux supplémentaires conservés avant ceux requis par les copies passives protégées et la plage requise de la copie active. Sur une copie de base de données passive, il s’agit du nombre de journaux conservés à partir du dernier journal disponible. Un dixième de ce nombre est également utilisé pour gérer les journaux avant la plage requise de cette copie passive. Les deux limites sont en place pour garantir que les copies de base de données retardées ne prennent pas trop d’espace, car leur plage requise est généralement très grande.

Stratégie d’activation de la base de données

Les stratégies d’activation de la base de données sont des scénarios dans lesquels vous voulez créer une copie de base de données de boîtes aux lettres et éviter que le système active automatiquement cette copie en cas de panne, par exemple :

Si vous déployez une ou plusieurs copies de base de données de boîtes aux lettres dans un centre de données de remplacement ou de veille.
Si vous configurez une copie retardée de base de données à des fins de récupération.
Si vous effectuez une maintenance ou une mise à niveau d’un serveur.

Dans chacun des scénarios évoqués ci-dessus, vous avez des copies de base de données que vous ne voulez pas voir activées automatiquement par le système. Si vous voulez éviter que le système active automatiquement une copie de base de données de boîtes aux lettres, vous pouvez configurer la copie pour qu'elle soit bloquée (suspendue) à l'activation. Cela permet au système de maintenir l'actualité de la base de données par l'envoi de fichiers journaux et la relecture, mais l'empêche d'activer et d'utiliser automatiquement la copie. Les copies bloquées pour l'activation doivent être activées manuellement par un administrateur. Vous pouvez configurer la stratégie d’activation de base de données pour un serveur entier à l’aide de l’applet de commande Set-MailboxServer ou d’une copie de base de données individuelle à l’aide de l’applet de commande Set-MailboxDatabaseCopyCopy pour définir le paramètre DatabaseCopyAutoActivationPolicy sur Bloqué.

Pour plus d'informations sur la configuration des stratégies d'activation de la base de données, consultez la rubrique Configurer la stratégie d'activation pour une copie de base de données de boîte aux lettres.

Impact des déplacements de boîtes aux lettres sur la réplication continue

Sur une base de données de boîtes aux lettres très occupée avec une fréquence élevée de génération des journaux, vous risquez davantage de perdre des données si la réplication sur les copies passives de base de données ne parvient pas à suivre la génération des journaux. Un déplacement de boîtes aux lettres peut provoquer une fréquence élevée de génération de journaux. Exchange Server inclut une API de garantie des données utilisée par des services tels que le service de réplication de boîtes aux lettres Exchange (MRS) pour vérifier l’intégrité de l’architecture de copie de base de données en fonction de la valeur du paramètre DataMoveReplicationConstraint défini par le système ou un administrateur. Plus précisément, l'API de garantie des données peut servir à :

Vérifier l’intégrité de la réplication : confirme que le nombre de copies de base de données requis est disponible.
Vérifier le vidage de la réplication : confirme que les fichiers journaux requis ont été relus par rapport au nombre de copies de base de données requis.

Lorsqu'elle est exécutée, l'API retourne les informations d'état suivantes à l'application appelante :

Nouvelle tentative : signifie qu’il existe des erreurs temporaires qui empêchent la vérification d’une condition par rapport à la base de données.
Satisfait : signifie que la base de données remplit les conditions requises ou que la base de données n’est pas répliquée.
Non satisfait : signifie que la base de données ne remplit pas les conditions requises. De plus, des informations sont fournies à l'application appelante sur le motif du retour de la réponse NotSatisfied.

La valeur du paramètre DataMoveReplicationConstraint pour la base de données de boîtes aux lettres détermine le nombre de copies de base de données à évaluer dans le cadre de la requête. Le paramètre DataMoveReplicationConstraint a les valeurs possibles suivantes :

None: lorsque vous créez une base de données de boîtes aux lettres, cette valeur est définie par défaut. Lorsque cette valeur est définie, les conditions de l'API de garantie des données sont ignorées. Ce paramètre doit être utilisé uniquement pour les bases de données de boîtes aux lettres qui ne sont pas répliquées.
SecondCopy: il s’agit de la valeur par défaut lorsque vous ajoutez la deuxième copie d’une base de données de boîtes aux lettres. Lorsque cette valeur est définie, au moins une copie passive de base de données doit respecter les conditions de l'API de garantie des données.
SecondDatacenter: lorsque cette valeur est définie, au moins une copie de base de données passive dans un autre site Active Directory doit répondre aux conditions de l’API De garantie des données.
AllDatacenters: lorsque cette valeur est définie, au moins une copie de base de données passive dans chaque site Active Directory doit répondre aux conditions de l’API De garantie des données.
AllCopies: lorsque cette valeur est définie, toutes les copies de la base de données de boîtes aux lettres doivent répondre aux conditions de l’API De garantie des données.

Vérifier l'intégrité de la réplication

Lorsque l'API de garantie des données est exécutée pour évaluer l'intégrité de l'infrastructure de la copie de base de données, plusieurs éléments sont évalués.

Dans tous les scénarios, la copie passive de la base de données doit remplir les conditions suivantes :

Être intègre.
Avoir une file d'attente de relecture comprise dans les 10 minutes du délai d'attente de relecture.
Avoir une longueur de file d'attente de copie inférieure à 10 journaux.
Avoir une longueur moyenne de file d'attente de copie inférieure à 10 journaux. La longueur moyenne de file d'attente de copie est calculée en fonction du nombre de fois où l'application a demandé l'état de la base de données.

Si le paramètre DataMoveReplicationConstraint est défini sur...	Ensuite, pour une base de données donnée...
`SecondCopy`	Au moins une copie de base de données passive pour une base de données répliquée doit répondre aux conditions décrites précédemment.
`SecondDatacenter`	Au moins une copie de base de données passive dans un autre site Active Directory doit remplir les conditions décrites précédemment.
`AllDatacenters`	La copie active doit être montée et une copie passive dans chaque site Active Directory doit répondre aux conditions décrites précédemment.
`AllCopies`	La copie active doit être montée et toutes les copies de base de données passives doivent respecter les conditions décrites précédemment.

Vérifier le vidage de réplication

L'API de garantie des données permet également de valider qu'un nombre préalablement requis de copies de base de données ont relu les journaux des transactions requis. Ceci est vérifié en comparant l'horodatage du dernier journal relu à celui de validation du service d'appel (dans la plupart des cas, c'est l'horodatage du dernier fichier journal qui contient les données requises) plus cinq secondes supplémentaires (pour tenir compte des variations ou des décalages de l'horloge système). Si l’horodatage de relecture est supérieur à l’horodatage de validation, le paramètre DataMoveReplicationConstraint est satisfait. Si l’horodatage de relecture est inférieur à l’horodatage de validation, dataMoveReplicationConstraint n’est pas satisfait.

Avant de déplacer un grand nombre de boîtes aux lettres vers ou à partir de bases de données de réplication au sein d’un DAG, nous vous recommandons de configurer le paramètre DataMoveReplicationConstraint sur chaque base de données de boîtes aux lettres en fonction des éléments suivants :

Si vous déployez...	Définissez DataMoveReplicationConstraint sur...
Des bases de données de boîtes aux lettres qui ne possèdent aucune copie de base de données	`None`
Un DAG au sein d'un seul site Active Directory	`SecondCopy`
Un DAG dans plusieurs centres de données à l'aide d'un site Active Directory étiré	`SecondCopy`
Un DAG qui s'étend sur deux sites Active Directory et que vous avez des copies de base de données à haute disponibilité sur chaque site	`SecondDatacenter`
Un DAG qui s'étend sur deux sites Active Directory et que vous avez seulement des copies de base de données retardées sur le second site	`SecondCopy` En effet, l'API de garantie des données ne garantira pas des données en cours de validation avant la relecture du fichier journal dans la copie de base de données et, en raison de la nature de la copie de base de données étant retardée, cette contrainte va faire échouer la demande de déplacement, à moins que la valeur de ReplayLagTime de la copie de base de données retardée soit inférieure à 30 minutes.
Un DAG qui s'étend sur trois sites Active Directory ou plus, et que chaque site contient des copies de base de données à haute disponibilité	`AllDatacenters`

Équilibrage des copies de base de données

De par la nature inhérente des groupes de disponibilité de base de données, lorsqu’un basculement ou une permutation de base de données se produit, les copies de base de données de boîtes aux lettres actives changent d’hôte plusieurs fois tout au long du cycle de vie d’un groupe de disponibilité de base de données. Par conséquent, les groupes de disponibilité de base de données se trouvent en déséquilibre au niveau de la distribution des copies de base de données de boîtes aux lettres actives. Le tableau suivant illustre un exemple de groupe de disponibilité de base de données comportant quatre bases de données et quatre copies de chacune (pour un total de 16 bases de données sur chaque serveur) avec une distribution inéquitable des copies de base de données actives.

Groupe de disponibilité de base de données avec une distribution inéquitable des copies actives

Serveur	Nombre de bases de données actives	Nombre de bases de données passives	Nombre de bases de données montées	Liste de décompte des préférences
EX1	5	11	5	4, 4, 3, 5
EX2	1	15	1	1, 8, 6, 1
Ex3	12	4	12	13, 2, 1, 0
EX4	1	15	1	1, 1, 5, 9

Dans l'exemple précédent, on dénombre quatre copies de chaque base de données et donc, seulement quatre valeurs possibles pour la préférence d'activation (1, 2, 3 ou 4). La colonne Liste de décompte des préférences indique le nombre de bases de données avec chacune de ces valeurs. Par exemple, sur EX3, il existe 13 copies de base de données avec la préférence d'activation 1, deux copies avec la préférence d'activation 2, une copie avec la préférence d'activation 3 et aucune copie avec la préférence d'activation 4.

Comme vous pouvez le voir, ce groupe de disponibilité de base de données n'est pas équilibré en termes de nombre de bases de données actives hébergées par chaque membre du groupe, de nombre de bases de données passives hébergées par chaque membre du groupe ou de décompte de préférences d'activation des bases de données hébergées.

Vous pouvez utiliser le script RedistributeActiveDatabases.ps1 pour équilibrer les copies de base de données de boîtes aux lettres actives sur un DAG. Ce script déplace les bases de données d'une copie vers une autre afin d'essayer d'obtenir un nombre équitable de bases de données montées sur chaque serveur dans le groupe de disponibilité de base de données. Si nécessaire, le script essaie également d'équilibrer les bases de données actives dans les sites.

Le script inclut deux options permettant d'équilibrer les copies de base de données actives dans un groupe de disponibilité de base de données :

BalanceDbsByActivationPreference : lorsque cette option est spécifiée, le script tente de déplacer les bases de données vers leur copie préférée (en fonction de la préférence d’activation) sans tenir compte du site Active Directory.
BalanceDbsBySiteAndActivationPreference : lorsque cette option est spécifiée, le script tente de déplacer les bases de données actives vers leur copie préférée, tout en essayant d’équilibrer les bases de données actives au sein de chaque site Active Directory.

Après avoir exécuté le script avec la première option, le groupe de disponibilité déséquilibré précédent est rééquilibré, comme l'illustre le tableau suivant.

Groupe de disponibilité de base de données avec une distribution équitable des copies actives

Serveur	Nombre de bases de données actives	Nombre de bases de données passives	Nombre de bases de données montées	Liste de décompte des préférences
EX1	4	12	4	4, 4, 4, 4
EX2	4	12	4	4, 4, 4, 4
Ex3	4	12	4	4, 4, 4, 4
EX4	4	12	4	4, 4, 4, 4

Comme indiqué dans le tableau précédent, ce groupe de disponibilité de base de données est à présent équilibré en termes de nombre de bases de données actives et passives sur chaque serveur et de préférence d'activation sur les serveurs.

Le tableau suivant répertorie les paramètres disponibles pour le script RedistributeActiveDatabases.ps1.

Paramètres du script RedistributeActiveDatabases.ps1

Paramètre	Description
DagName	Indique le nom du groupe de disponibilité de base de données que vous souhaitez rééquilibrer. Si ce paramètre est omis, le groupe de disponibilité de base de données dont fait partie le serveur local est utilisé.
BalanceDbsByActivationPreference	Indique que le script doit déplacer les bases de données vers leur copie préférée, indépendamment du site Active Directory.
BalanceDbsBySiteAndActivationPreference	Indique que le script doit essayer de déplacer les bases de données actives vers leur copie préférée, tout en essayant d'équilibrer les bases de données actives dans chaque site Active Directory.
ShowFinalDatabaseDistribution	Indique qu'un rapport de distribution des bases de données actuelles doit s'afficher une fois la redistribution terminée.
AllowedDeviationFromMeanPercentage	Spécifie l'écart autorisé des bases de données actives dans les sites, exprimé en pourcentage. La valeur par défaut est de 20 %. Par exemple, si 99 bases de données ont été distribuées entre trois sites, la distribution idéale serait de 33 bases de données dans chaque site. Si l'écart autorisé est de 20 %, le script tente d'équilibrer les bases de données afin que chaque site ne contienne pas plus de 10 % par rapport à ce nombre. 10 % de 33 équivaut à 3,3, chiffre arrondi à 4. Par conséquent, le script essaie d'avoir entre 29 et 37 bases de données dans chaque site.
ShowDatabaseCurrentActives	Indique que le script doit créer, pour chaque base de données, un rapport indiquant la manière dont celle-ci a été déplacée et si elle est maintenant active sur sa copie préférée.
ShowDatabaseDistributionByServer	Indique que le script doit générer un rapport décrivant la distribution des bases de données pour chaque serveur.
RunOnlyOnPAM	Indique que le script s'exécute uniquement sur le membre du groupe de disponibilité de base de données exerçant actuellement le rôle de gestionnaire Active Manager principal (PAM). Le script vérifie qu'il est exécuté à partir du gestionnaire Active Manager principal. Si tel n'est pas le cas, le script prend fin.
LogEvents	Indique que le script consigne un événement (événement 4115 MsExchangeRepl) contenant un résumé des actions.
IncludeNonReplicatedDatabases	Indique que le script doit inclure les bases de données non répliquées (bases de données sans copies) lors de la détermination du mode de redistribution des bases de données actives. Même si les bases de données non répliquées ne peuvent pas être déplacées, elles peuvent influencer la distribution des bases de données répliquées.
Confirm	Le commutateur Confirm peut être utilisé pour supprimer la boîte de dialogue de confirmation qui s'affiche par défaut lorsque ce script est exécuté. Pour supprimer la boîte de dialogue de confirmation, utilisez la syntaxe de -Confirm:$False. Vous devez inclure un signe deux-points ( : ) dans la syntaxe.

Exemples de script RedistributeActiveDatabases.ps1

Cet exemple illustre la distribution des bases de données actuelles pour un groupe de disponibilité de base de données, notamment la liste de décompte des préférences.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

Cet exemple illustre la redistribution et l'équilibrage des copies de base de données de boîtes aux lettres actives dans un groupe de disponibilité de base de données utilisant la préférence d'activation sans intervention de l'utilisateur.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

Cet exemple illustre la redistribution et l’équilibrage des copies de base de données de boîtes aux lettres actives dans un groupe de disponibilité de base de données utilisant la préférence d’activation, ainsi que la création d’un récapitulatif de la distribution.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Surveillance des copies de base de données

En examinant les détails d'une copie de base de données dans le CAE, vous pouvez consulter une variété d'informations, dont la longueur de la file d'attente de copie, la longueur de la file d'attente de relecture et des informations sur l'état de la copie et de l'index de contenu. Dans l'Environnement de ligne de commande Exchange Management Shell, vous pouvez également utiliser la cmdlet Get-MailboxDatabaseCopyStatus pour afficher des informations sur l'état d'une copie de base de données.

Remarque

Une copie de base de données est votre premier recours en cas de panne touchant la copie active de la base de données. Il est donc essentiel de contrôler l'intégrité et l'état des copies de base de données pour vous assurer qu'elles seront disponibles quand vous en aurez besoin.

Pour plus d’informations sur la surveillance des copies de base de données, consultez Surveiller les groupes de disponibilité de base de données.

Suppression d’une copie de base de données

Une copie de base de données peut être supprimée à tout moment à l'aide du CAE ou de la cmdlet Remove-MailboxDatabaseCopy dans l'Environnement de ligne de commande Exchange Management Shell. Après suppression d'une copie de base de données, vous devez manuellement supprimer tout fichier journal de transaction et de base de données du serveur sur lequel la copie de base de données est en cours de suppression. Pour savoir en détail comment supprimer une copie de base de données, consultez la rubrique Supprimer une copie de base de données de boîtes aux lettres.

Permutation de base de données

Le serveur de boîtes aux lettres qui héberge la copie active de la base de données est le maître de la base de données de boîtes aux lettres. Le processus d'activation d'une copie de base de données active modifie le maître de la base de données de boîtes aux lettres et convertit la copie passive en nouvelle copie active. Ce processus est appelé basculement de base de données. Dans un basculement de base de données, la copie active de la base de données est démontée d'un serveur de boîtes aux lettres et une copie passive de cette base est montée en tant que nouvelle base de données de boîtes aux lettres active sur un autre serveur de boîtes aux lettres. Lorsque vous effectuez un basculement, vous pouvez éventuellement remplacer les paramètres de numérotation de montage de la base de données sur le nouveau maître de la base de données de boîtes aux lettres.

Vous pouvez rapidement identifier le serveur de boîtes aux lettres qui est actuellement le maître de la base de données de boîtes aux lettres en examinant la colonne de droite sous l'onglet Copies de base de données dans le CAE. Vous pouvez effectuer un basculement à l'aide du lien Activer dans le CAE ou à l'aide de la cmdlet Move-ActiveMailboxDatabase dans l'Environnement de ligne de commande Exchange Management Shell.

Plusieurs vérifications internes sont effectuées avant l’activation d’une copie passive. Dans certains cas, le basculement de base de données est bloqué ou annulé. Dans d’autres cas, vous pouvez utiliser des applets de commande pour déplacer ou ignorer certaines vérifications.

L'état de la copie de base de données est contrôlé. Si la copie de base de données est en état d'échec, le basculement est bloqué. Vous pouvez remplacer ce comportement et contourner le contrôle d’intégrité à l’aide du paramètre SkipHealthChecks de l’applet de commande Move-ActiveMailboxDatabase . Ce paramètre vous permet de déplacer la copie active vers une copie de base de données en état d'échec.
La copie de base de données active est vérifiée pour voir si elle est actuellement une source d'amorçage pour toute copie de base de données passive. Si la copie active est actuellement utilisée comme source d'amorçage, le basculement est bloqué. Vous pouvez remplacer ce comportement et contourner la vérification de la source d’amorçage à l’aide du paramètre SkipActiveCopyChecks de l’applet de commande Move-ActiveMailboxDatabase . Ce paramètre vous permet de déplacer une copie active qui est utilisée comme source d'amorçage. L'utilisation de ce paramètre entraîne l'annulation de l'opération d'amorçage qui est alors considérée défectueuse.
Les longueurs de la file d'attente de copie et de relecture de la copie de base de données sont contrôlées afin de veiller à ce que les valeurs correspondent aux critères configurés. De même, la copie de base de données est vérifiée pour s'assurer qu'elle n'est pas utilisée actuellement comme source d'amorçage. Si les valeurs des longueurs de file d'attente ne font pas partie des critères configurés ou si la base de données est actuellement utilisée comme source d'amorçage, le basculement est bloqué. Vous pouvez remplacer ce comportement et contourner ces vérifications à l’aide du paramètre SkipLagChecks de l’applet de commande Move-ActiveMailboxDatabase . Ce paramètre permet d'activer une copie disposant de files d'attente de relecture et de copie en dehors des critères configurés.
L'état du catalogue de recherche (index du contenu) de la copie de base de données est contrôlé. Si le catalogue de recherche n'est pas à jour, n'est pas en bon état ou est endommagé, le basculement est bloqué. Vous pouvez remplacer ce comportement et contourner la vérification du catalogue de recherche à l’aide du paramètre SkipClientExperienceChecks de l’applet de commande Move-ActiveMailboxDatabase . Grâce à ce paramètre, la recherche n'effectue pas le contrôle d'état du catalogue. Si le catalogue de recherche de la copie de base de données que vous activez n'est pas en bon état ou est inexploitable et que vous utilisez ce paramètre pour passer le contrôle d'état du catalogue et activer la copie de base de données, il vous faudra à nouveau analyser ou amorcer le catalogue de recherche.

Quand vous effectuez un basculement de base de données, vous pouvez remplacer les paramètres de numérotation de montage configurés pour le serveur hébergeant la copie passive de base de données activée. L’utilisation du paramètre MountDialOverride de l’applet de commande Move-ActiveMailboxDatabase indique au serveur cible de remplacer ses propres paramètres de numérotation de montage et d’utiliser ceux spécifiés par le paramètre MountDialOverride .

Pour obtenir la procédure détaillée de basculement d'une copie de base de données, consultez la rubrique Activer une copie de la base de données de boîtes aux lettres.

Partager via