Are you backing up ADAM?

  • Article

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:

  • Some 3rd party backup applications are described as being "Active Directory aware". Being Active Directory aware means that the software knows how to deal with System State data which allows you to create backup jobs that can specifically target the System State. The Active Directory database is included in System State as well as various other data. Data included in System State for Windows 2000/2003 is described in more detail here.
  • When the System State is backed up, we utilize the Volume Shadow Copy Service (VSS) to take a snapshot (shadow copy) of the data while it remains online so that system activity is not interrupted. We take a backup of this snapshot instead of the live data to be sure that we are backing up valid data. VSS is described in this overview.
  • The contents of the Microsoft ADAM directory are not included in a System State backup. Since the ADAM database is an online database we still need to rely on VSS to take a valid backup of the entire directory. When an ADAM instance is installed, a new registry value is created here:

HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup

Value name: ADAM (<instance_name>) Writer

Value Data: <path_to_adamntds.dit>

                  <path_to_edb*.log>

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.

clip_image002

When NTBackup encounters the Microsoft ADAM directory data you can see on the interface when the VSS has been invoked:

clip_image004

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.

Take care,

Adam "Wheatgrass" Conkle

[What are the odds of an ADAM SME being named Adam? I think I'll change my name to DFSR - Ned]