eDirectory is a considered to be a loosely synchronized database. So what does that mean? eDirectory changes are based upon timestamps. As an object is updated with a new timestamp, eDirectory recognizes the change and replicates it to the corresponding servers in the replica ring. Once the replication is complete through the confirmed synchronization process, the change is NEVER synchronized again. Unlike other databases that synchronize entire copies of the database or entire objects, eDirectory only synchronizes the affected attributes and components that have changed, when the change occurs.
So if eDirectory is healthy and consistent among all replica holders, and you restore an image from 6 months ago, or 2 days ago or 2 minutes ago for that matter, it will hold different information that the other replica holders. eDirectory will NOT reconcile the differences on the restored server. These differences may simply be different values in attributes (descriptions, address, password, etc), or they may be that the server holds an object that has since been deleted.
A common symptom of inconsistencies in a replica ring are #_# objects. Collision renamed objects (#_# objects such as 0_2) are caused by one server trying to sync a new object over to another server that either holds an object with the same name and a different creation timestamp, or a different name with the same creation timestamp. eDirectory cannot handle two objects with same name or timestamp so it creates a collision rename object in its place. The Numbers actually mean something, where the first digit (#_ ) is instance of the rename, and the second digit ( _#) is the replica number doing the rename. So you can find the offending replica by looking at the replica attribute for the partition and finding the server with that replica number in the replica ring using iMonitor.
So what does all of this mean in the virtualized environment we have now days.
When migrating to a virtual environment, or restoring images there can be material consequences if not handled properly.
It is NOT supported to be running two servers with the same name in the same tree. All Novell utilities that perform migrations from one server to another take steps to disable the source server once the migration is complete. This action will prevent duplicate servers in the same tree.
There are known third party utilities that do NOT lock the source server down when the migration is complete. Leaving both servers running after the virtual migration is complete. Leaving both servers running in the tree, WILL cause corruption in eDirectory! So as you migrate to a Virtual server using any third party utilities. When the migration is complete shut down and disable (by FDISK, Formatting or other means) the source server.
Restoring images on virtual servers. This is one of the key benefits of a virtualized environment. There are several reasons for restoring a virtual server.
Virtual host OS is corrupt.
eDirectory is corrupt.
Need to get deleted file from server.
Need to restore user or other eDirectory object that was Deleted.
Along with other reasons....
Options 1-3 are valid reasons to restore a virtual image. Option 4 is not. If you are trying to recover a single object in eDirectory, then use a supported eDirectory backup software to restore the single object or recreate the object by hand.
So when can a virtual image be restored without potential affects? The answer may be never. However in if you restore an image and immediately (within moments after restoring the image) remove ALL replicas from the servers, then in most cases the restore can be accomplished without any issues.
If the SERVER OBJECT HAS MOVED in the tree since the image was taken, DO NOT RESTORE IT.
The most common practice, which is used by Novell Technical Support, is to manually remove all replicas from the server after the restore. TID 7001592 â Manually removing all replicas from a server, discusses how to manually remove all replicas from a server. WARNING: If done incorrectly, the xk2 process can cause severe issues in your tree. In other words, you could lose your entire eDirectory tree or portions of it.
Another approach is to remove all the replicas through normal tools, such as iManager. If the replica remove is not done within moments of restoring the image, you could potentially replicate old or bad information in the tree as changes are being made to the database on the restored server. This method WILL NOT WORK if you have MADE CHANGE TO THE REPLICA RINGS in the tree since the image was taken.
In the end, it is NOT recommended or advised to restore images of virtual servers in your eDirectory tree. Restore images at your own risk! Some effects of restoring images could be irreversible.
Related Technical Information Documents: