NetVault Plug-in for Exchange 12.0 - Guide de l'utilisateur

Protection des bases de données Exchange Server

Une base de données offre la granularité la plus fine pour l'organisation du stockage dans le schéma Exchange Server. Les boîtes aux lettres sont attribuées à des bases de données spécifiques, ce qui permet de séparer les données par boîte aux lettres pour des raisons de sécurité ou d'évolutivité. Il peut arriver que les boîtes aux lettres critiques ou à grand volume soient séparées dans une base de données distincte pour améliorer les performances ou effectuer des sauvegardes plus fréquentes.

Les bases de données sont utilisées pour contenir les boîtes aux lettres, messages, stockages de dossiers et autres objets de données pris en charge par le serveur Exchange. Bien qu'elles puissent contenir une grande variété d'objets de données, les bases de données sont généralement de deux types : les banques de messagerie et les banques de dossiers publics. Dans la terminologie Exchange Server, une banque est identique à une base de données.

Microsoft différencie également les éditions du produit Exchange Server par une prise en charge accrue des bases de données concurrentes. L'édition Enterprise est définie comme prenant en charge davantage de bases de données concurrentes que l'édition Standard.

Protection du journal des transactions du serveur Exchange

Toutes les modifications apportées à la base de données Exchange Server sont d'abord validées dans les fichiers journaux des transactions. Chaque fois qu'un utilisateur modifie les données stockées dans une boîte aux lettres ou que des données sont ajoutées à la boîte aux lettres, cette modification est consignée dans un fichier journal de transactions avant d'être écrite dans la base de données Exchange Server.

Aperçu des méthodes de sauvegarde disponibles

Plug‑in for Exchange prend en charge les méthodes de sauvegarde suivantes :

Pour Exchange 2007, le plug-in prend en charge la mise en œuvre d'un moteur de stockage extensible (ESE) ou d'une stratégie de sauvegarde VSS ; c'est-à-dire que votre stratégie de sauvegarde doit inclure les sauvegardes ESE ou VSS, mais pas les deux ensemble. Pour Exchange 2010 ou version ultérieure, VSS est la seule option prise en charge par Exchange.

Microsoft prend en charge la sauvegarde en ligne des bases de données Exchange Server à l'aide du moteur de base de données Exchange Server (ESE) pour Exchange 2007 et versions antérieures. Fourni par Microsoft comme composant standard d'Exchange Server, ESE offre les plus hauts niveaux de compatibilité avec Exchange.

IMPORTANT: Windows Server 2008 prend en charge Exchange Server 2007 SP1 ou version ultérieure ; les versions précédentes d'Exchange 2007 ne sont pas prises en charge. Dans une installation standard d'Exchange Server 2007 SP1, le dossier Exchange Server Bin contient la bibliothèque de client ESE (esebcli2.dll). esebcli2.dll possède la version de fichier 8.1.240.5 pour Exchange Server 2007 SP1. Cependant, si cette bibliothèque n'est pas répliquée du dossier Bin d'Exchange vers le dossier Bin de Windows, une version plus ancienne du fichier .dll peut être présente dans le dossier Bin de Windows. Plug‑in for Exchange utilise la bibliothèque client ESE disponible dans le dossier Bin de Windows. Si l'ancienne version de la bibliothèque se trouve dans le dossier Bin de Windows, une session de sauvegarde ou de restauration peut échouer. En cas d'échec, enregistrez une copie de la bibliothèque de client ESE du dossier Bin de Windows dans un emplacement sûr, copiez la bibliothèque de client ESE du dossier Bin d'Exchange Server dans le dossier Bin de Windows, puis exécutez à nouveau la session de sauvegarde ou de restauration.

Microsoft permet de créer des instantanés des données Exchange à l'aide de VSS. Microsoft fournit des enregistreurs VSS spécifiques à Exchange, coordonnés avec les services Exchange et agissant au nom du Plug‑in for Exchange, afin de préparer les fichiers des groupes de stockage/bases de données de boîtes aux lettres pour les sauvegardes et de geler l'activité d'entrée/sortie (E/S) imputable aux transactions Exchange avant de passer à la sauvegarde, puis de débloquer et tronquer les journaux une fois la sauvegarde terminée.

