Différence entre sauvegarde et restauration dans l'utilitaire DSBK et TSA pour NDS
Présentation du processus de restauration avec l'outil de restauration
Utilisation de serveurs DSMASTER dans le cadre d'un plan de reprise après sinistre
Vecteurs de transition et processus de vérification de la restauration
L'outil de sauvegarde permet d'effectuer une sauvegarde continue à chaud de la base de données eDirectory sur un serveur individuel. Si vous sauvegardez eDirectory sur votre serveur sans fermer la base de données, vous obtenez néanmoins d'une sauvegarde complète, image fidèle de l'état de la base au début de la sauvegarde. Grâce à cette fonction, vous pouvez lancer une sauvegarde à tout moment, eDirectory restant accessible tout au long du processus.
REMARQUE :la sauvegarde continue à chaud est adoptée par défaut. Vous pouvez, si nécessaire, demander une sauvegarde « à froid » lorsque la base de données est fermée.
La nouvelle fonction de sauvegarde permet également d'activer la consignation de transactions individuelles par fichier, pour conserver un enregistrement des transactions dans la base de données depuis la dernière sauvegarde. Vous pouvez ainsi restaurer un serveur dans l'état où il se trouvait avant son arrêt. Vous devez activer cette consignation pour les serveurs qui font partie d'un anneau de répliques, afin de rendre à un serveur l'état de synchronisation attendu par les autres serveurs. Faute de quoi, des messages d'erreur s'afficheront lorsque vous tenterez de procéder à une restauration à partir des fichiers de sauvegarde et la base de données ne s'ouvrira pas. La consignation de transactions individuelles par fichier est désactivée par défaut. Pour plus d'informations, reportez-vous à la Section 15.3, Utilisation des fichiers journaux de transactions individuelles.
L'outil de sauvegarde ne sauvegarde pas tous les objets d'eDirectory en même temps, mais seulement les partitions d'un serveur spécifique. Cela permet une meilleure restauration du serveur et des sauvegardes plus rapides qu'avec l'utilitaire de sauvegarde classique TSA pour NDS®. Celui-ci continue de fonctionner comme expliqué dans eDirectory 8.6. Vous pouvez l'employer avec la nouvelle fonction de sauvegarde, si nécessaire. Pour une comparaison, reportez-vous à la section Différence entre sauvegarde et restauration dans l'utilitaire DSBK et TSA pour NDS.
L'outil de sauvegarde d'eDirectory doit être utilisé en association avec les sauvegardes du système de fichiers, afin d'enregistrer sur bande les fichiers de sauvegarde d'eDirectory, par mesure de sécurité. NetIQ a établi des partenariats avec plusieurs grands fournisseurs de solutions de sauvegarde. Pour obtenir la liste, consultez la section du site des produits partenaires de NetIQ eDirectory (NetIQ eDirectory Partner Products).
Pour une description du format des fichiers de sauvegarde et des fichiers journaux créés par l'outil de sauvegarde, reportez-vous aux sections Format du fichier journal de sauvegarde et Format de l'en-tête des fichiers de sauvegarde.
Dans les versions précédentes d'eDirectory, les fonctions de sauvegarde et de restauration étaient axées sur la sauvegarde de l'arborescence, objet par objet.
L'outil de sauvegarde d'eDirectory 8.7 a introduit une méthode totalement différente, ainsi qu'une nouvelle architecture. Il est en effet axé sur le serveur, et non sur l'arborescence. Vous sauvegardez la base de données eDirectory individuellement sur chaque serveur. De plus, il est beaucoup plus rapide que l'utilitaire de sauvegarde classique TSA pour NDS.
Vous pouvez continuer d'utiliser celui-ci pour sauvegarder l'arborescence, mais nous vous conseillons d'employer le nouvel outil.
Pour plus d'informations, consultez le tableau ci-dessous.
|
Point |
Sauvegarde TSA pour NDS existante |
Outil de sauvegarde « Sauvegarde continue à chaud » |
|---|---|---|
|
Objectif |
Conçu pour sauvegarder l'arborescence, objet par objet. |
Conçu pour sauvegarder la base de données eDirectory sur chaque serveur pris individuellement. La tolérance aux pannes de l'arborescence complète doit être en premier lieu assurée par la réplication, mais le fait de sauvegarder chaque serveur permet de la renforcer. Lorsque vous devez prévoir une stratégie de restauration de l'arborescence suite à un sinistre ayant entraîné la perte de nombreux serveurs, pensez à employer des serveurs DSMASTER avec la fonction de planification de répliques, comme expliqué à la section Utilisation de serveurs DSMASTER dans le cadre d'un plan de reprise après sinistre. |
|
Vitesse |
S/O |
Considérablement accrue. La vitesse est l'une des caractéristiques les plus importantes du nouvel outil de sauvegarde. |
|
Emplacement de la sauvegarde |
Permet de placer la sauvegarde directement sur une bande magnétique. |
Les fichiers de sauvegarde sont placés dans le système de fichiers. Vous devez sauvegarder ce dernier pour les enregistrer sur bande, afin de les stocker en lieu sûr. |
|
Multi plate-forme |
Fonctionne différemment sur chaque plate-forme. |
Fonctionne de manière identique sur toutes les plates-formes. |
|
Possibilité de restaurer des serveurs individuels |
Non conçu pour cela. |
Offre la possibilité de restaurer un serveur spécifique après une défaillance de disque dur, ou d'utiliser la sauvegarde pour transférer un serveur d'une machine vers une autre. Il est également possible de mettre en oeuvre la consignation de transactions individuelles par fichier afin de rendre à un serveur l'état qu'il avait avant son arrêt, de sorte qu'il retrouve l'état de synchronisation attendu par les autres serveurs dans un anneau de répliques. Permet de sauvegarder des fichiers liés à eDirectory sur un serveur individuel. Vous pouvez, par exemple, sauvegarder et restaurer des fichiers NICI. Vous pouvez aussi créer votre propre liste de fichiers à inclure dans la sauvegarde. |
|
Possibilité de restaurer des fichiers NICI pour un serveur |
Non conçu pour cela. |
Permet de sauvegarder et de restaurer les fichiers NICI, afin de pouvoir accéder aux données codées après une restauration. Vous pouvez ainsi gagner beaucoup de temps lors de la restauration. |
|
Consignation de transactions individuelles par fichier pour un serveur individuel |
Non conçu pour cela. |
Permet de conserver un enregistrement des transactions dans la base de données depuis la dernière sauvegarde, afin de rétablir un serveur dans l'état où il se trouvait avant son arrêt. Dans un environnement multiserveur, cela vous permet de rendre à un serveur l'état de synchronisation attendu par les autres serveurs. La consignation de transactions individuelles par fichier est désactivée par défaut. Pour plus d'informations, reportez-vous à la Section 15.3, Utilisation des fichiers journaux de transactions individuelles. |
Avant d'effectuer la restauration, vous devez collecter tous les fichiers de sauvegarde en suivant les instructions contenues dans la Section 15.4, Préparation d'une restauration. Lorsque vous demandez à l'outil de sauvegarde de commencer la restauration, à l'aide d'iManager ou de DSBK, celui-ci exécute la procédure suivante :
Il ferme l'agent DS.
Il transforme l'ensemble DIB (Data Information Base) actif nommé NDS en nouvel ensemble DIB nommé RST.
REMARQUE :la base de données NDS existante est conservée sur le serveur. Si la vérification de la restauration échoue, elle redevient l'ensemble DIB actif.
Il effectue la restauration dans l'ensemble DIB nommé RST.
L'ensemble DIB est désactivé.
L'attribut de connexion désactivée est paramétré sur le pseudo-serveur, empêchant ainsi l'agent DS de s'ouvrir avec cet ensemble DIB.
Il rétablit les paramètres par défaut des fichiers journaux de transactions individuelles. Vous pouvez l'en empêcher en utilisant le paramètre -s.
Ainsi, après une restauration, la consignation de transactions individuelles par fichier est toujours désactivée. De plus, l'emplacement par défaut des fichiers journaux de transactions individuelles est rétabli.
REMARQUE :Si vous souhaitez activer la consignation de transactions individuelles par fichier sur le serveur, vous devez prévoir de recréer la configuration appropriée après une restauration afin de vous assurer que cette fonction est activée et que les fichiers journaux sont enregistrés dans un emplacement assurant la tolérance aux pannes. Après avoir activé les journaux de transactions individuelles, vous devez également effectuer une nouvelle sauvegarde complète.
Il vérifie la base de données RST restaurée.
Le serveur tente de vérifier la cohérence des données restaurées. Pour cela, il contacte chaque serveur avec lequel il partage une réplique et compare les vecteurs de transition.
Le résultat de ce processus de vérification est enregistré dans le fichier journal.
Si le vecteur de transition du serveur distant est en avance par rapport au vecteur local, il manque alors des données dans la restauration et la vérification échoue.
Voici un exemple des informations enregistrées dans le fichier journal en cas d'échec de la vérification pour l'une des répliques. Il montre les vecteurs de transition qui ont été comparés :
Server: \T=LONE_RANGER\O=novell\CN=CHIP
Replica: \T=LONE_RANGER\O=novell
Status: ERROR = -6034
Local TV Remote TV
s3D35F377 r02 e002 s3D35F3C4 r02 e002
s3D35F370 r01 e001 s3D35F370 r01 e001
s3D35F363 r03 e001 s3D35F363 r03 e001
s3D35F31E r04 e004 s3D35F372 r04 e002
s3D35F2EE r05 e001 s3D35F2EE r05 e001
s3D35F365 r06 e003 s3D35F365 r06 e003
Pour plus d'informations, reportez-vous à la section Vecteurs de transition et processus de vérification de la restauration.
Si la vérification réussit, RST est renommé NDS et l'attribut de connexion désactivée est effacé, faisant ainsi de RST la base de données eDirectory active sur le serveur. Si la vérification échoue, l'ensemble DIB RST n'est pas renommé et NDS redevient l'ensemble DIB actif.
En cas d'échec de la vérification, reportez-vous à la Section 15.7, Récupération de la base de données en cas d'échec de la vérification de la restauration pour savoir comment récupérer le serveur.
REMARQUE :Il est possible de forcer l'activation et le déverrouillage de la base de données RST à l'aide des options de restauration avancées, mais cela n'est pas conseillé, sauf si NetIQ vous le propose.
Les fichiers de sauvegarde comportent un en-tête que vous pouvez lire pour accéder à des informations importantes, notamment :
Le nom assigné au fichier de sauvegarde lors de sa création.
Cela est utile si le fichier a été renommé depuis la création de la sauvegarde.
Le nom du journal de transaction individuelle en service au moment de la sauvegarde.
S'il s'agit de la dernière sauvegarde du jeu à partir duquel vous effectuez la restauration (par exemple, la dernière sauvegarde incrémentielle d'un ensemble constitué d'une sauvegarde complète et de trois sauvegardes incrémentielles), cette information vous est utile puisqu'elle indique le premier fichier journal de transaction individuelle dont vous avez besoin pour effectuer une restauration complète.
Les répliques que contenait le serveur.
Cette information est utile si vous n'avez pas noté l'emplacement de vos répliques. Si vous êtes confronté à un sinistre dans lequel de nombreux serveurs sont perdus, la liste des répliques figurant dans l'en-tête du fichier de sauvegarde peut vous aider à choisir les serveurs à restaurer en premier.
Les noms des fichiers inclus dans la sauvegarde, listés dans un fichier d'inclusion utilisateur.
Le nombre de fichiers figurant dans le jeu de sauvegarde.
Pour chaque sauvegarde individuelle, l'en-tête du fichier est au format XML. Immédiatement après l'en-tête viennent les données de sauvegarde de la base de données exprimées en code binaire.
REMARQUE :Étant donné que des données binaires sont incluses à la fin du fichier, l'analyse de ce dernier produirait des erreurs. Toutefois, l'en-tête est conforme au standard XML.
Si la sauvegarde s'étend sur plusieurs fichiers, les informations d'en-tête sont incluses dans chacun d'eux.
AVERTISSEMENT :lorsque vous ouvrez un fichier de sauvegarde, contentez-vous de consulter l'en-tête. N'essayez pas d'enregistrer ni de modifier le fichier, car vous risqueriez de l'altérer. La plupart des applications n'enregistrent pas les données binaires correctement.
Voici la partie DTD de l'en-tête XML. Elle est incluse également dans l'en-tête du fichier de sauvegarde, pour référence.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE backup [
<!ELEMENT backup (file|replica)*>
<!ELEMENT file (#PCDATA)>
<!ELEMENT replica EMPTY>
<!ATTLIST backup version CDATA #REQUIRED
backup_type (full|incremental) #REQUIRED
idtag CDATA #REQUIRED
time CDATA #REQUIRED
srvname CDATA #REQUIRED
dsversion CDATA #REQUIRED
compression CDATA "none"
os CDATA #REQUIRED
current_log CDATA #REQUIRED
number_of_files CDATA #IMPLIED
backup_file CDATA #REQUIRED
incremental_file_ID CDATA #IMPLIED
next_inc_file_ID CDATA #IMPLIED>
<!ATTLIST file size CDATA #REQUIRED
name CDATA #REQUIRED
encoding CDATA "base64"
type (user|nici) #REQUIRED>
<!ATTLIST replica partition_DN CDATA #REQUIRED
modification_time CDATA #REQUIRED
replica_type (MASTER|SECONDARY|READONLY|SUBREF|
SPARSE_WRITE|SPARSE_READ|Unknown) #REQUIRED
replica_state (ON|NEW_REPLICA|DYING_REPLICA|LOCKED|
CRT_0|CRT_1|TRANSITION_ON|DEAD_REPLICA|
BEGIN_ADD|MASTER_START|MASTER_DONE|
FEDERATED|SS_0|SS_1|JS_0|JS_1|MS_0|MS_1|
Unknown) #REQUIRED>
]>
Le tableau ci-dessous décrit les attributs que contient cette partie.
|
Attribut |
Explication |
|---|---|
|
backup version |
Version de l'outil de sauvegarde. |
|
backup backup_type |
Type de sauvegarde exécuté (sauvegarde complète ou incrémentielle). Une sauvegarde à froid est une sauvegarde complète. |
|
backup idtag |
Identificateur GUID attribué selon l'heure de la sauvegarde. Il permet d'identifier la sauvegarde, même si le fichier de sauvegarde est renommé. |
|
backup time |
Date et heure à laquelle la sauvegarde a débuté. |
|
backup srvname |
Nom distinctif du serveur sauvegardé. |
|
backup dsversion |
Version d'eDirectory exécutée sur le serveur. |
|
backup compression |
Indique si l'outil de sauvegarde a comprimé les données de sauvegarde. La compression ne s'applique qu'aux données de sauvegarde. L'en-tête n'est jamais comprimé. |
|
backup os |
Système d'exploitation sur lequel la sauvegarde a été exécutée. Nous vous recommandons de ne restaurer que le même système d'exploitation. |
|
backup current_log |
Premier fichier journal de transaction individuelle nécessaire pour restaurer la sauvegarde. Cette information vous permet de collecter l'ensemble de fichiers approprié pour une restauration. |
|
backup number_of_files |
Nombre de fichiers faisant partie du jeu de sauvegarde. Cette valeur figure uniquement dans le premier fichier de sauvegarde. |
|
backup backup_file |
Nom de fichier de la sauvegarde actuelle. Si la sauvegarde s'étend sur plusieurs fichiers, l'en-tête de chaque fichier indique le nom du fichier ainsi que son numéro d'ordre dans le jeu de sauvegarde. Pour un exemple de noms de fichiers de sauvegarde, consultez la description de -s taille_fichier. |
|
backup incremental_file_ID |
S'il s'agit d'une sauvegarde incrémentielle, identificateur (ID) du fichier incrémentiel. |
|
backup next_inc_file_ID |
ID attribué au fichier de sauvegarde incrémentielle suivant lors de sa création. Cette information vous permet de collecter l'ensemble de fichiers approprié pour une restauration. |
|
file size |
Taille des données qui figurent entre les balises <file> du fichier. |
|
file name |
Nom et emplacement du fichier au moment de la sauvegarde. |
|
file encoding |
Algorithme de codage utilisé pour le fichier. |
|
file type |
Indique s'il s'agit d'un fichier NICI ou utilisateur. |
|
Mot de passe |
Spécifie le mot de passe de sauvegarde NICI. Le même mot de passe doit être spécifié pour restaurer les fichiers NICI. |
|
replica partition_DN |
Nom distinctif de la partition. Cette information est utile si vous n'avez pas noté l'emplacement de vos répliques. Si vous êtes confronté à un sinistre dans lequel de nombreux serveurs ont été perdus, la liste des répliques figurant dans l'en-tête du fichier de sauvegarde peut vous aider à choisir les serveurs à restaurer en premier. |
|
replica modification_time |
Vecteur de transition de la réplique au moment de la sauvegarde. |
|
replica replica_type |
Type de réplique (maîtresse ou Lecture seule, par exemple). |
|
replica_state |
État de la réplique au moment de la sauvegarde (Active ou Nouvelle réplique, par exemple). |
Voici un exemple d'en-tête de fichier de sauvegarde d'un serveur Windows. Les fichiers de sécurité NICI sont inclus dans la sauvegarde.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE backup [
<!ELEMENT backup (file|replica)*>
<!ELEMENT file (#PCDATA)>
<!ELEMENT replica EMPTY>
<!ATTLIST backup version CDATA #REQUIRED
backup_type (full|incremental) #REQUIRED
idtag CDATA #REQUIRED
time CDATA #REQUIRED
srvname CDATA #REQUIRED
dsversion CDATA #REQUIRED
compression CDATA "none"
os CDATA #REQUIRED
current_log CDATA #REQUIRED
number_of_files CDATA #IMPLIED
backup_file CDATA #REQUIRED
incremental_file_ID CDATA #IMPLIED
next_inc_file_ID CDATA #IMPLIED>
<!ATTLIST file size CDATA #REQUIRED
name CDATA #REQUIRED
encoding CDATA "base64"
type (user|nici) #REQUIRED>
<!ATTLIST replica partition_DN CDATA #REQUIRED
modification_time CDATA #REQUIRED
replica_type (MASTER|SECONDARY|READONLY|SUBREF|
SPARSE_WRITE|SPARSE_READ|Unknown) #REQUIRED
replica_state (ON|NEW_REPLICA|DYING_REPLICA|LOCKED|
CRT_0|CRT_1|TRANSITION_ON|DEAD_REPLICA|
BEGIN_ADD|MASTER_START|MASTER_DONE|
FEDERATED|SS_0|SS_1|JS_0|JS_1|MS_0|MS_1|
Unknown) #REQUIRED>
]>
<backup version="2" backup_type="full" idtag="3D611DA2" time="2002-8-19'T10:32:35" srvname="\T=MY_TREE\O=novell\CN=DSUTIL-DELL-NDS" dsversion="1041081" compression="none" os="windows" current_log="00000003.log" next_inc_file_ID="2" number_of_files="0000001" backup_file="c:\backup\header.bak"><replica partition_DN="\T=MY_TREE" modification_time="s3D611D95_r1_e2" replica_type="MASTER" replica_state="ON" /><replica partition_DN="\T=MY_TREE\O=part1" modification_time="s3D611D95_r1_e2" replica_type="MASTER" replica_state="ON" /><replica partition_DN="\T=MY_TREE\O=part2" modification_time="s3D611D95_r1_e2" replica_type="MASTER" replica_state="ON" /><replica partition_DN="\T=MY_TREE\O=part3" modification_time="s3D611D96_r1_e2" replica_type="MASTER" replica_state="ON" /><file size="190" name="C:\WINDOWS\system32\novell\nici\bhawkins\XARCHIVE.001" encoding="base64" type="nici">the data is included here</file>
<file size="4228" name="C:\WINDOWS\system32\novell\nici\bhawkins\XMGRCFG.KS2" encoding="base64" type="nici">the data is included here</file>
<file size="168" name="C:\WINDOWS\system32\novell\nici\bhawkins\XMGRCFG.KS3" encoding="base64" type="nici">the data is included here</file>
<file size="aaac" name="C:\WINDOWS\system32\novell\nici\nicintacl.exe" encoding="base64" type="nici">the data is included here</file>
<file size="150" name="C:\WINDOWS\system32\novell\nici\NICISDI.KEY" encoding="base64" type="nici">the data is included here
</file>
<file size="4228" name="C:\WINDOWS\system32\novell\nici\system\Xmgrcfg.ks2" encoding="base64" type="nici">the data is included here
</file>
<file size="168" name="C:\WINDOWS\system32\novell\nici\system\Xmgrcfg.ks3" encoding="base64" type="nici">the data is included here
</file>
<file size="1414" name="C:\WINDOWS\system32\novell\nici\xmgrcfg.wks" encoding="base64" type="nici">the data is included here
</file>
</backup>
Les données binaires de la sauvegarde de la base de données sont ajoutées dans le fichier de sauvegarde à la suite de l’en-tête.
L'outil de sauvegarde d'eDirectory tient à jour un journal qui présente une vue d'ensemble de son activité et comporte des informations sur les sauvegardes antérieures. Le fichier journal contient un historique de toutes les sauvegardes et consigne l'heure de début et de fin de chacune d'entre elles. Il fournit également des informations sur les erreurs survenues éventuellement pendant le processus de sauvegarde. Ce fichier est complété à chaque sauvegarde. Il est également enregistré à l'emplacement que vous désignez.
Le fichier journal permet de s'assurer de la réussite des sauvegardes sans surveillance. Le résultat (réussite ou échec) est indiqué sur la dernière ligne avec le code d'erreur éventuel.
Le fichier journal de l'outil de sauvegarde mentionne également l'ID des sauvegardes qui ont été effectuées, ce qui facilite la collecte des fichiers de sauvegarde complète et incrémentielle corrects en vue d'une restauration. Les quatre premières lignes reprennent les informations de l'en-tête du fichier de sauvegarde.
Les autres fichiers inclus dans la sauvegarde de la base de données, tels que les fichiers NICI ou ceux listés dans un fichier d'inclusion, sont également consignés dans le fichier journal.
Pour une restauration, ce dernier enregistre également les fichiers inclus qui ont été restaurés.
Voici deux exemples d'entrées de fichier journal :
|==================DSBackup Log: Backup================| Backup type: Full Log file name: sys:/backup/backup.log Backup started: 2002-6-21'T19:53:5GMT Backup file name: sys:/backup/backup.bak Server name: \T=VIRTUALNW_TREE\O=novell\CN=VIRTUALNW Current Roll Forward Log: 00000001.log DS Version: 1041072 Backup ID: 3D138421 Backing up security file: sys:/system/nici/INITNICI.LOG Backing up security file: sys:/system/nici/NICISDI.KEY Backing up security file: sys:/system/nici/XARCHIVE.000 Backing up security file: sys:/system/nici/XARCHIVE.001 Backing up security file: sys:/system/nici/XMGRCFG.KS2 Backing up security file: sys:/system/nici/XMGRCFG.KS3 Backing up security file: sys:/system/nici/XMGRCFG.NIF Starting database backup... Database backup finished Completion time 00:00:03 Backup completed successfully |==================DSBackup Log: Restore================| Log file name: sys:/save/doc.log Restore started: 2002-7-19'T19:1:34GMT Restore file name: sys:/backup/backup.bak Starting database restore... Restoring file sys:/backup/backup.bak Restoring file sys:/system/nici/INITNICI.LOG Restoring file sys:/system/nici/NICISDI.KEY Restoring file sys:/system/nici/XARCHIVE.000 Restoring file sys:/system/nici/XARCHIVE.001 Restoring file sys:/system/nici/XMGRCFG.KS2 Restoring file sys:/system/nici/XMGRCFG.KS3 Restoring file sys:/system/nici/XMGRCFG.NIF Database restore finished Completion time 00:00:15 Restore completed successfully
Si vous possédez un environnement multiserveur et souhaitez planifier la reprise après un sinistre entraînant la perte de tous vos serveurs, vous pouvez utiliser des serveurs DSMASTER dans le cadre du plan de restauration de votre arborescence.
L'outil de sauvegarde permet de sauvegarder chaque serveur séparément. Il est axé sur le serveur et non sur l'arborescence. Si toutefois vous créez des serveurs DSMASTER, vous pouvez utiliser les fonctionnalités de l'outil de sauvegarde spécifiquement pour sauvegarder toute la structure de votre arborescence. Un exemple de sauvegarde impliquant des serveurs DSMASTER est présenté dans le scénario Scénario : perte de tous les serveurs dans un environnement multiserveur.
Lors d'une restauration après un sinistre, l'un des principaux problèmes consiste à éviter de restaurer des répliques de la même partition qui ne concordent pas. Si, à la suite d'un sinistre, vous perdez les fichiers journaux de transaction individuelle de vos serveurs, vous ne pourrez pas restaurer tous vos serveurs au même point dans le temps. Sans ces fichiers journaux, les répliques qui se trouvent dans vos sauvegardes ne concordent pas. Cela entraîne des problèmes si elles sont toutes restaurées au même moment et intégrées ensemble à l'arborescence.
REMARQUE :le processus de vérification de la restauration a été conçu pour éviter ces problèmes. Par défaut, une base de données eDirectory restaurée ne s'ouvre pas après une restauration si elle ne concorde pas avec les autres répliques.
Vous pouvez recourir à des serveurs DSMASTER pour vous préparer à cette situation, en créant une copie maîtresse de l'arborescence que vous utiliserez comme point de départ.
Pour utiliser des serveurs DSMASTER en prévision d'un éventuel sinistre :
Organisez vos répliques pour qu'un serveur contienne une réplique de chaque partition de l'arborescence. Ainsi, vous pouvez disposer d'une copie de l'ensemble de l'arborescence dans la base de données eDirectory d'un seul serveur (si l'arborescence est trop grande, vous pouvez utiliser deux serveurs clés). Ce type de serveur est souvent appelé serveur DSMASTER. Les répliques du serveur DSMASTER doivent être de type maîtresse ou Lecture/écriture.
REMARQUE :si vous utilisez deux serveurs DSMASTER clés, gardez à l'esprit que chacun doit en principe disposer d'un ensemble unique de répliques de partitions. Il ne doit pas y avoir de chevauchement pour éviter les incohérences entre les répliques lors de la restauration après un sinistre.
Si un sinistre entraîne la perte de vos serveurs, vous n'aurez pas accès aux derniers fichiers journaux de transactions individuelles pour la restauration ; en effet, ceux-ci sont enregistrés localement sur le serveur, de sorte qu'il sera probablement impossible de restaurer tous les serveurs DSMASTER au même point dans le temps. Si la même réplique est stockée sur deux serveurs DSMASTER, les deux copies ne seront probablement pas identiques, ce qui entraînera des incohérences dans l'arborescence. Pour préparer une reprise après sinistre, il est donc préférable qu'une même partition ne soit pas répliquée sur plusieurs serveurs DSMASTER.
Pour obtenir des informations générales sur les répliques, reportez-vous à la Section 1.6, Répliques.
Sauvegardez régulièrement les serveurs DSMASTER pour créer une copie de sauvegarde de votre arborescence. Il peut en outre être judicieux de prendre des précautions supplémentaires pour le stockage des sauvegardes des serveurs DSMASTER dans le cadre de votre plan de récupération en cas de sinistre.
Si vous concevez ainsi votre arborescence, vous pourrez, en cas de sinistre, rendre rapidement opérationnelle la structure arborescente en restaurant simplement le serveur (ou le petit groupe de serveurs clés) concerné et en vous assurant que les répliques qu'il contient sont désignées comme étant les répliques maîtresses.
Une fois la structure de l'arborescence redevenue opérationnelle, vous pourrez restaurer les autres serveurs perdus en utilisant uniquement les fichiers de sauvegarde complète et incrémentielle. Toutefois, comme vous ne disposez pas des fichiers journaux de transaction individuelle, la vérification de la restauration échoue pour ces autres serveurs. Pour les réintégrer dans l'arborescence, vous devrez les supprimer de l'anneau de répliques, changer en références externes toutes les informations concernant leurs répliques à l'aide de DSRepair, puis leur ajouter de nouveau les répliques en effectuant la réplication à partir de la copie figurant sur le serveur DSMASTER. Ces opérations sont décrites à la Section 15.7, Récupération de la base de données en cas d'échec de la vérification de la restauration.
Si, lors d'un sinistre, vous perdez une grande partie de vos serveurs, la procédure liée aux répliques risque d'être complexe. Dans ce cas, nous vous conseillons de contacter le support technique de NetIQ.
Un vecteur de transition est un tampon horaire pour une réplique. Ce tampon est constitué d'une représentation du nombre de secondes écoulées depuis un point de référence historique commun (1er janvier 1970), du numéro de réplique et du numéro d'événement en cours. Voici un exemple :
s3D35F377 r02 e002
Dans le contexte de la sauvegarde et de la restauration, le vecteur de transition est important, car il sert à vérifier que le serveur restauré est synchronisé avec l'anneau de répliques auquel il participe.
Les serveurs qui contiennent des répliques d’une même partition communiquent entre eux pour que celles-ci restent synchronisées en permanence. Chaque fois qu'un serveur communique avec un autre serveur de l'anneau de répliques, il conserve un enregistrement du vecteur de transition de l'autre serveur au moment de la communication. Les vecteurs de transition permettent aux serveurs d'un anneau de répliques de savoir quelles informations ils doivent envoyer à chacune des répliques de l'anneau pour assurer leur synchronisation. Lorsqu'un serveur s'arrête, il cesse de communiquer. Les autres serveurs ne lui envoient plus de mises à jour et ne modifient plus le vecteur de transition qu'ils ont enregistré pour lui jusqu'à ce qu'il recommence à communiquer.
Lorsque vous restaurez eDirectory sur un serveur, le processus de vérification de la restauration compare le vecteur de transition du serveur en cours de restauration et celui des autres serveurs de l'anneau de répliques. Cela permet de s'assurer que les répliques restaurées sont dans l'état attendu par les autres serveurs.
Si le vecteur de transition du serveur distant est en avance par rapport au vecteur local, il manque alors des données dans la restauration et la vérification échoue. Par exemple, des données peuvent être manquantes pour les raisons suivantes : vous n'avez pas activé la consignation continue de transactions individuelles par fichier avant la dernière sauvegarde complète ou incrémentielle, vous n'avez pas inclus les fichiers journaux de transactions individuelles dans la restauration ou l'ensemble de fichiers journaux que vous avez fourni pour la restauration est incomplet.
Par défaut, la base de données eDirectory restaurée n'est pas ouverte si elle est incohérente par rapport aux autres répliques.
Pour obtenir un exemple d'entrée de fichier journal lorsque des vecteurs de transition ne concordent pas, reportez-vous à la section Présentation du processus de restauration avec l'outil de restauration.
Pour plus d'informations sur la procédure à suivre en cas d'échec de la vérification de la restauration, reportez-vous à la Section 15.7, Récupération de la base de données en cas d'échec de la vérification de la restauration.