Windows Administration

Active Directory Backup and

Restore in Windows Server
2008
NTBACKUP vs. Windows Server Backup
 Backup tools and options
 Recovery tools and options
 Keys to a sound Active Directory backup strategy

You all know that Active Directory Domain Services

(ADDS) is a mission-critical component in your Windows
infrastructure. If Active Directory goes down, your
network is essentially useless. Consequently, your
backup and recovery plans for Active
Directory are fundamental to security, business continuity, and regulatory compliance.
Windows Server® 2008 brings many new features to Active Directory®, two of
which have a significant impact on your backup and recovery plans: the new
Windows Server Backup utility and the ability to take and work with Volume
Shadow Copy Service snapshots of Active Directory. In this article I will describe
the changes these enhancements bring to the table and how you can take
advantage of these changes to streamline your Active Directory backup activities.

NTBACKUP vs. Windows Server Backup

Group Policy Settings
Windows Server Backup provides several Group Policy settings that give you some limited
control over how backups work on your servers. With these backup policies, you can mitigate
some of the risks associated with people performing unauthorized backups to obtain access to
unauthorized data. The options include:
Allow Only System Backup If this is set, Windows Server Backup can only back up
critical system volumes. It cannot perform volume backups. Disallow Locally Attached Storage
as Backup Target When enabled, this setting does not allow backups to locally attached drives.
You can only back up to a network share.
Disallow Network as Backup Target This setting does not allow backing up to any
network share.
Disallow Optical Media as Backup Target When this is set, Windows Server Backup
cannot back up to any optical device, such as a recordable DVD drive.
Disallow Run-Once Backups This setting does not allow Windows Server Backup to run
unscheduled, ad hoc backups. Only backups that are scheduled through the Windows Server
Backup MMC snap-in are allowed to run.

The NTBACKUP you've known and loved since Windows NT® 3.5 is gone. Replacing
it is Windows Server Backup. And this new tool is not just a gussied-up NTBACKUP;
it's a whole new backup technology that will force you to rethink the way you back
up your systems.
Although Windows® Server Backup is the only in-the-box backup solution for
Windows Server 2008, it is not a feature-for-feature replacement for NTBACKUP.
The biggest difference is that Windows Server Backup is a disk-to-disk backup
solution; it doesn't support backing up to tape. You can create backup images on
direct-attached disk volumes, on network shares, and even on external USB hard
drives and multi-volume recordable DVDs. But you cannot back up to tape. Just to
be clear, you can still hang a tape drive on a Windows Server 2008 server and
copy the Windows Server Backup-generated backup images to the tape drive—but
you'll have to use someone else's software to do so.
Whereas NTBACKUP is a file-based backup and restore tool, Windows Server
Backup is volume- and block-based. Windows Server Backup deals with its backup
source as a set of volumes, with each volume as a collection of disk blocks. This is
considerably more efficient than backing up files through the file system. Dealing
with backups on a block basis also allows Windows Server Backup to make use of
Volume Shadow Copy Service snapshots to perform block-level incremental
backups, as well as to create snapshots on the target volume to simplify the use of
(and reduce the space used by) multiple backups.
Even if you are doing full backups, Windows Server Backup provides some great
space efficiencies on the target disks. For instance, you might perform multiple full
backups of the same volume. Since Windows Server Backup uses Volume Shadow
Copy Service snapshots on the target disks where it stores the backup images, the
snapshots will only store the blocks that have changed. This substantially reduces
the space used by multiple full backups. This eliminates the need to perform
multiple restore operations to recover an incremental backup. Even though the
snapshot only stores the deltas for each backup, Volume Shadow Copy Service
makes each backup appear complete.
Be aware, though, that you only get the benefits of Volume Shadow Copy Service
snapshots on the target if you back up to a local hard disk—Windows Server
Backup can't perform Volume Shadow Copy Service operations on backups stored
on DVD or network shares.
As an added bonus, Windows Server Backup stores its backup images in
Microsoft® Virtual Hard Disk (VHD) format. You can actually take a backup image
and mount it as a volume in a virtual machine running under Microsoft Virtual
Server 2005. You can simply mount the VHDs in a virtual machine and browse for
a particular file rather than having to perform test restores of tapes to see which
one has the file is on it. (A note of caution: you can't take a backup image and
boot a virtual machine from it. Since the backed-up hardware configuration
doesn't correspond to the virtual machine's configuration, you can't use Windows
Server Backup as a physical-to-virtual migration tool.)
There is a downside to Windows Server Backup's volume- and block-orientation.
Since this new tool looks at the backup source as a set of volumes and blocks, it
doesn't allow you to back up only selected files. You have to back up the entire
volume. And even more problematic, by default you cannot store a backup image
on one of the volumes being backed up (there are some ways to configure around
this; see support.microsoft.com/kb/944530). This has profound implications for
system state backup, as I will discuss later in this article.

Installing Windows Server Backup

Windows Server Backup is a "feature" in Windows Server 2008 and is not installed
by default. Before you can perform a backup with Windows Server Backup, you
have to install the feature, using either Server Manager, or the
SERVERMANAGERCMD command-line utility:

Copy Code

C:\> servermanagercmd -install Backup-Features

Windows Server Backup is composed of two sub-features, Windows Server Backup

and Command-line Tools. Note that Command-line Tools refers to a set of Windows
PowerShellTM cmdlets—not the WBADMIN .EXE command-line tool. Thus, if you
choose to install both sub-features, you must install the Windows PowerShell
feature.
After installing Windows Server Backup, you can find the Microsoft Management
Console (MMC) snap-in under the Storage node in Server Manager and on the
Administrative Tools menu. If you are installing Windows Server Backup on a
Windows Server 2008 Server Core installation, use the OCSETUP command (it's
important to note that the OCSETUP command is case-sensitive):

Copy Code

C:\> ocsetup WindowsServerBackup

A complete description of the installation process is available at go.microsoft.com/fwlink/?

LinkId=113146.
 Note that Windows Server Backup can't restore images created with NTBACKUP.
For this unlikely scenario, Microsoft has made available a downloadable version of
NTBACKUP for Windows Server 2008 (see go.microsoft.com/fwlink/?
LinkId=113147).

The Windows Server Backup Components

The way in which the Windows Server Backup application is architected represents
a significant change. This new backup solution consists of four components:
1. MMC user interface (WBADMIN.MCS)
2. Command-line interface

(WBADMIN.EXE)
1. Backup service (WBENGINE.EXE)

2. Set of Windows PowerShell cmdlets

Splitting the application into a client and a service has several advantages, the
most important being increased reliability. Whether you start a backup from either
the MMC client or the command-line interface, the WBENGINE service is doing the
heavy lifting. The client programs just report the status of the backup. Thus,
terminating the client will not result in a half-baked backup. The client will stop
and the service will continue to completion. Of course, if you really want to stop
the backup, you can, but you must do so explicitly.
The other advantage of this split architecture is that you can use the client to
manage backups on remote machines. This is particularly nice when you have to
back up Windows Server 2008 Core machines.
Windows Server Backup supports bare-metal restores using the Windows Recovery
Environment, or WinRE, which comes on the Windows Server 2008 installation
media. WinRE simplifies the process of recovering a server from scratch. I will
discuss performing a bare-metal restore later in this article. It's worth mentioning
that Windows Server Backup supports several Group Policy settings for managing
backups—these are outlined in the "Group Policy Settings" sidebar.

Volume Shadow Copy Service

