eDirectory Backup eMTool

     

The eDirectory Backup eMTool allows you to back up and restore the eDirectory database and associated files on an individual server. It has the following benefits:

• Same tool for all platforms supported by eDirectory 8.7 and later.

• Provides hot continuous backup. You can back up your server without closing the eDirectory database, and you still get a complete backup.

• Supports a quick restore of an individual server. This is especially helpful in the event of hardware failure.

• Scalability. You can back up a server whose eDirectory database contains tens or hundreds of millions of objects. The speed of the backup process is limited mainly by I/O channel bandwidth.

• Can support a quick restore of the tree, when used with replica planning and DSMaster servers. Even without using DSMaster servers, some level of recovery for the tree should be possible.

• Lets you perform tasks remotely. You can perform most backup and restore tasks using iManager or the Java eMBox Client.

• Lets you back up related files. You can back up files on the server that are related to the database, such as Novell International Cryptographic infrastructure (NICI) security files, stream files, and any files you specify (such as AUTOEXEC.NCF ).

• Can restore eDirectory to the state it was in at the moment before it went down, if you use continuous roll-forward logging.

• Makes hardware upgrade simpler. Doing a cold backup and then restoring the eDirectory database is an easy way to transfer the server's identity to a new machine or safeguard it while you make changes such as hardware upgrades.

• Works within the distributed nature of eDirectory. You can ensure that a restored server matches the synchronization state that other servers in the tree expect by turning on continuous roll-forward logging.

• Allows unattended backups. You can create batch files to run unattended backups through the eMBox Client.

REAL WORLD: What Is a DSMaster Server?

It is not uncommon for large sites to have one or more servers that contain a replica of every partition in the tree, so a copy of the whole tree is in the eDirectory database on just a few servers. This kind of server is often called a DSMaster server. The replicas on the DSMaster server should be Master or Read/Write replicas ( generally Master, thus the name "DSMaster server").

If more than one DSMaster server is used, keep in mind that ideally each DSMaster server should have a unique set of replicas of partitions. There should be no overlap between them, to avoid inconsistencies between the replicas when restoring after a disaster. If your servers were lost in a disaster, you would not have access to the most recent roll-forward logs for restoring because roll-forward logs are saved locally on the server, so all the DSMaster servers probably could not be restored to the same moment in time. If the same replica were held on two DSMaster servers, the two copies would probably not be identical and would cause inconsistencies in the tree. So, for disaster recovery planning it's best to not have the same partition replicated on more than one DSMaster server.

Even though there are many nice features and benefits in the eDirectory Backup eMTool, it also has some drawbacks to be aware of. The main drawback is that it only deals with the database and associated files on an individual server; it does not support backup and restore for individual objects, branches of the tree, or the whole tree. Therefore, unless you have a single-server eDirectory tree or are making use of DSMaster servers, you will need an SMS-compliant backup solution to fully back up the tree whose partitions are distributed on more than one server. In essence, eDirectory Backup eMTool provides the same functionality as SSI data but with enhancement features.

TIP

For a Unix-only eDirectory tree, you can use ndsbackup to back up and restore individual objects, branches of the tree, or the full tree, including schema.

The second drawback is that eDirectory Backup eMTool must be used in conjunction with file system backups to put the eDirectory files safely on tape. Another drawback is that for a multiple-server tree, to back up a server you need to upgrade all the servers that are in the same replica ring to eDirectory 8.5 or later. This is because the restore verification process is backward compatible only with 8.5 or later.

Lastly, the eDirectory Management Tool Box (eMBox), of which eDirectory Backup eMTool is a component, depends on RBS to function. Should something unforeseen happen to the RBS configuration, you are unable to access the Backup eMTool. Although not likely if you plan your partition replication strategy properly, you might get yourself into a Catch-22 situation where you need to use Backup eMTool to restore your eDirectory DIB but the only replica containing the RBS containers is in the DIB that you are trying to restore.

TIP