VSS est la méthode de sauvegarde recommandée pour les environnements LCR et CCR Exchange 2007. Lorsqu'ils utilisent la méthode de sauvegarde VSS dans un environnement CCR, les administrateurs peuvent choisir le nœud sauvegardé (le nœud actif ou le nœud passif).

Pour Exchange 2010 ou version ultérieure, VSS est la seule option prise en charge par Exchange.

VSS vous permet de :

REMARQUE: L'option Sauvegarder les fichiers dans le stockage est prise en charge avec n'importe quel stockage sur disque. Pour utiliser les options Conserver la persistance des instantanés et Ignorer après, les données que vous sauvegardez doivent se trouver sur une matrice de disque prise en charge par NetVault Backup. De plus, pour les instantanés persistants, seules les métadonnées sont copiées vers la cible.

Lorsque vous cherchez à déterminer la méthode de sauvegarde pour votre stratégie de sauvegarde Exchange, examinez les différences suivantes :

REMARQUE: ESE et VSS ne sont pas pris en charge sur toutes les versions d'Exchange. La version d'Exchange que vous utilisez dicte les méthodes de sauvegarde disponibles.

Gestion des fichiers journaux de transactions

La gestion des fichiers journaux de transactions est une considération primordiale pour la définition d'une stratégie de sauvegarde Exchange Server.

IMPORTANT: Important : puisque toutes les modifications apportées à la base de données Exchange Server sont d'abord validées dans les fichiers journaux de transactions, Quest vous recommande vivement d'exécuter régulièrement des sauvegardes complètes ou incrémentielles, afin d'éviter l'accumulation excessive de fichiers journaux de transactions. Le fait de ne pas effectuer de sauvegardes régulières, ce qui réduit le nombre de fichiers journaux de transactions, peut éventuellement entraîner l'échec des sessions de sauvegarde. De plus, l'accumulation de milliers de fichiers journaux de transactions a un impact négatif sur le temps nécessaire pour traiter une session de sauvegarde et générer l'index. Si l'environnement implique de fréquentes modifications du serveur Exchange, Quest recommande également d'augmenter la fréquence des sauvegardes afin de réduire l'accumulation des fichiers journaux de transactions.

La troncature des fichiers journaux de transactions est utilisée pour « nettoyer » le groupe de stockage/la base de données de boîte aux lettres Exchange Server, améliorant ainsi les performances et réduisant les besoins en espace disque ainsi que le temps requis pour restaurer une base de données.

Quest recommande d'exécuter régulièrement les sauvegardes qui effectuent la troncature des fichiers journaux de transactions. Il est souvent recommandé d'effectuer une sauvegarde hebdomadaire ou bimensuelle effectuant la troncature des fichiers journaux des transactions. La fréquence optimale peut varier considérablement, en fonction de l'utilisation et de la configuration de chaque serveur Exchange.

Si vous utilisez un type de sauvegarde qui prend en charge la troncature des fichiers journaux de transactions, comme la sauvegarde complète et incrémentielle, le serveur Exchange effectue la troncature des fichiers journaux de transactions une fois que le plug-in l'informe que la sauvegarde est terminée avec succès. Par ailleurs, le moment où la troncature est effectuée dépend d'Exchange Server et s'il a encore besoin des journaux à d'autres fins, telles que la réplication ; par conséquent, la troncature peut ne pas se produire dès la fin d'une sauvegarde réussie.

Dans un environnement DAG, la troncature des fichiers journaux de transactions est également déterminée par les propriétés de décalage de réexécution et de troncature de la base de données. Les propriétés sont configurables. Le décalage de réexécution définit, en minutes, le temps nécessaire pour retarder la réexécution du journal pour une copie de la base de données. Le décalage de troncature définit, en minutes, le temps nécessaire pour retarder la suppression du journal pour la copie de la base de données, une fois que le fichier journal a été réexécuté dans la copie de la base de données.