Windows Server Backup uses Volume Shadow Copy Service in three different
ways. When you start a full backup on Windows Server 2008, the first thing that
the application does is make a shadow copy of all of the source volumes. Doing
this provides a consistent view of the file system for the backup software to work
with. (This is similar to what NTBACKUP did.) Windows Server Backup then copies
blocks from the source volume—block by block—to the backup target, building a
VHD image for each backed-up volume in the process.
Unless you specify otherwise, Windows Server Backup also creates a snapshot of
the source volume so that Volume Shadow Copy Service will keep track of all
changed blocks on the volume. This enables Windows Server Backup to create
block-level incremental backups that only require reading the changed blocks of
the source volume. Rather than reading and writing an entire file because one bit
was changed in the file, Windows Server Backup can read and write only the block
that has changed.
This makes for very efficient incremental backups, but at the expense of extra disk
I/O for write operations on the source volume. If you are backing up a particularly
busy or performance-critical volume, you should disable the Volume Shadow Copy
Service snapshot on the source volume by selecting the Configure Performance
Settings link and then disabling incremental backups on that volume (as shown in
Figure 1).

Figure 1 Disable incremental backups on busy volumes (Click the image for a
larger view)
When the backup is complete, Windows Server Backup takes a snapshot of the
target volume (assuming you are backing up to a locally attached hard disk).
During the next backup, the target VHD files are overwritten. But since Volume
Shadow Copy Service is maintaining shadow copies of the target volume, there
are, in effect, multiple versions of each VHD file corresponding to each of the full
backups. You essentially get multiple full backups for the cost of one full backup
and the changed blocks.

Backing Up to Network Shares

Backing up to a network share is just as easy as backing up to a local volume. The
significant difference is that it can't create a Volume Shadow Copy Service
snapshot of the remote volume. Therefore, each full backup will overwrite the
previous, leaving you with just the latest full backup image of each server on a
network share. Due to this limitation, you can't use the Windows Server Backup
scheduler to schedule backups to a network share. You can, however, use the
Windows Task Scheduler to run the WBADMIN command-line program to perform
full backups to a network share. If you elect to schedule full backups to a network
share this way, change the target folder for each backup to avoid overwriting
previous backups.

Backing Up to Recordable DVDs

Windows Server Backup also supports backing up to optical media, such as
writable DVDs. And you can create backup sets that span multiple volumes, as
well. Windows Server Backup always compresses backups to DVDs, which means
that you can only perform full system or full volume restores from DVD. Windows
Server Backup doesn't support system state or file level backups and restores
when using DVDs. And you can't schedule backups to DVD.

System State Backups and Restores

System state backups, which include only select files and some application
databases (rather than entire volumes) is handy and often essential. But early
builds of Windows Server 2008 didn't support system state backups and restores.
Instead, the backup tool just backed up critical system volumes (meaning any
volumes necessary for recovering and rebooting the OS and key applications).
These critical system volumes were the volume-oriented equivalent of a system
state backup.
Acknowledging feedback from customers, Microsoft added system state backup
and restore capabilities to Windows Server Backup. The application creates
multiple VHD files, one for each volume that hosts the system state data, but it
only copies the necessary files and databases to the VHDs. Another issue is that
when you perform a system state backup, Windows Server Backup does not create
a snapshot of the target volume as it does in the normal backup process. Instead,
each system state backup generates an entirely new set of VHD files, which
means you don't get the space efficiencies you find with the snapshot-based
volume backups.
You can only perform a system state backup using the WBADMIN.EXE command-
line program—the MMC snap-in doesn't provide this option. To perform a system
state backup, you use this command:

Copy Code

C:\> wbadmin start systemstatebackup

–backuptarget:e:

WBADMIN will then back up the critical system files and application databases to
the target volume, in a folder reserved for system state backups. The system state
backup on a 32-bit Windows Server 2008 domain controller (DC) with a default
directory information tree (DIT) runs a little more than 6GB—this is more than 5GB
larger than on Windows Server 2003 due in part to the fact that Windows Server
Backup is capturing core OS files that NTBACKUP didn't.
The time required to back up the system state is also greater, as you would
expect. These initial numbers, of course, are based on a pre-release version of the
OS. You'll certainly need to test this in your own environment, but it's likely that
you'll need to plan for larger system state backups (and longer backup times)
when you move your domain controllers to Windows Server 2008.