It is sufficient to install iManager on just one server in the tree, launch iManager from that server, and then perform most functions on many objects in the tree. iManager makes calls to eDirectory when creating or modifying objects. eDirectory is responsible for finding the object in the tree and performing the specific function. This is independent of whether or not iManager is installed on other servers in the tree.

The only requirement when performing server-centric eMBox tool functions (such as backup, DSRepair, and so on) through iManager or the eMBox Client is that the server you are trying to perform this function on must have eDirectory 8.7 or later installed.

Overview of Backup eMTool Restore Process

When you direct the Backup eMTool to begin the restore process, either through iManager or the eMBox Client, the following steps are taken by the Backup eMTool:

1. The DS Agent is closed.
   
   
2. The current active DIB set is switched from the DIB set with filename extension .NDS to a new DIB set named .RST . (The existing DS database is left on the server; if the restore verification fails it will once again become the active DIB set.)
   
   
3. The restore is performed, restoring to the DIB set named .RST .
   
   
4. The DIB set is disabled by setting a Login Disabled attribute on the [Pseudo Server] object. This prevents the DS Agent from being able to open and using this DIB set.
   
   
5. The roll-forward log settings are reset to the default. This means that after a restore, roll-forward logging on the server is always set to Off,
   
   
6. and the location of the roll-forward logs is reset to the default ( drive :\Novell\NDS\DIBFiles\nds.rfl ). (If you want roll-forward logging turned on for this server, you must re-create your configuration for roll-forward logging after the restore, to make sure it is turned on and the logs are being saved in a fault-tolerant location. After turning on the roll-forward logs, you must also do a new full backup.)
   
   
6. Verification of the restored .RST database is performed. The server attempts to verify the consistency of the data that has been restored. It does this by contacting every server that it shares a replica with and comparing the transitive vectors. The output from this verification process is printed in the log file. If the transitive vector on the remote server is ahead of the local vector, then data is missing from the restore, and the verification fails. For more information about the verification process, see the following section, "Transitive Vectors and the Restore Verification Process."
   
   Here is an example of the information that's recorded in the log file if verification fails for one of the replicas, showing the transitive vectors that were compared:
   
   

    Server: \T=EDIR-873-TEST-TREE\O=XYZCorp\CN=WIN2K-A    Replica: \T=EDIR-873-TEST-TREE\O=XYZCorp       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 

   
   
7. If verification is successful, .RST is renamed to .NDS and the login disabled attribute is cleared so it becomes the active eDirectory database on the server. If verification fails, the .RST DIB is not renamed, and the active DIB set is set back to .NDS .
   
   

The restore verification process is backward compatible only with eDirectory 8.5 or later (due to the transitive vector requirement). If the server you are restoring participates in a replica ring with a server running a version of NDS earlier than eDirectory 8.5, the restore log will show a -666 error (incompatible DS version) for that replica. This does not indicate whether the replicas are out of sync; it merely indicates that the restore verification was unable to compare the transitive vectors because the version of eDirectory was earlier than 8.5. When this happens, the database will not open (by default) because the restore verification was not completely successful. If in your best judgment, however, it is safe to open the database, you can use the override restore option in the eMBox Client to make the restored DIB active. Refer to the later section "Recovering the DIB if Restore Verification Fails" on how to recover the server from a failed restore verification process.

Transitive Vectors and the Restore Verification Process

A transitive vector is a time stamp for a replica. The vector consists of the number of seconds since midnight of January 1, 1970 (a common reference point used by all DS-related time functions), the replica number, and the current event number. Here's an example of a transitive vector:

 s3D35F377 r02 e002 

In the context of backup and restore, it's important because the transitive vector is used to verify that the server restored is in sync with the replica rings it participates in.

