eDirectory Backup and Recovery using eMBox / eMTool

  • 10093373
  • NOVL97524
  • 24-Jun-2004
  • 24-Jun-2004

Archived Content: This information is no longer maintained and is provided 'as is' for your convenience.


eDirectory Backup and Recovery using eMBox / eMTool


eDirectory 8.7

Backup and Restore


How do I backup eDirectory?


This is a TID not an Appnote, there are many, many ways to deploy backup and recovery - this is one of them.

Since eDirectory 8.7 a new eDirectory backup and restore tool has been available. This tool provides a number of features.


It is very important to make eMBox AND TSA backups of eDirectory. They have two completely different functions. If you delete a few objects or a container, it is most likely best to use a tape restore.


Restoring an eMBox backup has very serious implications. You will almost NEVER be able to restore a backup on one or two servers (in a tree with 10’s of servers) and just walk way from them without having to do more work on eDirectory. A basic eMBox backup is equal to a DSRepair DIB Achive in terms of the partitions restored.


The most important point about this backup technology is that the end result is a snapshot of a specific server’s eDirectory database. It does not backup the entire tree unless the server where the backup was performed holds a copy of the entire tree.


When making backups the database may be open, called Hot Continuous Backup. Cold backups are also possible. These are performed when the database is closed.


The next important point about this backup method is that the Directory Services database is closed at the time that data is restored. This is because the restoration process reconstructs the database by writing blocks of data back into specific locations in the database. No Directory Services events are generated during recovery. The database is closed and data is written as blocks, not events.

<.FONT size=3> 

The net effect of this backup is that all details held in eDirectory are captured by the backup, but only for the server where the backup was performed. By default these details include: System Partition, Schema, External Reference Partition, Bindery Partition and All User Created Partitions.


An important point about this backup tool is that it is not a backup solution or backup product. It is only a tool. It is up to the user to script a solution to ensure that backups are scheduled (e.g. CRON), that disk space is managed, that log files are created and checked for problems and that data is backed up to a different server or tape for fault tolerance.


In addition to backing up eDirectory itself, the backup can be configured to backup:


·        Security Related Files: NICI/PKI key files


·        User specified files, defined by including their names in a semicolon (;) delimited text file, listed all on one line. An example could be SYS:\SYSTEM\AUTOEXEC.NCF;SYS:\ETC\HOSTS on NetWare.
Wildcards are not permitted.


·        Streams file backup must be enabled, otherwise they will not be backed up.


The following types of backups can be performed:


·        Full Backup

·        Incremental Backup

·        Roll-Forward Backup (RFL – Roll-Forward Logs)


There are three backup tools available for backup and restore.:


·        The eMBox java Client

·        iManager

·        DSBK (Not shipped in the product)


We could have a very long discussion about security, but the DSBK utility does not require the following in order to recover an eMBox backup:


·        Require authentication

·        SSL to be functioning

·        Java to be functioning

·        An existing temporary database


If you want security, secure the physical server and the server console.


The iManager component needs many pieces in place for it to work, which include the points mentioned above as well as the HTTP stack, IP stack, server NIC and Portal.




The actual backup commands will not be discussed here. It’s quite clear in the documentation. More importantly we need to look at Roll-Forward logs.


The following facts about RFL’s are important:

·        RFLs are files which contain blocks of approximately 800 bytes per change, written to a single RFL file limited by the maximum RFL size.

·        An RFL file is closed and a new one created when the maximum RFL size is reached.

·        The RFL currently in use may be double the maximum. This is normal. When the file is closed off it will be close to the maximum size specified.

·        RFL file names are sequential. You have no control over the file name, only the file location.

·        RFL files can not be used to roll back. They are Roll Forward files.

·        A Full backup is required in order to make use of RFL files.

·        RFL files are never overwritten.

·        When making a Full Backup, the previous Full backup + RFL files is equal to the latest Full Backup.

·        The only way to effectively manage RFLs is to write them to a different directory structure BEFORE each Full backup. The Full backup has an XML header which identifies the RFL file name in use during the Full backup.