Backing Up a Server with the MMC

When you run the Windows Server Backup MMC (see Figure 2), you have the
option of either setting up a backup schedule or immediately running an ad hoc
backup. In this case, I select Backup once to perform an immediate backup.

Figure 2 Windows Server Backup MMC (Click the image for a larger view)
As you can see in Figure 3, I can choose whether to back up all the volumes on
the server or back up just the specific volumes that I choose. If I select Full server,
Windows Server Backup will back up all mounted volumes, but I won't have the
option of backing up to a mounted hard drive—instead, I will have to back up to a
recordable DVD or to a network share.

Figure 3 Using the backup configuration dialog to specify all or select

volumes (Click the image for a larger view)
In this example, I want to back up to a local hard drive, so I select the Custom
option. A dialog then lets me select the volumes to back up (see Figure 4). By
default, Windows Server Backup checks the Enable system recovery box, which
causes Windows Server Backup to select the boot volume, the OS volume, and any
other volumes with critical system files and application databases. On a DC, this
includes the volumes hosting SYSVOL, the Active Directory DIT, and Active
Directory logs. This is the equivalent of a system state backup but it backs up all
the critical volumes, not just the critical files on those volumes. In fact, I even have
the ability to perform a system state recovery from a system recovery backup set.

Figure 4 Selecting specific volumes to back up (Click the image for a larger
view)
After I select the destination type (local drive or network share) and specify the
destination, Windows Server Backup prompts me to select either a "VSS copy"
backup or a "VSS full" backup. The terminology is a little confusing, as both
options will back up the selected volumes in their entirety. The difference lies in
the way Windows Server Backup handles the source files after they've been
backed up. If you select the copy option, Windows Server Backup will leave the
backed up files alone. If you choose the full option, Windows Server Backup will
then reset the archive.

Backing Up a Server from the Command Line

If you want to script the backup process, or if you are backing up a server on a
Server Core installation, you can use the WBADMIN.EXE command-line program.
WBADMIN provides a complete set of options that perform essentially the same
functions as the MMC snap-in, including managing backup schedules.
Suppose I want to start the WBENGINE service, which will in turn perform the
backup process. All I do is enter this command:

Copy Code
C:\> wbadmin start backup –include:c:,d:

–backuptarget:e:

Or to back up all critical system volumes, I can enter this command:

Copy Code

C:\> wbadmin start backup -allcritical

–backuptarget:e:

After starting the backup, WBADMIN continues to run and show the progress of the
backup. If I terminate WBADMIN, the backup will continue in the background. I can
then reconnect WBADMIN to a running backup using this command:

Copy Code
C:\> wbadmin get status

And if I want to terminate a running backup, I just enter this:

Copy Code

C:\> wbadmin stop job

Scheduling Backups with the MMC