Servers that hold replicas of the same partition communicate with each other to keep the replicas synchronized. Each time a server communicates with another server in the replica ring, it keeps a record of the transitive vector the other server had when they communicated. These transitive vectors allow the servers in a replica ring to know what information needs to be sent to each replica in the ring to keep all the replicas synchronized. When a server is unavailable, it stops communicating, and the other servers don't send updates or change the transitive vector they have recorded for that server until the server starts communicating again.

When you restore eDirectory on a server, the restore verification process compares the transitive vector of the server being restored to the other servers in the replica ring. This is done to make sure the replicas being restored are in the same state the other servers expect.

If the transitive vector on the remote server is ahead of the local vector, then data is missing from the restore, and the verification fails. As an example, data might be missing because you did not turn on continuous roll-forward logging before the last full or incremental backup, you did not include the roll-forward logs in the restore, or the set of roll-forward logs you provided for the restore was not complete.

Hot Continuous Backup and Roll-Forward Logs

The eDirectory Backup eMTool provides hot continuous backup of the eDirectory database on an individual server. This feature allows you to back up eDirectory on your server without closing the database and still get a complete backup that is a snapshot of the moment when the backup began . This means you can create a backup at any time and eDirectory will remain accessible by your users and other clients throughout the process. Hot continuous backup is the default behavior.

The Backup eMTool also lets you turn on roll-forward logging to keep a record of transactions in the database since the last backup. This allows you to restore a server to the state it was in at the moment before it went down. In a single-server environment, roll-forward logging is not required for the restore verification process, but the log files enable you to restore eDirectory to the moment before it went down instead of just to the last backup. In a multiserver tree, however, you must turn on roll-forward logging for all servers that participate in a replica ring, so that you can restore a server to the synchronization state that the other servers expect. If you don't, then when you try to restore from your backup files you will get errors and the database will not open. Roll-forward logging is off by default.

NOTE

The concept of Backup eMTool's hot backup plus roll-forward logging is not new. It is essentially the same as that of the full data backup plus incremental backups you are accustomed to when dealing with file system backups. The difference is that roll-forward log files contain a history of changes since the last full or incremental backup.

eDirectory automatically creates a record of transactions in a log file before committing them to the database. By default, the log file for these records is reused over and over (consuming only a small amount of disk space), and the history of changes to the eDirectory database is not saved. When you turn on continuous roll-forward logging, the history of changes is saved in a set of consecutive roll-forward log files. Roll-forward logging does not reduce server performance; it simply saves the log file entries that eDirectory is already creating.

When using the continuous roll-forward logging feature, you must be aware of the following issues:

• Turn on roll-forward logging before a backup is done. This enables you to use this feature for restoring the database.

• For fault tolerance, make sure that the roll-forward logs are placed on a different storage device than eDirectory. For security, you should also restrict user rights to the logs.

• Document the location of the roll-forward logs so you can backup the log files to tape.

• Monitor the available disk space where the logs are located. If you run out of disk space and roll-forward logs cannot be created, eDirectory will stop responding ”much like the situation with legacy versions of NDS when NetWare's Transaction Tracking System (TTS) shuts down.

• If the logs are turned off or lost, turn them back on, then do a new full backup to ensure that you can make a full recovery.

• If you turn on logging of stream files, the roll-forward logs use up disk space much more quickly. When logging of stream files (such as login scripts or any attribute that uses the SYN_STREAM syntax) is turned on, the whole stream file is copied into the roll-forward log every time there is a change. You can slow the growth of the log files by turning off roll-forward logging of stream files and, instead, back them up only when you do an incremental or full backup.

• Don't change the name of a roll-forward log file. If the filename is different than when the log was created, the log file can't be used in a restore.

Removal of eDirectory from a server also removes all the roll-forward logs. If you want to be able to use the logs for restoring in the future, copy the roll-forward logs to another location before removing eDirectory.

Configuring and Maintaining Roll-Forward Logs

The roll-forward log feature is off by default. It is easiest to use iManager for this task. Follow these steps to enable roll-forward logging on a given server:

1. Log into iManager as a user with Supervisor rights.
   
   
2. Click the Roles and Tasks button.
   
   
3. Click eDirectory Maintenance, Backup Configuration.
   
   
4. Specify the server that you want to configure and click Next .
   
   
5. If not already authenticated to the server, you will be prompted for a username and password. Enter the requested information and click Next.
   
   
6. The Backup Configuration Wizard (see Figure 8.22) is displayed showing the current setting.
   
   

   Figure 8.22. Configuring roll-forward logging.

   
   
7. Change the status of Roll-forward logging to On.
   
   
8. Specify a Roll-forward logs directory. For fault-tolerance purposes, this directory should be on a separate drive or volume than where eDirectory is installed.
   
   
9. Set maximum and minimum file sizes as desired.
   
   
10. Click Start to save the new settings.
    
    
11. Document your settings.
    
    

You need to do this for every server that you want to use roll-forward logging on.

We strongly suggest that you periodically back up the log files and remove unused logs from the server to free up disk space. Use the following procedure to identify, back up, and remove roll-forward logs that are safe to remove:

1. Make a note of the name of the last unused roll-forward log. You can find out the name of the last unused roll-forward log in the following ways:
   
   

   • In iManager, click eDirectory Maintenance, Backup Configuration and read the filename displayed, as shown in Figure 8.23.

     Figure 8.23. Determining the name of the last unused roll-forward log.

     
     

   • In the eMBox Client, use the backup.getconfig command in the interactive mode. If using the GUI mode, backup, Retrieve backup configuation, Run.

     The last unused roll-forward log is the most recent roll-forward log the database has completed and is no longer using to record transactions. It's called the last unused roll-forward log because the database has finished writing to it and has begun a new log file so it does not need to have this one open any more. The current roll-forward log in which the database is recording transactions is in use and is still needed by the database.

2. Do a file system backup of the roll-forward logs to put them all safely on tape.
   
   
3. Manually remove the roll-forward logs that are older than the last unused roll-forward log.
   
   

WARNING

Be cautious when removing roll-forward logs from the server. Check to ensure you have a backup copy of the log files before you delete them.

The last unused roll-forward log simply indicates which file the database has just completed and closed. It does not mean it's safe to remove that file from the server. You must make sure that you remove only files that you have a tape backup for.

Although Backup eMTool is rather easy to use and more powerful than the former SSI option, there is quite a bit of manual maintenance work in regard to the roll-forward log files.

Backing Up a Server Using Backup eMTool

The eDirectory Backup eMTool can back up data from an eDirectory database to one or more files on the server where the backup is being performed. You can do a full or incremental backup. The backup files contain information necessary to restore eDirectory to the state it was in at the time of the backup. The results of the backup process are written to the log file you specify.

Backups performed using iManager are hot continuous backups, meaning that the eDirectory database is kept open and accessible during the process, and you still get a complete backup that is a snapshot of the moment when the backup began. To perform a cold backup (a backup with the database closed) or an unattended backup, you must use the eMBox Client.

The following steps illustrate how to back up a server using iManager:

1. Log into iManager as a user with Supervisor rights.
   
   
2. Click the Roles and Tasks button.
   
   
3. Click eDirectory Maintenance, Backup.
   
   
4. Specify the server that you want to backup and click Next.
   
   
5. If not already authenticated to the server, you will be prompted for a username and password. Enter the requested information and click Next.
   
   
6. Specify the backup file options, such as full, incremental and name and location of the backup file (see Figure 8.24), optionally a maximum file size for the backup data file, and then click Next.
   
   

   Figure 8.24. Server backup options.

   
   

   NOTE

   When a maximum file size is specified, after the first file (whose name is what you specified) has reached the specified file size, subsequent files are created as filename . xxxxx , where xxxxx ranges from 00001 to FFFFF.

