Article

(View Disclaimer)

DSBK Restore to Test Environment:

This document outlines a method of restoring a production tree into a lab environment under Linux using the eMBox DSBK utility.

This guide was built from various TIDs and test restores in VM environments.

For further information please refer to:

• TID: 3308688
• TID: 7000768
• TID: 3950804
• eDirectory 8.8.x restore documentation.

What you need:

1. A server (virtual or physical) that will be the target of the restore.
2. A copy of the production tree that was backed up via DSBK
3. This guide!

Step 1 – Prepare the Target Server:

Build your Target server as required, the partition that will house the actual DIB should be at least twice the size of the DIB as it currently stands in production (once the restore is complete the target server will contain the restored files and the files copied from backup).

The hostname / IP Address of your target server does not have to match production.

Install the appropriate version of eDirectory onto your target server as per the production environment. Patch your eDirectory version with the appropriate Security Services patch.

Ensure your nds.conf path and DIB paths match the production environment in the following steps!

Build a temporary tree and ensure ndsd is running. Whatever path you use for the DIB location of the temporary tree will be used in the restore, the nds.conf file will also be updated with the production tree information after the restore has completed.

Step 2 – Prepare for Restore:

Use scp to copy the directory that contains the dsbk backup of your production tree onto the partition your created for eDirectory (not the same location as the DIB!). The backup should be of a server that contains a replica of every partition in the tree, it is recommended to use the dsbk copy from a master server as this will speed up the process of requiring the promotion of R/W replicas to master on the target server.

Run the following command to create a symbolic link for NICI (see TID 3950804):

<code>ln -s /etc/opt/novell/nici.cfg /etc/nici.cfg</code>

Create the following file:
<code>vi /etc/dsbk.conf</code>

Create the following line in this file:
</code>/tmp/dsbk.command</code>

Touch the following file:
</code>touch /tmp/dsbk.command</code>

This configuration / temp file is used by the restore process to pass commands through the ndstrace process (see eDirectory documentation).

Step 3 – Perform the Restore:

Once the target server is disconnected to the production environment perform the following command as root at the terminal:

<code>dsbk restore -f /<path to backup .dib file> -l /tmp/restore.log -r -a -o -n -v -k</code>
eg -
<code>dsbk restore -f /eDir/dsbk-slppdad1/slppdad1-ndsbackup.dib -l /tmp/restore.log -r -a -o -n -v -k</code>

The restore can be monitored by executing tail -f against /tmp/restore.log

Restores of larger production environments can take some time to complete, a VM restore of ~4million object tree can take 40-50minutes, you may get better performance on physical hardware.

Below is an example of a successful restore:

Click to view.

Login to this server with iManager and remove any server objects from the tree that do not match the target server.

Also remove certificate / LDAP and any other objects for these servers (these objects will contain the old server name).

Once you have confirmed nds is up and running and is indeed the Production tree you restored you can remove the dsbk backup that you copied over from production.

Open iManager and perform a Tree Rename operation to change the tree to something that differs from any current production Tree names.

The Tree rename process can take a long time to complete for large databases (~5 hours on a VM environment for 4million object tree), the rename process also consumes large amounts of disk space until the operation is completed.

Once the tree has been renamed check your nds.conf file for accuracy and restart the ndsd to ensure it comes up correctly with the new tree name.

If you receive 'not listening' errors when ndsd starts, refer to TID 3308688.

Before connecting the target server to the production environment confirm the following:

• Server IP is unique
• Server hostname is unique
• Tree name is unique
• All existing production servers have been removed from the new tree (except the target server).

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.