The backup scheduler that is integrated with the Windows Server Backup is really
designed to do one thing: simplify scheduling of daily full-system backups to a
local disk volume. You can use the built-in scheduler to automatically rotate
backups among multiple target volumes. If you have easily removable hard drives
(or you are using USB-attached hard drives), you can use this feature to set up a
rotation scheme where you remove the backup disk and store it off-site and return
the oldest backup disk to the server for the next scheduled backup.
The Windows Server Backup scheduler only lets you schedule backups that always
occur daily. There is no way to schedule backups for, say, Mondays, Wednesdays,
and Fridays. So if you don't want to run your scheduled backups daily, you'll have
to work directly with the Windows Task Scheduler.
When you set up a scheduled backup to a local disk, Windows Server Backup takes
responsibility of the disk, formatting it, setting up a specific folder structure, and
making the target disk invisible to Windows Explorer. The target disk must be a
basic volume—Windows Server Backup cannot backup to disks configured as
dynamic volumes.
Scheduling backups through the MMC snap-in is very easy. In this example, I first
select the Backup Schedule link, specify the type of backup and the volumes to
back up, and then Windows Server Backup shows the "Specify backup time" dialog
(see Figure 5).
Figure 5 Specifying when daily backups should occur (Click the image for a
larger view)
After selecting the times at which I want the backup to occur, I can select the
volume (or volumes) to which I want to back up. In this case, I select the backup
volume E:, as shown in Figure 6. Windows Server Backup tries to select an
appropriate target volume for you, but if it happens that the disk you want to back
up to doesn't appear, you can use the Show All Available Disks button to view all
attached disk devices. After going through a couple of "confirm" dialogs, Windows
Server Backup formats the target volume(s) and schedules the backup task using
the Windows Task Scheduler.
Figure 6 Specifying the destination disk for a scheduled backup (Click the
image for a larger view)
Each time a scheduled backup is completed, Windows Server Backup takes a
snapshot of the target volume. And every seven days, it creates a new base
image. Activity is logged in the Microsoft/Backup/Operational log. You can check
there to see if your backups completed successfully; you can also associate a task,
such as sending an e-mail message, with the success and failure events so you will
always know the status of your scheduled backups.

Scheduling Backups from the Command Line

If you are scheduling backups on a Server Core installation or you just want to
script the process, you can manage the backup schedule using the WBADMIN
command-line. To add a scheduled backup, you use the WBADMIN ENABLE
BACKUP command, specifying the target, source, and scheduled time, like so:

Copy Code
C:\> wbadmin enable backup –addtarget:e:

-include:c:,d: -schedule:06:00,12:00,18:00

This command would back up the C: and D: drives to the E: drive three times a
day, at 6:00 A.M., 12:00 P.M., and 6:00 P.M. (note that all times are specified using
a 24-hour clock). To back up all critical system volumes (from which you can
perform a bare metal restore or a system state restore), replace the –include
switch with –allcritical.
You can also use WBADMIN to disable all scheduled backups, like this:

Copy Code
C:\> wbadmin disable backup

This command will delete all the scheduled backup jobs created by the Windows Server Backup
scheduler and release all the backup target volumes for normal use. Note that you can always
use the WBADMIN MMC snap-in to remotely manage the backup and restore activities of Server
Core servers.

Bare-Metal Recovery of a Domain Controller

One of the most exciting improvements for backup and recovery is how the WinRE
has been incorporated into the installation process. When you boot Windows
Server 2008 from the installation media, you can choose the Repair your computer
option, as shown in Figure 7. I point this out because it is easy to miss if you're
not looking for it.
Figure 7 The Repair your computer option is available on the installation
screen (Click the image for a larger view)
After I select the repair option on the installation screen, Windows lets me select a
recovery option, as shown in Figure 8. In this case, I select Windows Complete PC
Restore, which invokes the Windows Recovery Environment.

Figure 8 Specifying system recovery options (Click the image for a larger
view)
After you select the operating system you want to repair (there is typically only
one choice), WinRE allows you to select the backup from which you want to
restore. By default, WinRE selects the most recent complete system backup, but
you can specify other backups stored on local disks or search the network for
backups that are stored on file shares on other servers.
In my example, I select the most recent complete system backup. The next dialog
(shown in Figure 9) lets me format and repartition all the disks before they are
restored. This is an appropriate option if the problem you are recovering from was
caused by some sort of disk failure or if you've replaced one or more disk drives in
the server.

Figure 9 You can easily format and repartition disks before they're
restored (Click the image for a larger view)
After a couple of confirming dialogs, WinRE starts the restore process and the
server reboots. This is a pretty painless way to perform a bare-metal recovery on a
server.

System State Recovery of a Domain Controller