7. Specify whether to include NICI files in the backup. Novell recommends that you always include NICI files.
   
   
8. Specify whether to include stream files in the backup.
   
   
9. Specify any additional files to back up via an include file. This include file is a text file that exists on the file system of the server you are backing up and contains a list of semicolon-separated files.
   
   

   WARNING

   The filenames must not have any spaces or hard returns between each entry and the last entry must have a semicolon after its name; embedded spaces within a filename is okay. For example, SYS:SYSTEM\AUTOEXEC.NCF;SYS:PUBLIC\CUSTOM_APP.EXE; .

10. Click Start.
    
    

TIP

To make it easier to move the backup files to another storage device, you can specify the maximum size of eDirectory backup files. You can also use a third-party file compression tool (for instance, HRZIP. NLM on NetWare [ www.novell.com/coolsolutions/tools/1099.html ]; WinZIP on Windows; gzip on Unix) on the files after they are created. The backup files can be compressed by approximately 80%.

The backup log file contains a list of files that were backed up, such as the NICI files and any files you specified using an include file. The log file looks similar to the following:

 ==================DSBackup Log: Backup================ Backup type: Full Log file name: d:\backups\fullbackup.log Backup started: 2004-4-11'T19:59:45 Backup file name: d:\backups\fullbackup.data Server name: \T=W2K-873-TEST-TREE\O=XYZCorp\CN=W2KC-NDS Current Roll Forward Log: 00000001.log DS Version: 1055098 Backup ID: 4079DBF1 Backing up security file: C:\WIN2K\nici\NICIFK Backing up security file: C:\WIN2K\nici\nicintacl.exe Backing up security file: C:\WIN2K\nici\NICISDI.KEY Backing up security file: C:\WIN2K\nici\system\Xmgrcfg.ks2 Backing up security file: C:\WIN2K\nici\system\Xmgrcfg.ks3 Backing up security file: C:\WIN2K\nici\XARCHIVE.000 Backing up security file: C:\WIN2K\nici\XMGRCFG.NIF Backing up security file: C:\WIN2K\nici\xmgrcfg.wks Backing up file: c:\info\backup-1.pcx Backing up file: c:\info\backup-3.pcx Backing up file: c:\info\backup-2 Temp.pcx Starting database backup... Starting new file: d:\backups\fullbackup.data.00001 Starting new file: d:\backups\fullbackup.data.00002 Starting new file: d:\backups\fullbackup.data.00003 Starting new file: d:\backups\fullbackup.data.00004 Database backup finished Completion time 00:04:12 Backup completed successfully 

Make sure you do a file system backup shortly after the eDirectory backup is created, to put the eDirectory backup files ( including the log file ) safely on tape since the Backup eMTool only places them on the server.

NOTE

You will need the backup log file in order to perform a restore.

To perform a cold backup (for the purpose of hardware upgrade, for example) or a scheduled unattended backup (via system batch files and scripts), you need to use the eMBox Client, and not iManager. Refer to the "eDirectory Management Toolbox" section in Chapter 7 for more information about using the eMBox Client.

Restoring a Server Using Backup eMTool

The most important part of restoring the eDirectory database is making sure it is complete. Because of the file dependencies (having the correct roll-forward logs for the specific backup and so on), you must ensure the following prerequisites have been met before restoring an eDirectory database to a server:

• All servers that share a replica with the server to be restored are up and communicating. This allows the restore verification process to check with servers that participate in the same replica ring.

• You have gathered all the backup files you need. The full backup and subsequent incremental backup files are copied to one directory on the server to be restored. And all the roll-forward logs since the last backup are in one directory on the server to be restored (so Backup eMTool can locate them), with the same filenames they had when they were created.

  TIP

  For procedures on how to confirm that you have the correct backup files before performing a restore or how to determine which are the correct files if names were changed, refer to the "Locating the Right Backup Files for a Restore" section in eDirectory 8.7 (or later) documentation.

  
  

  TIP

  If you do not have all the necessary backup files, you can try the procedure outlined in the "Recovering a Crashed SYS Volume or Server" section in Chapter 11. You can also refer to TID #10010922, titled "Removing a Crashed Server from the NDS Tree," which covers how to recover from a server crash.

  
  

