eDirectory Backup and Recovery using eMBox / eMTool

(Last modified: 24Jun2004)

This document (10093373) is provided subject to the disclaimer at the end of this document.

goal

fact

eDirectory 8.7

Backup and Restore

symptom

How do I backup eDirectory?

fix

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 10s 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 servers 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.

BACKUP

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

The following facts about RFLs 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 RFLs:

o Delete Dir1 structure

o Set RFL directory to Dir1 (RFLs are in Dir1\RFL)

o Make Full Backup to Dir1

o Delete Dir2 structure

o Set RFL directory to Dir2 (RFLs are in Dir2\RFL)

o Make Full Backup to Dir2

o Zip Dir1 stru.cture to ArchiveDir

RECOVERY

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 servers 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.)

NetWare

· SYS:\_Netware

Linux/Solaris

· /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 dont 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.

NetWare

· load embox i

Linux/Solaris

· edirutil -i

<./P>

At the embox command prompt (All OSs 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.

syntax:

-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 dont 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.

NetWare

· 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.

document

Document Title:	eDirectory Backup and Recovery using eMBox / eMTool
Document ID:	10093373
Solution ID:	NOVL97524
Creation Date:	24Jun2004
Modified Date:	24Jun2004
Novell Product Class:	Novell Directory Services

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.