If you need to recover from some sort of Active Directory-related problem—such
as recovering a deleted OU from backup—you should restore the Active Directory
Domain Services (ADDS) database to an earlier state, rather than restore the
entire system. Even though you can stop ADDS like a service in Windows Server
2008, you still need to boot the server into Directory Services Restore Mode
(DSRM) to perform a system state restore on a domain controller.
Changing the boot options to make Windows Server 2008 boot into DSRM is not
quite as easy as it used to be. The entire Windows boot environment has been re-
engineered to support the new Extensible Firmware Interface (EFI) and the old
school boot.ini file no longer exists. Instead, Windows Server 2008 uses Boot
Configuration Data (BCD) to control the boot process.
The simplest way to manage the BCD is to use the BCDEDIT command line
program. A discussion covering all the BCDEDIT commands and options would
require its own article, so I'll just show you some useful examples here.
To reboot a Windows Server 2008 DC into DSRM, use the following command:

Copy Code
C:\> bcdedit /set safeboot dsrepair

This will set the safeboot option for the default boot loader entry. In a fresh Windows Server
2008 installation, there is only one boot loader entry, WINLOAD.EXE. To remove the safeboot
option and reboot in normal mode, use this command:
Copy Code

C:\> bcdedit /deletevalue safeboot

To make things a little easier for yourself, you can configure two bootloader
entries on your DCs—one for a normal boot and one for a DSRM boot. This way,
you can change the boot options using the Startup and Recovery settings dialog
available under System Settings. To add a new bootloader entry, use this
command:

Copy Code
C:\> bcdedit /copy {default}

/d "Directory Service Repair Mode"

This action will create a new bootloader entry by copying the default bootloader entry. BCDEDIT
will display something like this:

Copy Code

The entry was successfully copied to

{c50d4710-a1f0-11dc-9580-0003ff402ae9}.

The GUID identifies the new entry. Then use this command to set the safeboot
option for the new bootloader entry in the BCD:

Copy Code
C:\> bcdedit /set {<GUID for new entry>}

safeboot dsrepair

You can now switch from normal boot mode to DSRM boot mode using the Startup
and Recovery settings (see Figure 10).
Figure 10 Disable incremental backups on busy volumes
Before you use WBADMIN to start a system state restore, you must identify the
backup from which you want to restore. WBADMIN can perform a system state
restore from either a full system backup, a backup that contains just the critical
system volumes, or a system state backup. In any of these cases, you have to
specify the version of the backup you want to use. The easiest way to identify the
backup versions that are available is to use the following WBADMIN command:

Copy Code
C:\> wbadmin get versions

WBADMIN will then display the backup versions in a form similar to the info shown
in Figure 11. Note that each backup has a backup time, backup target, a version
identifier (which, by the way, is the time and date the backup was started in
Universal Mean Time), and a list of the types of recovery operations the backup
can support.
Figure 11 Identify backups available for recovery

Copy Code

wbadmin 1.0 - Backup command-line tool

(C) Copyright 2004 Microsoft Corp.

Backup time: 11/30/2007 3:47 PM

Backup target: Fixed Disk labeled E:

Version identifier: 11/30/2007-22:47

Can Recover: Application(s), System State

Backup time: 12/1/2007 10:46 PM

Backup target: Fixed Disk labeled Backup(E:)

Version identifier: 12/02/2007-05:46

Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery,

System State

Backup time: 12/2/2007 5:58 PM

Backup target: Fixed Disk labeled Backup(E:)

Version identifier: 12/03/2007-00:58

Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery,

System State

Backup time: 12/3/2007 11:25 AM

Backup target: Fixed Disk labeled E:

Version identifier: 12/03/2007-18:25

Can Recover: Application(s), System State

In this case, I select the most recent backup and start the system state restore
with this WBADMIN command:

Copy Code
C:\> wbadmin start systemstaterecovery