Les critères suivants doivent être respectés pour qu'un serveur Exchange puisse tronquer un fichier journal de transactions :

Dans un environnement DAG, chaque copie de base de données conserve les fichiers journaux de transactions jusqu'à ce que toutes les copies de la base de données aient confirmé la réexécution du fichier journal de transactions. Si une ou plusieurs copies passives de la base de données sont suspendues ou hors ligne, les fichiers journaux ne sont pas tronqués, entraînant l'accumulation de fichiers journaux de transactions et la consommation d'espace disque.

REMARQUE: Si votre environnement connaît une accumulation de fichiers journaux de transactions et une réduction de l'espace disque disponible, vérifiez le statut de connexion des copies passives de base de données. Si vous devez conserver une ou plusieurs copies de base de données suspendues ou hors ligne pendant une longue période, par exemple pour des raisons de maintenance, envisagez de supprimer la copie passive de base de données concernée au lieu de la suspendre ou de la mettre hors ligne. Une fois la maintenance terminée, vous pouvez rajouter la copie passive de base de données.

Afin de réduire les effets de l'accumulation de fichiers journaux de transactions imputables aux copies de base de données suspendues ou hors ligne, Exchange Server 2013 Service Pack 1 propose une nouvelle fonction de troncature lâche. Avec la troncature lâche, chaque copie de base de données assure le suivi de son propre espace disque disponible et applique la troncature lâche lorsque le disque est pratiquement saturé. Lorsque la troncature lâche est appliquée, chaque copie passive de base de données tronque ses propres fichiers journaux de transactions de manière indépendante. Pour la copie active de base de données, la troncature ignore la copie passive de base de données, qui est la plus en retard sur la réexécution des journaux.

La troncature lâche est désactivée par défaut. Pour activer la troncature lâche, vous devez modifier le registre de Windows sur chaque nœud DAG du serveur Exchange DAG. Avant d'activer la troncature lâche, assurez-vous que cela va dans le sens de vos objectifs de protection des données. Pour plus d'informations sur l'activation de la troncature lâche, voir la documentation Exchange Server.

Les sauvegardes complètes sauvegardent tous les fichiers d'une base de données, quel qu'en soit leur type. Les sauvegardes de journaux de transactions sauvegardent uniquement les fichiers journaux de transactions d'une base de données.

Les sauvegardes complètes permettent de sauvegarder tous les fichiers de la base de données, offrant des fonctions de restauration autonomes. Selon la taille de la base de données, les sauvegardes complètes peuvent être exigeantes en termes de besoins de stockage et de temps requis pour effectuer la sauvegarde. Pour les grandes bases de données, les contraintes en matière de stockage et de temps peuvent revêtir une grande importance.

Les sauvegardes de journaux de transactions sont des sauvegardes plus légères destinées à capturer les nouvelles activités intervenues depuis la dernière sauvegarde complète. Ce type de sauvegarde peut considérablement réduire les exigences de temps et de stockage pour les grandes bases de données, mais il dépend également d'une ou plusieurs sauvegardes antérieures pour effectuer une restauration complète.

IMPORTANT: Les sauvegardes basées sur VSS pour les environnements de réplication non continue tronquent les journaux de transactions à l'issue des sauvegardes complètes ou de journaux de transactions. Dans les environnements LCR et CCR, le Service de réplication Microsoft Exchange retarde la troncature des journaux jusqu'à ce que tous les fichiers journaux nécessaires soient réexécutés dans la copie de réplique. Le Service de réplication Microsoft Exchange supprime les fichiers journaux sauvegardés des chemins d'accès des fichiers journaux de copie active et passive, après avoir vérifié que les fichiers journaux à supprimer ont été appliqués avec succès à la base de données de copie passive et que les points de contrôle de la base de données de copie active et passive ont vérifié les fichiers journaux en question.