Backup eMTool 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. (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. Si vous ne le faites pas, des erreurs se produisent lors de la restauration à partir des fichiers de sauvegarde et la base de données ne s'ouvre pas. Par défaut, la consignation de transactions individuelles par fichier est désactivée. Pour plus d'informations, reportez-vous à la section Utilisation des fichiers journaux de transactions individuelles.
Backup eMTool ne sauvegarde pas tous les objets de eDirectory à la fois, mais seulement les partitions d'un serveur individuel. 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 Quelles sont les différences des fonctions de sauvegarde et de restauration de eDirectory 8.7.3 ?.
Le nouvel outil de sauvegarde de eDirectory doit être utilisé en association avec les sauvegardes du système de fichiers, afin d'enregistrer sur bande les fichiers de sauvegarde de eDirectory, par mesure de sécurité. Novell a établi des partenariats avec plusieurs grands fournisseurs de solutions de sauvegarde. Vous trouverez une liste à la page NetWare Partner Products: Backup, Restore, & Recovery (Produits partenaires NetWare : sauvegarde, restauration et reprise après sinistre).
Sous NetWare, vous devrez peut-être également utiliser l'outil de sauvegarde eDirectory en association avec les sauvegardes des droits du système de fichiers. Pour plus d'informations, reportez-vous à la section Préservation des droits lors de la restauration des données du système de fichiers sous NetWare.
Dans iManager, vous pouvez employer toutes les fonctions, exception faite de la sauvegarde à froid, des sauvegardes sans surveillance et des options de restauration avancées, comme expliqué dans la section Utilisation de Novell iManager pour la sauvegarde et la restauration. Toutes les tâches de sauvegarde et de restauration, y compris les sauvegardes sans surveillance, peuvent être exécutées à partir du client Java à ligne de commande eMBox, comme expliqué dans la section Utilisation du client eMBox pour la sauvegarde et la restauration.
Pour obtenir une description des options de sauvegarde et de restauration dans iManager, consultez l'aide en ligne. Pour une description des options du client eMBox, reportez-vous à la section Options de ligne de commande pour la sauvegarde et la restauration.
Pour obtenir une description du processus de restauration, reportez-vous à la section Présentation du processus de restauration avec Backup eMTool.
eDirectory Backup eMTool fait partie du jeu d'outils eMBox. Installé sur le serveur, eMBox est un service qui fait partie de eDirectory.
Backup eMTool comprend les fichiers suivants :
Pour obtenir une description du format des fichiers de sauvegarde et des fichiers journaux créés par Backup eMTool, reportez-vous aux sections Format du fichier journal de sauvegarde et Format de l'en-tête des fichiers de sauvegarde.
IMPORTANT: Le processus de vérification de la restauration est rétrocompatible avec eDirectory 8.5 et versions ultérieures uniquement. Si vous souhaitez utiliser le nouvel outil de sauvegarde et de restauration sur des serveurs qui font partie d'un anneau de répliques, veillez à les mettre à niveau vers eDirectory 8.5 ou une version ultérieure. (Reportez-vous également à la section Rétrocompatibilité du processus de vérification de la restauration avec eDirectory 8.5 et versions ultérieures uniquement.)
Dans les versions précédentes de eDirectory, les fonctions de sauvegarde et de restauration étaient axées sur la sauvegarde de l'arborescence, objet par objet.
Le nouvel outil Backup eMTool de eDirectory 8.7 a introduit une méthode totalement différente, ainsi qu'une nouvelle architecture. En effet, il est 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.
La sauvegarde des informations propres au serveur a été mise en oeuvre à l'aide de Backup eMTool. Pour plus de détails, reportez-vous à la section Modifications apportées à la sauvegarde des informations propres au serveur (NetWare uniquement).
Pour plus d'informations, consultez le tableau ci-dessous.
Critère | Utilitaire de sauvegarde classique TSA pour NDS | Outil Backup eMTool « Sauvegarde continue à chaud » |
---|---|---|
Objectif |
Conçu pour sauvegarder l'arborescence, objet par objet. Pour plus d'informations sur les utilitaires de sauvegarde classiques (qui sont toujours pris en charge dans eDirectory 8.7 ; les deux types de sauvegarde peuvent au besoin être utilisés), reportez-vous à la section « Backing Up and Restoring Novell eDirectory (Sauvegarde et restauration de Novell eDirectory) » dans le manuel Novell eDirectory 8.6 Administration Guide (Guide d'administration de Novell eDirectory 8.6). |
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 à la suite d'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é dans la section Utilisation de serveurs DSMASTER dans le cadre d'un plan de reprise après sinistre. |
Vitesse |
Non applicable |
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. |
Multiplate-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 individuel 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 restaurer 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. Par défaut, la consignation de transactions individuelles par fichier est désactivée. Pour plus d'informations, reportez-vous à la section 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 Préparation d'une restauration. Lorsque vous demandez à l'outil Backup eMTool de commencer la restauration, à l'aide de iManager ou du client eMBox, celui-ci exécute la procédure suivante :
(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 applique l'attribut de login désactivé sur le pseudo-serveur, ce qui empêche l'agent DS de s'ouvrir avec cet ensemble DIB.
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.
(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 fichiers journaux de transactions individuelles, vous devez également effectuer une nouvelle sauvegarde complète.)
Le serveur tente de vérifier la cohérence des données restaurées. Pour ce faire, 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.
En cas d'échec de la vérification, reportez-vous à la section 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. (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 Novell vous le propose.)
Les fichiers de sauvegarde comportent un en-tête que vous pouvez lire pour accéder à des informations importantes, notamment :
Cela est utile si le fichier a été renommé depuis la création 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.
Cette information est utile si vous n'avez pas noté l'emplacement de vos répliques. Si vous êtes confronté à un sinistre impliquant la perte de nombreux serveurs, la liste des répliques figurant dans l'en-tête du fichier de sauvegarde peut vous aider à choisir les serveurs à restaurer en premier.
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. (É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.
WARNING: 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 il pourrait alors devenir tronqué. La plupart des applications ne peuvent pas enregistrer correctement les données binaires.
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 de eDirectory exécutée sur le serveur. |
backup compression |
Indique si Backup eMTool a comprimé les données de sauvegarde. La compression ne s'applique qu'aux données ; 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, voir -s f ile_size. |
backup incremental_file_ID |
S'il s'agit d'une sauvegarde incrémentielle, cet attribut représente l'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. |
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 impliquant la perte de nombreux serveurs, 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 NT. 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:\WINNT\system32\novell\nici\bhawkins\XARCHIVE.001" encoding="base64" type="nici">the data is included here</file>
<file size="4228" name="C:\WINNT\system32\novell\nici\bhawkins\XMGRCFG.KS2" encoding="base64" type="nici">the data is included here</file>
<file size="168" name="C:\WINNT\system32\novell\nici\bhawkins\XMGRCFG.KS3" encoding="base64" type="nici">the data is included here</file>
<file size="aaac" name="C:\WINNT\system32\novell\nici\nicintacl.exe" encoding="base64" type="nici">the data is included here</file>
<file size="150" name="C:\WINNT\system32\novell\nici\NICISDI.KEY" encoding="base64" type="nici">the data is included here
</file>
<file size="4228" name="C:\WINNT\system32\novell\nici\system\Xmgrcfg.ks2" encoding="base64" type="nici">the data is included here
</file>
<file size="168" name="C:\WINNT\system32\novell\nici\system\Xmgrcfg.ks3" encoding="base64" type="nici">the data is included here
</file>
<file size="1414" name="C:\WINNT\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.
eDirectory Backup eMTool 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 Backup eMTool mentionne également l'ID des sauvegardes 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 aussi 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 Backup eMTool s'emploie pour 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 Backup eMTool pour sauvegarder toute la structure de votre arborescence. Un exemple de sauvegarde impliquant des serveurs DSMASTER est présenté à la section 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 transactions individuelles de vos serveurs, vous ne pouvez pas restaurer ces derniers 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. (Le processus de vérification de la restauration a pour but d'é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 :
NOTE: 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 Répliques.
Si vous concevez votre arborescence de cette façon, en cas de sinistre, la structure de l'arborescence pourra rapidement redevenir opérationnelle ; il vous suffira de restaurer le serveur concerné (ou le petit groupe de serveurs clés) et de vous assurer que les répliques qu'il contient sont bien celles désignées comme 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. Cependant, comme vous ne disposez pas des fichiers journaux de transactions individuelles, 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 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 Novell.
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. En 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 les anneaux de répliques auxquels 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 les vecteurs de transition ne concordent pas, reportez-vous à la section Présentation du processus de restauration avec Backup eMTool.
Pour obtenir une description des problèmes de compatibilité pouvant faire échouer la vérification de la restauration, reportez-vous à la section Rétrocompatibilité du processus de vérification de la restauration avec eDirectory 8.5 et versions ultérieures uniquement.
Pour plus d'informations sur la procédure à suivre en cas d'échec de la vérification de la restauration, reportez-vous à la section Récupération de la base de données en cas d'échec de la vérification de la restauration.
Le processus de vérification de la restauration est rétrocompatible avec eDirectory 8.5 et versions ultérieures uniquement. Si le serveur que vous restaurez partage une réplique avec un serveur qui exécute une version de eDirectory antérieure à 8.5, le journal de restauration indique l'erreur -666 (version DS incompatible) pour cette réplique. Cela n'indique pas si les répliques sont désynchronisées ; cette erreur signifie simplement que le processus de vérification de la restauration ne peut pas comparer les vecteurs de transition étant donné que la version de eDirectory est antérieure à 8.5.
Par défaut, la base de données ne s'ouvre pas car la vérification de la restauration ne s'est pas déroulée correctement. Dans ce cas, faites appel à votre bon sens. Si la seule erreur provient d'un serveur 8.5 et si les autres serveurs ont été correctement vérifiés, vous pouvez choisir d'ouvrir la base de données en sélectionnant l'option de remplacement de la restauration, disponible dans le client eMBox.
Vous pouvez aussi supprimer de l'anneau de répliques le serveur exécutant une version antérieure, puis recommencer la restauration.
Pour plus d'informations sur le processus de restauration et les vecteurs de transition, reportez-vous aux sections Présentation du processus de restauration avec Backup eMTool et Vecteurs de transition et processus de vérification de la restauration.
Sous NetWare uniquement, la restauration des droits du système de fichiers (appelés aussi assignations d'ayant droit) dépend de l'objet qui est l'ayant droit actuel dans eDirectory. Compte tenu de cette relation, vous devez procéder avec précaution lorsque vous restaurez eDirectory et les données du système de fichiers sous NetWare, afin de préserver les droits du système de fichiers.
Si vous restaurez eDirectory avant les données du système de fichiers, les droits du système de fichiers devraient normalement être préservés lors de la restauration des données. Vous devez néanmoins être conscient des problèmes Recherchez les problèmes éventuels et prenez des mesures préventives au besoin.
Dans le cadre de votre préparation à la restauration de eDirectory, vous devez procéder à une nouvelle installation de eDirectory en créant une arborescence temporaire, soit sur un nouveau périphérique de stockage destiné à remplacer l'unité défaillante qui contenait le volume sys:, soit sur une nouvelle machine, si vous faites migrer un serveur d'une machine vers une autre.
Une nouvelle installation de eDirectory ne contient pas les objets auxquels des droits d'ayant droit ont été assignés. (Il va de soi que les objets seront restaurés lors de la restauration de eDirectory.)
Lors de la restauration des données du système de fichiers, le processus de restauration recherche les objets ayants droit dans eDirectory. Si un objet désigné comme ayant droit n'existe pas dans la base de données eDirectory (comme dans le cas d'une nouvelle installation avant la restauration de eDirectory), il se peut que les assignations de droits de cet objet soient supprimées du système de fichiers.
Pour résoudre les problèmes liés aux restaurations et aux droits du système de fichiers/assignations d'ayant droit, vous disposez de plusieurs méthodes différentes :
Vous pouvez effectuer une nouvelle installation et restaurer eDirectory sans prendre de mesures particulières, puis, une fois eDirectory restauré, prévoir d'effectuer une restauration du système de fichiers pour tous les fichiers pour lesquels vous devez rétablir des droits/assignations d'ayant droit.
Vous pouvez planifier des sauvegardes des droits/assignations d'ayant droit du système de fichiers à intervalles réguliers, comme vous le faites pour eDirectory et le système de fichiers.
NOTE: vous pouvez planifier la sauvegarde des droits du système de fichiers à l'aide d'un logiciel tiers, ou de cron.nlm, disponible sur le site Web du support Novell.
Pour cela, vous pouvez déconnecter les périphériques de stockage du serveur avant la nouvelle installation de NetWare et de eDirectory, puis les reconnecter une fois eDirectory restauré.
Après la restauration de eDirectory, vous pouvez, au besoin, restaurer le système de fichiers du volume sys:, pour récupérer les droits sur ce volume.