·        When restoring RFL files, each RFL header identifies the next RFL to use. By renaming an RFL the restore process will stop. The restore process stops when it is unable to locate the next RFL file.

·       RFL files can only be written to a locally mounted disk, for performance reasons.

·        This type of process is required to manage backups using RFL’s:

o       Delete Dir1 structure

o       Set RFL directory to Dir1 (RFL’s are in Dir1\RFL)

o       Make Full Backup to Dir1

o       Delete Dir2 structure

o       Set RFL directory to Dir2 (RFL’s are in Dir2\RFL)

o       Make Full Backup to Dir2

o       Zip Dir1 stru.cture to ArchiveDir



The eMBox command line client can be used for a workstation or at the server console. The steps below would be required in order to recover one server’s eMBox backup data:


1. Copied a temporary eDirectory tree with role based servers installed onto the problem server. (Backup the specific servers existing eDirectory data by copying it at the server console.)



·        SYS:\_Netware



·        /var/nds/dibs

·        Copy the utility <.B style="mso-bidi-font-weight: normal">dsrmenu6 from the Novell patch site to the server. This contains a menu wrapper for ndsrepair. This will help you perform tasks required during recovery without the need to know the command-line syntax for ndsrepair. Highly recommended!


2. Start the temporary tree on the server. (Restart eDirectory Services)


3. Copy the backup files onto a drive on server.


4. Optional. Pull the network cable from the problem server to stop DirXML from syncing. This would only be required if it is not possible to stop the DirXML driver on the other end.


This is a decision point:

* Will the data being recovered be too outdated?  If you do not want to allow the recovered server to synchronise with others, then goto point 5.


* If you don’t care that there may be small differences which eDirectory will resolve later, then goto point 8.


5. Remove the problem server from the replica ring for all partitions. This task is performed at the console a server holding a replica of the partition or through iManager. (See the product docume.ntation.)


6. Move the master for the partitions involved to one of the R/W or R/O replica holding servers.


7. Disable eDirectory synchronisation on the working servers which hold the same partitions as the broken server. This is to prevent synchronization until you are ready to have the servers synchronise.


8. Load eMBox in interactive mode, authenticate, then set advanced mode and restored DIB.



·        load embox –i



·        edirutil -i


At the embox command prompt (All OS’s the same):


login –s <serverIPaddr> -p<8008> -u <user.context> -w <password> -n


setmode –a


restore -f full_backup_path_and_filename -d roll-forward_log_location -l restore_log_path_and_filename -e -u -a –r -n -k -v –o


         NOTE: The syntax above opens eDirectory after the restore (-o). The default Transitive Vector check is for protection. The situations in 

                    which this feature would be required in normal recovery situations is limited. What are the chances of restoring eDirectory 

                    to all servers in the tree? What are the chances that RFLs are being used? What are the chances that the RFL's are actually

                    available? They are written to the local server. If you loose the disk, you loose the RFL's.



-f     Backup file name

-l     Log file name

-d     Roll forward log directory      

-i     Comma separated list of incremental files in order

-e     Restore security files

-u     Restore user included files

-r     Restore DIB set

-a     Activate DIB after verify

-o     Open database when finished

-n     Do not verify database after restore

-v     Override restore

-k     Remove lockout on database


After the full backup is restored a prompt will ask for the location of the incremental file. Press enter if no file is being used.


This is a decision point:

* Will the data being recovered be too outdated?  If you do not want to allow the recovered server to synchronise with others, then goto point 9.


* If you don’t care that there may be small differences which eDirectory will resolve later, then goto point 10.


9. Use dsrepair -xk2 to remove the replicas from the restored server only, the data is too old.



·        dsrepair –xk2 -rd


Linux (case sensitive)

·        ndsrepair –R –Ad –XK2


10. Put the cable back into the recovered server


11. Wait for xk2 operation to complete.


12. Place replicas back on the recovered server


13. Move the master for each partition back to the recovered server if DirXML is involved or as required.