Backup eMTool permet d'effectuer une sauvegarde continue à chaud d'une base de données eDirectory sur un serveur individuel. Si vous sauvegardez eDirectory sur votre serveur sans fermer la base de données, vous disposez 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 interruption. Vous devez activer cette consignation pour les serveurs qui font partie d'un anneau de répliques, afin de pouvoir rétablir un serveur dans 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 à Utilisation des 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 d'un serveur et des sauvegardes plus rapides qu'avec la sauvegarde TSA pour NDS classique (celle-ci continue de fonctionner comme il est expliqué dans eDirectory 8.6 ; vous pouvez l'employer avec la nouvelle fonction de sauvegarde, si nécessaire). Pour plus d'informations sur les comparaisons, reportez-vous à Quelles différences les fonctions de sauvegarde et de restauration de eDirectory 8.7.3 présentent-elles ?.
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 d'exemples dans la page Backup Partners (Partenaires pour la sauvegarde).
Sous NetWare, vous devrez peut-être également utiliser l'outil de sauvegarde eDirectory en association avec les sauvegardes des droits sur le système de fichiers. Pour plus d'informations, reportez-vous à 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 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 il est 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 à Options de ligne de commande pour la sauvegarde et la restauration.
Pour obtenir une description du processus de restauration, reportez-vous à Présentation du processus de restauration avec Backup eMTool.
eDirectory Backup eMTool fait partie du jeu d'outils eMBox. eMBox est un service, installé sur le serveur, qui fait partie de eDirectory.
Backup eMTool comprend les fichiers suivants :
Pour obtenir une description du format des fichiers de sauvegarde et des fichiers journal créés par Backup eMTool, reportez-vous à 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 offre une compatibilité ascendante avec eDirectory 8.5 et les 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 à mettre à niveau ceux-ci avec eDirectory 8.5, ou une version plus récente (Reportez-vous également à Le processus de vérification de la restauration offre une compatibilité ascendante avec eDirectory 8.5 et les 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 la sauvegarde TSA pour NDS existante.
Vous pouvez continuer d'utiliser celle-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 à Modifications apportées à la sauvegarde des informations propres au serveur (NetWare uniquement).
Pour plus d'informations, reportez-vous au tableau ci-dessous.
| Critère | Sauvegarde TSA pour NDS existante | Backup eMTool "Sauvegarde continue à chaud" |
|---|---|---|
Objectif |
Conçue pour sauvegarder l'arborescence, objet par objet. Pour plus d'informations sur les utilitaires de sauvegarde existants (qui sont toujours pris en charge dans eDirectory 8.7 ; les deux types de sauvegarde peuvent être utilisés en cas de besoin), reportez-vous à "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çue 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é dans Utilisation de serveurs DSMASTER dans le cadre d'un plan de récupération en cas de 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çue 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 à une autre. Il est également possible de mettre en oeuvre la consignation de transactions individuelles par fichier afin de rétablir un serveur dans l'état où il se trouvait 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çue 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çue 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 rétablir un serveur dans 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 à Utilisation des journaux de transactions individuelles. |
Avant d'effectuer la restauration, vous devez collecter tous les fichiers de sauvegarde en suivant les instructions contenues dans 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.)
L'attribut de login désactivé est appliqué 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 journaux de transactions individuelles est rétabli.
(Si vous voulez 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 la fonction est en service et que les journaux sont enregistrés à un emplacement permettant d'assurer une tolérance aux pannes. Après avoir activé les 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 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 si la vérification échoue 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 à Vecteurs de transition et processus de vérification de la restauration.
En cas d'échec de la vérification, reportez-vous à 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 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 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.
Pour chaque sauvegarde individuelle, l'en-tête du fichier est au format XML. Immédiatement après l'en-tête vient la sauvegarde de la base de données en code binaire. (Du fait 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 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_type |
Type de sauvegarde exécuté (sauvegarde complète ou incrémentielle). (Une sauvegarde à froid est une sauvegarde complète.) |
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é. |
time |
Date et heure à laquelle la sauvegarde a débuté. |
srvname |
Nom distinctif du serveur sauvegardé. |
dsversion |
Version de eDirectory exécutée sur le serveur. |
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é. |
os |
Système d'exploitation avec lequel la sauvegarde a été exécutée. Nous vous recommandons de ne restaurer que le même système d'exploitation. |
current_log |
Premier journal de transactions individuelles nécessaire pour restaurer la sauvegarde. Cette information vous permet de collecter l'ensemble de fichiers approprié pour une restauration. |
number_of_files |
Nombre de fichiers faisant partie du jeu de sauvegarde. Cette valeur figure uniquement dans le premier fichier de sauvegarde. |
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. Vous trouverez un exemple de noms de fichiers de sauvegarde dans -s f ile_size. |
incremental_file_ID |
S'il s'agit d'une sauvegarde incrémentielle, identificateur (ID) du fichier incrémentiel. |
next_inc_file_ID |
Identificateur (ID) du fichier de sauvegarde incrémentielle suivant assigné à 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 si le fichier est un fichier NICI ou un fichier ajouté par l'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 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 provenant 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 contient également des informations sur les erreurs survenues éventuellement pendant le processus de sauvegarde. Ce fichier reçoit des informations à chaque sauvegarde. Il est également enregistré à l'emplacement que vous désignez.
Le fichier journal est utile pour vérifier si les sauvegardes sans surveillance ont réussi. Le résultat est indiqué sur la dernière ligne et accompagné du code d'erreur en cas d'échec.
Le fichier journal de Backup eMTool 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 spécifié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 récupération 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 vous créez des serveurs DSMASTER toutefois, vous pouvez utiliser les fonctionnalités de Backup eMTool pour sauvegarder toute la structure de votre arborescence. Vous trouverez un exemple de sauvegarde impliquant des serveurs DSMASTER dans Scénario : perte de tous les serveurs dans un environnement multiserveur.
Lors d'une restauration après un sinistre, le principal problème qui se pose consiste à éviter de restaurer des répliques de la même partition qui ne concordent pas. Si en raison d'un sinistre vous perdez les journaux de transactions individuelles de vos serveurs, vous ne pouvez pas restaurer ces derniers au même point dans le temps. Sans ces 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 :
REMARQUE : si vous utilisez deux serveurs clés DSMASTER au lieu d'un, sachez que chacun doit en principe disposer d'un ensemble unique de répliques des 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.
En cas de perte de vos serveurs suite à un sinistre, vous n'auriez pas accès aux journaux de transactions individuelles les plus récents pour effectuer une restauration ; en effet, ceux-ci sont enregistrés localement sur le serveur, de sorte qu'il serait probablement impossible de restaurer tous les serveurs DSMASTER au même moment. Si la même réplique était stockée sur deux serveurs DSMASTER, les deux copies ne seraient probablement pas identiques, entraînant des incohérences dans l'arborescence. Pour préparer une récupération en cas de 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 à Répliques.
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 que la structure de l'arborescence est à nouveau opérationnelle, vous pouvez restaurer les autres serveurs perdus en utilisant uniquement les fichiers de sauvegarde complète et incrémentielle. Cependant, comme vous ne disposez pas des journaux de transactions individuelles, la vérification de la restauration échoue pour ces autres serveurs. Pour les réintégrer dans l'arborescence, vous devez les retirer de l'anneau de répliques, changer en références externes toutes les informations relatives à leurs répliques à l'aide de DSRepair, puis leur ajouter à nouveau les répliques en effectuant la réplication à partir de la copie figurant sur le serveur DSMASTER. Ces opérations sont décrites dans 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, sachez que la procédure liée aux répliques peut être complexe. Dans ce cas, il vous est conseillé de contacter le support 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 détiennent 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 qu'avait 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 à celui détenu par les 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. (Il se peut, par exemple, que des données manquent 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 journaux de transactions individuelles dans la restauration ou l'ensemble de 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 à 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 à Le processus de vérification de la restauration offre une compatibilité ascendante avec eDirectory 8.5 et les 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 à 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 offre une compatibilité ascendante avec eDirectory 8.5 et les 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 à la version 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 du fait que la version de eDirectory est antérieure à la version 8.5.
Par défaut, la base de données ne s'ouvre pas car 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 la vérification des autres serveurs s'est correctement déroulée, 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 retirer 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 à 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 sur le 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 le système de fichiers sous NetWare, afin de préserver les droits sur le système de fichiers.
Si vous restaurez eDirectory avant de restaurer les données du système de fichiers, les droits sur ce dernier doivent être préservés lors de la restauration des données. Vous devez néanmoins y penser. Recherchez les problèmes éventuels et prenez des mesures préventives si nécessaire.
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 une nouvelle unité de stockage destinée à 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. (Bien évidemment, 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 retirées du système de fichiers.
Pour résoudre les problèmes liés aux droits sur le système de fichiers et aux 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 sur le système de fichiers à intervalles réguliers, comme vous le faites pour eDirectory et le système de fichiers.
REMARQUE : vous pouvez planifier la sauvegarde des droits sur le système de fichiers à l'aide d'un logiciel tiers, ou de cron.nlm, disponible sur le site Web de support Novell.
Pour cela, vous pouvez déconnecter les unités de stockage du serveur avant la nouvelle installation de NetWare et de eDirectory, puis les reconnecter une fois la restauration de eDirectory terminée.
Après la restauration de eDirectory, vous pouvez, si nécessaire, effectuer une restauration du système de fichiers du volume sys:. pour récupérer les droits sur le volume SYS:.