Are you backing up ADAM?

Are you backing up ADAM?

  • Comments 3
  • Likes

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:


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.

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]

  • PingBack from

  • Follow-up Question:

    Although I do see the message "Preparing to backup using shadow copy", I still suspect the .dit and edb.log file are not being backed up.

    In the detailed backup listing, these two files are not listed and the number of bytes reported as backed up is only approximately 1200 bytes more than the sum of the bytes sizes of the files listed as having been backed up.

    It doesn't seem that the .dit and edb.log files could be in the backup file?!?

  • Hey tlb1234,

    A few things to check:

    1. When the backup completes there is a "Report..." button. Does that report show any errors? How many files does it say it backed up? Is that number consistent with the number of ADAM data files you have?

    2. Run through the Restore Wizard of NTBackup and select the backup you took of Microsoft ADAM. Drill down to your ADAM data directory, do you see the .dit and edb.log files in the list? What happens if you execute the restore to an alternate location? Do you get the .dit and edb.log files restored?

    3. Open Services.msc and find Volume Shadow Copy. The Startup Type should be set to Manual and Status is stopped. Start a new backup of your Microsoft ADAM directory and refresh the Services console a few times. Do you see the Volume Shadow Copy service Status change to Started?

    4. Check the registry for the appropriate FilesNotToBackup entry for each of your ADAM instances (this is detailed in the blog post). Make sure that the path to the .dit and edb.log files are correct.

    Thanks for the response!