–version:12/03/2007-18:25

This will perform a non-authoritative restore. If you want to perform an authoritative restore of
the SYSVOL, you can just mark the restored SYSVOL replica as being authoritative by adding
the authsysvol option to the WBADMIN command. For more information on this process, see
go.microsoft.com/fwlink/?LinkId=113152.

Taking Active Directory Snapshots

One of the most exciting changes in terms of backup for Active Directory has
nothing at all to do with Windows Server Backup. In Windows Server 2008, you can
take advantage of the fact that Active Directory can provide Volume Shadow Copy
Service snapshots. These snapshots are very lightweight, point-in-time backups of
the running Active Directory service. And even better, they take only a few
seconds of your time to create! You can then mount these snapshots and access
them using normal LDAP-based utilities, such as the LDP tool.
You take snapshots of ADDS or Active Directory Lightweight Directory Services
(ADLDS) using the NTDSUTIL command, as shown here:

Copy Code

ntdsutil: snapshot

snapshot: activate instance ntds

Active instance set to "ntds".

snapshot: create

Creating snapshot...

Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated

successfully.

snapshot: quit

ntdsutil: quit

This sequence of NTDSUTIL commands creates a Volume Shadow Copy Service

snapshot of the volumes that contain the Active Directory DIT, logs, and SYSVOL.
Even though Active Directory is still being updated, Volume Shadow Copy Service
uses a copy-on-write strategy to make sure that the snapshots you've taken are
properly maintained. Note that the snapshots are not a complete copy of the DIT.
They are really just a collection of disk blocks in the DIT that have been modified
since the snapshot was taken. By combining these blocks with the current copy of
the DIT, VSS can present the Active Directory DIT just as it appeared at the time of
the snapshot. Figure 12 shows how to delete old or unneeded snapshots.
Figure 12 Delete unneeded snapshots

Copy Code

C:\> ntdsutil

ntdsutil: snapshot

snapshot: list all

1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}

2: C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}

3: D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1

Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\

$SNAP_200712032318_VOLUMEC$\

Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\

$SNAP_200712032318_VOLUMED$\

snapshot: quit

ntdsutil: quit

C:\>

Mounting Active Directory Snapshots

In order to use one of these snapshots, you must first instruct Volume Shadow
Copy Service to make the snapshot available to the file system. You do this using
the ntdsutil command to list the available snapshots and then mount the snapshot
you are interested in (see Figure 13).
Figure 13 Using ntdsutil to mount a snapshot

Copy Code

C:\> ntdsutil

ntdsutil: snapshot

snapshot: list all

1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}

2: C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}

3: D: {2bbd739f-905a-431b-9449-11fba01f9931}

snapshot: mount 1

Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\

$SNAP_200712032318_VOLUMEC$\

Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\

$SNAP_200712032318_VOLUMED$\

snapshot: quit

ntdsutil: quit

C:\>
The "list all" command lists all the available Active Directory snapshots that are
currently being maintained by Volume Shadow Copy Service. The "mount 1"
command mounts the selected snapshots of the Active Directory DIT and log
volumes and makes them available in the file system. They are located at C:\
$SNAP_200712032318_VOLUMEC$\ and C:\$SNAP_200712032318_VOLUMED$\.
If you look in these folders, you'll see the entire contents of those volumes as they
were when the snapshot was taken. Note, however, that the mounted snapshots
are read-only—meaning you can't modify any of the files in the mounted snapshot.

Recovering Data from Active Directory Snapshots

The task of mounting the snapshots of the volumes that contain Active Directory
seems a bit like magic. How can you get to the Active Directory data contained in
those snapshots? The secret is the DSAMAIN command. This is the executable that
runs ADLDS. It is essentially a standalone LDAP server that shares almost all of its
code with ADDS. You can use DSAMAIN to make the mounted snapshots look like a
read-only LDAP server containing the Active Directory data as it was at the time
the snapshot was taken.
Consider this command:

Copy Code
C:\> dsamain –dbpath

c:\$snap_200712032318_volumed$\ntds\dit

\ntds.dit -ldapport 10000

This mounts the ntds.dit file located in the c:\$snap_200712032318_volumed$\ntds\dit folder

and makes it available to LDAP operations on TCP port 10000 (or whatever open port you
specify). DSAMAIN will open the LDAPS port (the port used for LDAP over Secure Sockets Layer)
on the port you specified plus one (in this case, 10001), the GC port (the port used for global
catalog connections) on the port you specified plus two (10002), and the GCS (Global Catalog
over Secure Sockets Layer) port on the port you specified plus three (10003).
You can use any LDAP program (such as LDP) to access the mounted DIT on the
specified port. But in Windows Server 2008, Active Directory Users and Computers
(ADUC), Sites and Services, and Domains and Trusts, as well as ADSIEDIT, have all
been modified to allow you to connect them to a DIT mounted using DSAMAIN. If
you right-click on the top-level node in the navigation pane of any ADUC and
select Change Domain Controller, you will see the dialog box shown in Figure 14.
If you simply type the name or IP address of the server hosting the mounted
snapshot, along with the port (in my example, localhost:10000), ADUC will connect
to the mounted snapshot, allowing you to browse the contents of the directory as
it existed at the time of the snapshot. Pretty amazing, isn't it?
 Figure 14 Connecting Active Directory users and computers to a mounted
snapshot (Click the image for a larger view)
Being able to access directory data in this way makes many kinds of data recovery
tasks much easier than they used to be. For instance, to recover a deleted object
from a backup formerly required that you perform a non-authoritative restore of
the backup on an existing DC and then perform an authoritative restore of the
deleted object. And if the backup you restored didn't have the correct data, you
had to start all over again with a different backup. Now, using tombstone
reanimation and snapshots, you can quickly find and recover deleted data, and
you don't even have to take the domain controller offline to do it.
There are some limitations, however. For instance, each active snapshot increases
the disk I/O associated with write operations to the directory, so you probably
shouldn't have more than one or two snapshots active at any point in time on a
production DC. Also, the longer you keep snapshots active, the larger the Volume
Shadow Copy Service delta store becomes—this can also affect performance. And,
of course, simply recovering a deleted object is only the first part of the recovery
problem. You will probably have to recover the object's linked attributes, such as
group memberships, as well. But even in this case, the snapshot can help you
identify all the groups the deleted object was a member of.

A Sound Backup and Recovery Strategy for Active Directory

Windows Server 2008 brings an entirely new backup and recovery system to the
table. Some of the changes may at first cause weeping and gnashing of teeth. But
once IT organizations have accepted these changes and incorporated the new
backup technology into their day-to-day operations, they will wind up with a more
effective backup and recovery implementation.
Even with all of the changes in the way you back up servers in Windows Server
2008, the basic strategy for backing up and recovering Active Directory doesn't
really change that much. So when planning your strategy, be sure to keep these
best practices in mind:
1. Schedule periodic full system backups so you can recover a DC after a
hardware failure. How frequently you schedule full backups of a DC depends on how
frequently your data is updated, your tolerance for downtime and/or data loss, and
the effort that may be required to rebuild the DC from scratch.
2. Schedule frequent system state backups to back up changes in Active
Directory. How frequently you perform system state backups depends on your
tolerance for lost Active Directory data. But you should do this at least once a day. If
you have the hardware, keep at least one or two system state backups on a local disk
and copy older system state versions to a DVD or to a network share.
3. Be sure to do system state backups on at least two DCs in each domain. This
will provide some insurance in case one of the backups is bad or unavailable.

Be sure to back up DCs with application partition replicas if you have defined
them. And consider creating a Windows Recovery Environment partition on your
DCs so you can boot quickly into WinRE in case a critical system drive fails. 