• You have installed eDirectory, in a new temporary tree. You bring up the server in a new tree at first because you will create the server with the same name it had before the failure. Furthermore, you don't want to cause confusion in the original tree by putting the newly installed server in the tree before the restore has re-created the server's complete identity. Completing the restore process for the database will put the server back into its original tree.

• If any applications or objects need to find this server by its IP address, ensure the same IP address is used for the restored server.

• (NetWare only) Make sure the name of the server you are restoring to is the same as the name of the failed server. If the names are not the same, you might encounter errors, such as Volume objects not being correct after the restore.

• (NetWare only) Be sure to restore file system data only after eDirectory has been fully restored. Otherwise, you will lose file system trustee information.

During the restore process, the eDirectory Backup eMTool first restores the full backup. After this is complete, the Backup eMTool prompts you to enter the filenames of the incremental backup files. It provides you with the ID of the next file. After all incremental files are restored, the Backup eMTool moves on to the roll-forward logs.

After you have gathered all the necessary files and have placed them in the same directory, perform the restore using either iManager or the eMBox Client. The following outlines the server restore from backup files procedure using iManager:

1. Ensure that the prerequisites listed at the beginning of this section are met.
   
   
2. Log into iManager as a user with Supervisor rights.
   
   
3. Click the Roles and Tasks button.
   
   
4. Click eDirectory Maintenance, Restore.
   
   
5. Specify the server that you want to restore and click Next.
   
   
6. If not already authenticated to the server, you will be prompted for a username and password. Enter the requested information and click Next.
   
   
7. Specify the name of the backup and log files you want to use (see Figure 8.25), then click Next.
   
   

   Figure 8.25. Specifying the backup files for restore.

   
   
8. Specify additional restore options (see Figure 8.26), then click Next. In most cases, the following check boxes should be selected for a proper restore:
   
   

   • Restore database

   • Activate the restored database after verification

   • Open the database after completion of restore

   • Restore security files (meaning NICI files)

   • If you are restoring roll-forward logs, make sure you include the full path to the logs, including the directory that is automatically created by eDirectory, usually named nds.rfl .

   • Activate the restored database after verification

   Figure 8.26. Specifying additional restore options.

   
   
9. Click Start to initiate the restore process.
   
   
10. If the restore verification fails, refer to the later section "Recovering the DIB If Restore Verification Fails."
    
    
11. If you restored NICI security files, restart the server after the eDirectory restore is complete to reinitialize NICI.
    
    
12. Verify that the server is re-introduced into the production tree correctly and check that all replicas on this server are properly synchronized.
    
    

NOTE

The restore process turns off roll-forward logging and resets the configuration for roll-forward logging back to the default, which is Off . You will need to re-enable it if the server is part of a replica ring.

You should perform a full backup soon after the server restore process is complete. The new full backup is necessary so that you are prepared for any failures that might occur before the next full backup is scheduled to take place.

Recovering the DIB If Restore Verification Fails

To ensure data consistency, the Backup eMTool restore process includes a verification step, which compares transitive vectors in the eDirectory database on the server being restored against other servers in the replica ring. If the transitive vectors do not match, the verification fails. This usually indicates that data is missing from the files you used for the restore. Data might be missing for one of the following reasons:

• You did not turn on roll-forward logging before the last backup was performed.

• You did not include the roll-forward logs in the restore.

• The set of roll-forward logs you provided for the restore was not complete.

Verification failure might be caused by one of the servers in the replica ring running a version of NDS earlier than eDirectory 8.5. By default the restored eDirectory database will not open after the restore if Backup eMTool determines it is inconsistent with the other replicas.

If you have all the backup files and roll-forward logs necessary for a complete restore but forget to provide all of them during the process, you can simply run the restore again with a complete set of files. If the restore is complete on a second try, the verification can succeed and the restored database will open.

