Hi, it's Adam Conkle from the Microsoft Directory Services team. I recently encountered a disaster recovery situation with an ADAM instance where objects were accidentally deleted, and the customer required help performing the restore of those objects from backup. We ran into a major problem that I feel many administrators may be overlooking, so I thought I should write about it.
When I began working with the customer, she had performed a restore to an alternate location of the Microsoft ADAM directory using their enterprise 3rd party backup software. She then showed me the contents of the restore directory and I saw that neither the database (adamntds.dit) nor the transaction log (edb.log) were present. She stated that their backup job was configured to back up the entire Microsoft ADAM directory, and she was concerned why the database and transaction log were not included in the restore.
Here are some things to think about:
Value name: ADAM (<instance_name>) Writer
Value Data: <path_to_adamntds.dit>
This registry value tells NTBackup not to backup these files as a normal file backup. Instead, NTBackup will ignore these files during the normal file backup and then invoke VSS to take a snapshot of the files so that a proper backup can be taken.
In NTBackup, if you select the entire Microsoft ADAM directory for backup and then drill down to the data directory you can see that the database and transaction logs are not checked. This tends to be confusing because one would assume that this means the files will not be backed up. Rest assured that as long as your VSS writer is functional and the registry value described above is in place, the files will be captured in your backup.
When NTBackup encounters the Microsoft ADAM directory data you can see on the interface when the VSS has been invoked:
In the customer's scenario, the 3rd party backup software could back up the System State, but it was not aware of the FilesNotToBackup registry key, and thus did not back up the ADAM database and transaction log files successfully. Without a valid backup of ADAM we were not able to restore those objects.
In conclusion, for disaster recovery purposes, I highly recommend that administrators verify that they are getting good backups of ADAM, especially if they are using 3rd party backup software. If your ADAM database and transaction logs are not being backed up you should schedule NTBackup to backup your ADAM instances or consult your 3rd party backup software vendor to add this functionality.
*Note - This posting does not apply to AD LDS on Windows Server 2008. Windows Server 2008 contains Windows Server Backup which backs up whole volumes of data using the Volume Shadow Copy Service. A System State backup using Windows Server Backup captures the entire volume for all critical volumes containing operating system files. If your AD LDS instance(s) are stored on a non-critical volume, you will need to ensure that the volume(s) on which they reside are being backed up correctly as they will not be captured in a System State backup.
Adam "Wheatgrass" Conkle
[What are the odds of an ADAM SME being named Adam? I think I'll change my name to DFSR - Ned]
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.