There are many possible approaches to backing up eDirectory. Of course the issue historically has been, how do you restore? There are clearly two possible cases: restoring a single object that was accidentally deleted, or restoring a complete server after some kind of disaster.
You can use TSANDS to back the directory up, object by object, to a TSA-complaint backup software package. This is useful for restoring single objects. But for a full directory restore, this can take a lot of time.
You can use emBox, introduced in the eDirectory 8.7 timeframe. This approach lets you back up something like a database snapshot-in- time view of the directory. This will not help with a single object restore, but it's much better for a disaster recovery backup.
You could use DSMAINT and the Prepare DS for Hardware Upgrade option, which makes a sys:\system\backup.ds file. However, this is generally a bad idea, as that would leave the server in a state where it is waiting for the upgrade, so you would then have to immediately restore the server. That's very highly recommended against - there are much better approaches than that.
There is an option of doing a DSRepair -rc, which dumps the DIBset to the $DU files. It used to be that only Novell Technical Services could restore these files. In fact, in Novell Knowledgebase articles as recent as 2006 or so, that is stated as the case.
At some point support was added for us, as the end users to restore one of these dumps. (Does anyone know when that was? It is sort of irrelevant, unless you are running old eDirectory versions, but I would be interesting to know when it actually was added. In fact I went looking for when this became an option, and I cannot find anything in the Knowledgebase about this feature. All references still say that Novell Technical Services are the only ones who can restore these files.)
This is very powerful, and it has some great uses that probably were not originally intended. For example, what I find most useful with it is to build an isolated test lab. When doing a large scale IDM implementation, you need to have a copy of the real environment to test with. So how do you get it into your test lab? eDirectory is actually pretty easy. You could just install an extra server into the tree, and then isolate it from the network, and declare it dead in the production environment. Then inside the test environment, you would declare all the other servers in the tree dead. If the server had a replica of all partitions, then you have a copy of it in your test environment.
Of course, you must be VERY careful NEVER to let this server back onto the public network. It must NEVER, EVER, EVER talk to the tree again. Let me restate that: it must NEVER, EVER, EVER talk on the same network again. Weird things will happen if it does - bad, weird things. This is obvious but very critical.
Of course, a VM is an excellent choice. That's because once you have your VM up and running, before you test anything, you can take a snapshot. Then you can test a migration, and if there are any issues, revert the snapshot and try again, until you get it just right. In each case, it very closely mirrors the issues you will find when you try it in production.
For Active Directory you can do something similar as well. Add a server as a DC, and then take it off the public network and isolate it.
Lotus Notes can do something similar, build a server, give it a replica of the names.nsf addressbook and you once done, you can hide it on the network.
Thus this can be a very powerful and necessary approach to build your test lab.
However when you try this, often after you isolate your virtual servers, you want to move the DS backup files to the isolated server, you may run into a problem.
To restore the files backed up with Dsrepair -rc, you need to load DSRepair with the -$DU switch. (That was obvious, right? Gotta love hidden command line options. Years ago I saw a list of all the hidden commands, at that time for Dsrepair. I imagine there are many more now. Anyone have an up to date copy of that, that is allowed to be shared? That would be very useful to have in the public!)
Once you do that, under Netware, go to Advanced Options, then NDS Archive at the bottom. It used to be there was just an option to make a database archive. Now there is a "restore from archive" option.
The problem I ran into was this: I selected the option, indicated "I Agree" to confirm that I know how bad an idea this is if it's done in error, and selected the folder. I then got an operation failed error, with no error message whatsoever. Very frustrating.
Running out of ideas, I decided to blast it with DSTrace, using NetWare 6.5 as the server. Here's what I did:
DSTRACE (loads dstrace.nlm) DSTRACE SCREEN ON (turns on the display to the screen) DSTRACE ALL (enables all the flags) DSTRACE FILE ON (turns on the output to the Sys:\system\dstrace.log file
Then I tried it again. Now there was a -144 error in the REPR tag. Finally, an error code to look for!
The -144 error is an "All read only error". This seemed like a red herring, since DSRepair needs to read the DIB backup, not write to it. But it was a path to try to resolve the issue.
The original images were moved onto the isolated VM through the use of a CD-R, since the network was not an option. When you copy files off the CD-R, there is an implicit Read Only attribute on the files copied. That's easy enough to clear. At the console, I ran:
One of the TBX commands is attrib. I tried the following (modify this to match your path):
attrib -r sys:\system\dsr_dib\*.*
and then tried it again. I found this resolved the issue. This was most frustrating, due to the lack of a useful error message to troubleshoot. I had tried different files from a different server, another copy, and so on. Hopefully this document will give you some ideas and approaches to try and find an error message to even begin to troubleshoot.
DSTRACE is a very powerful tool for troubleshooting issues. There are a large number of options you can turn on to look at a variety of issues. There is an iMonitor switch, for weird iMonitor issues. I have never seen an issue I need to use this for, but it is good to have, should I need to in the future.
A more useful one is NMAS, where you can watch the process of an authentication, when you are looking at really strange and hard-to- track-down problems.
LDAP tracing, of course, is pretty much a basic use, as is Identity Manager tracing (called DXML and DRVS, as leftovers from the DirXML days).