If you do not have all the backup files and roll-forward logs necessary to make the restore complete so that verification will be successful, you must follow the instructions outlined later in this section to recover the server. Here is an outline of what information you can recover if verification fails:

• You can still recover the server's identity and file system rights (for a NetWare server).

• You cannot recover any replicas on this server from backup, but the server can still be used for the replicas it contained after you follow the recovery procedure in this section. You must remove the server from the replica ring and use advanced Restore options and the DSRepair Tool to bring the server to a state where it can be put back in the replica ring. Then you can re-add the desired replicas to it.

• If this server had the sole copy of any partition of the database (there were no other replicas of the partition), the partition unfortunately cannot be recovered.

If eDirectory Backup eMTool verification fails to recover the server's identity, use the following procedure to recover and re-add it to the replica ring:

1. Clean up the replica rings per the steps given in the "Replica Ring Inconsistency" section in Chapter 11.
   
   
2. Change the replica information on the server to external references, so that the server does not consider it to be part of a replica ring. After you remove the replicas from the server in this way, you can unlock the database. To accomplish this step, you need to use the advanced restore mode in the eMBox Client ”you cannot use iManager for this step ”to override the default restore behavior:
   
   

   • Launch the eMBox Client using the instructions presented in the "eDirectory Management Toolbox" section in Chapter 7. You can use either the interactive mode ( -i ) or the graphical mode ( -g ).

   • If using the GUI mode, enable both the Show command line and Advanced mode options via the Settings menu.

   • Log into the server you want to restore. If using the interactive mode, enter the following command:

      backup.restadv -v -l  logfilename  

     
     

     If using the GUI mode (see Figure 8.27), click Backup, Advanced restore options, mark Override restore, and click Run. This advanced restore option will rename the .RST database (the database that was restored but failed the verification) to .NDS , but keep the database locked.

     Figure 8.27. Using the advanced restore option in eMBox Client.

     
     

   • At the server console, run DSRepair with the -XK2 switch to change all replica information on the server to external references:

     NetWare	DSREPAIR -XK2 -RD
     Windows	From NDSCons, select dsrepair.dlm , enter “rd “xk2 in the Startup Parameters field, and click Start.
     Unix	ndsrepair -R -Ad -xk2

     
     

     DSREPAIR.NLM and dsrepair.dlm will not display their menu and will exit automatically after the repair is finished when the -rd switch is specified.

     You can also use the DSRepair eMTool for this step (see Figure 8.28). Click dsrepair, Repair local database, uncheck all options, click Use temporary eDirectory database during repair?, click (xk2):Convert all replicas into external references, and click Run.

     Figure 8.28. Using the advanced repair option to change all replica information on the server to external references.

     
     

   • When the repair is finished, remove the lockout and open the database. If using the interactive mode, enter the following command:

      backup.restadv -o -k -l  logfilename  

     
     

     The - o opens the database and the - k remove the lockout.

     If using the GUI mode (see Figure 8.29), click backup, Advanced restore options, mark Open database when finished, mark Remove lockout on database, and click Run.

     Figure 8.29. Unlock and open the database.

     
     
3. You can now re-add the server into the replica rings using either ConsoleOne or iManager. When you have followed these steps and the replication process is complete, the server should function as it did before the failure (with the exception of any partitions that were not replicated and, therefore, can't be recovered).
   
   
4. If you restored NICI security files, after completing the restore and replication, restart the server to reinitialize NICI.
   
   
5. If you want to use roll-forward logging on this server, you must re-create your configuration for roll-forward logging to make sure it is turned on and the logs are being saved in a fault-tolerant location. After turning on the roll-forward logs, you must also do a new full backup.
   
   

This last step is necessary because during a restore, the configuration for roll-forward logging is set back to the default, which means that roll-forward logging is turned off and the location is set back to the default. The new full backup is necessary so that you are prepared for any failures that might occur before the next full backup is scheduled to take place.