Windows Server Backup for Active Directory

Correctly backing up and ensuring full recoverability of Active Directory (AD) has always been a challenge for IT administrators. To back up AD, you typically back up the whole domain controller (DC); but although backing up a DC might be simple, understanding when to use which recovery option can be difficult. The good news is that most of what you’ve already learned about AD backup and recovery still holds true for Windows Server 2008.

As with earlier versions of Windows, you can still back up AD by doing a full system backup or a system-state backup of any DC of an AD domain, and you still have to boot the DC in Directory Services Restore Mode (DSRM) and recover its system state to recover AD. You also still have to use the native Ntdsutil tool to perform an authoritative restore of objects should you need to recover an AD object that’s been deleted. Therefore, you don’t need to throw all your existing procedures overboard when you roll out your first Server 2008 DCs.

However, there are changes in the tools (and potentially in the media) you use for DC backup and recovery. You won’t find the well-known ntbackup.exe, the native backup tool in previous Windows versions, on Server 2008. Instead, you use Windows Server Backup, the new native backup solution, which is available as an installation option in all versions of Server 2008, including Server Core.

Server 2008 also gives you some powerful new options to protect AD data from being accidentally deleted and new ways to recover attribute data for AD. Here I describe these changes, focusing on how the underlying backup mechanisms have changed with Windows Server Backup and how you can use the new snapshot capabilities in Server 2008 for AD. The snapshot feature is worth spending some time with if you want to have faster and complete online recovery of objects without needing to reboot your DC. In an upcoming article, I’ll discuss how to prepare for an efficient online recovery of deleted objects, levering tombstone reanimation and Microsoft Volume Shadow Copy Service (VSS) snapshots of an AD database. But first things first—let’s look at how to use Windows Server Backup for AD backup and recovery.

Introducing Windows Server Backup
Don’t think of Windows Server Backup as an update to Ntbackup, because it isn’t. In fact, Windows Server Backup is completely new and has little in common with Ntbackup. For starters, it has an entirely different UI, as you can see in Figure 1. However, the difference between the old and new utilities becomes even more apparent once you realize that Windows Server Backup is designed to do only disk-to-disk backup and to use VSS. Here’s a rundown of the most important differences between Windows Server Backupand Ntbackup.

• Windows Server Backup uses VSS to create block-level backups from source volumes and to allow efficient creation of incremental backups. The backup files the utility creates on the target volume are actually Microsoft Virtual Hard Disk (VHD) files—the same format used for Microsoft’s OS virtualization solutions. If necessary, you can mount the virtual backup disks to a virtual server for direct access or to a physical server (using the Vhdmount tool that comes with Virtual Server 2005). However, Windows Server Backup’s backup function using a VHD file differs from a physical-to-virtual migration tool in that it doesn’t prepare the VHD to be bootable on a virtual machine. Physical-to-virtual migration tools convert physical instances of servers to virtual machines, replacing important hardware-level drivers with corresponding drivers that are required for the server to run as a virtual machine. Windows Server Backup doesn’t do this conversion.

• Windows Server Backup can back up and restore only NTFS volumes. (On IA64 systems the utility also supports the Extensible Firmware Interface system partition.) Both Master Boot Record and GUID Partition Table partition types are supported.

• Windows Server Backup always backs up whole volumes—you can’t back up individual files or folders, although you can specify particular files or folders to restore. The exception is a system-state backup, which includes all necessary system files but doesn’t back up theentire volume.

• Although Server 2008 still provides the APIs for tape access and media changers, Windows Server Backup can’t back up to a tape drive. Rather, it backs up only to an internal or externally attached disk—and only to basic disks, not to dynamic or Encrypting File System– encrypted disks.

• Other supported backup targets for Windows Server Backup are network shares and DVD media. However, because the system can’t perform a Volume Shadow Copy Service snapshot to a network share or a DVD, these two target types don’t let you store multiple backup versions on the same target. Additionally, a system-state backup can’t be performed directly to a network share; it needs to use a local volume.

• Windows Server Backup’s UI doesn’t support a system-state backup; however, all backup commands are available through the wbadmin.exe commandline tool.

• With the exception of a system-state backup, Windows Server Backup can’t store a backup on the same volume as the one that’s being backed up.

• Windows Server Backup is designed to allow very easy full-system recovery, so there’s no need to install a new server OS before you can recover from a backup. Windows Server Backup can quickly recover a server from bare metal.

So what do the changes in the native backup tool mean for backup and recovery of Server 2008 AD DCs? There’s no need to back up every DC in your forest— you can always recover a DC by re-promoting it and replicating the data from another DC. For backup redundancy, however, you should back up at least two writeable DCs per domain in your forest. Although backup and recovery of read-only domain controllers (RODCs) is generally supported, you can’t authoritatively restore objects backed up from an RODC because RODCs don’t replicate changes to other DCs.

Windows Server Backup requires you to provide a separate target volume for the backup data. This requirement might pose a challenge for single-volume server configurations, but if you have the space to partition your DCs, you can create a volume dedicated solely to backup data. If that isn’t possible, you can still perform a backup to a network share. And if your system volumes contain a lot of other data that you don’t care to back up over the network (or to a different drive), you can perform a system-state backup—even on the same volume as the source data—to ensure recoverability of the DC’s AD database. For instructions on how to store a system-state backup of a Server 2008 DC on the source volume, see the sidebar “Storing a DC System-State Backup on the Source Volume.”

Realize that in contrast to a full system recovery, a system-state recovery doesn’t perform a block-level restore and thus doesn’t erase the target volume before the restore. A system-state recovery is filebased, recovering all Windows System files and registry settings to the state they were in at backup. A system-state recovery doesn’t restore applications that were installed on the server and doesn’t recover local user profiles.

Continue to page 2

Backing Up a DC
The first step toward backing up a DC is to install Windows Server Backup on your Server 2008 system. On a full server installation, using Server Manager’s Add Features Wizard is the easiest approach. On a Server Core system, execute the command

ocsetup WindowsServerBackup

Before you perform any backups, you need to configure the Optimize Backup Performance settings for Windows Server Backup. You can find these settings in the Windows Server Backup menu’s task pane or by right-clicking the Windows Server Backup node under Storage in the Server Manager tree. By default, Windows Server Backup always performs a full backup, but as Figure 2 shows, you can configure it to perform incremental backups. Unfortunately, Server Core offers no command-line option to help you configure the settings. Microsoft recommends connecting to the Server Core box from a full server running Windows Server Backup and configuring the settings remotely.

The Optimize Backup Performance settings let you specify whether Windows Server Backup should keep or erase the VSS snapshots that it automatically creates on the source disk during each backup cycle. When you choose incremental backups, you choose to keep the snapshots on the disk; when you choose full backup, the snapshots are erased after the backup is finished. Keeping the snapshots lets the system automatically track changes on the source disk at runtime. However, tracking changes requires VSS to copy the original block to the shadow copy area before overwriting the source block. That procedure initiates extra disk activity and requires additional space on the source disk. On servers with write-intensive applications, keeping the shadow copies can slow disk performance.

Which option should you choose for your DCs? Incremental backups are better for two reasons. First, DCs are much more often read from rather than written to, so they tend not to be write intensive and don’t take much of a performance hit from the VSS activity. Second, you can use the shadow copies for other AD recovery options. For each of your hard disks, you can configure the amount of space devoted to snapshots by using the Microsoft Management Console Disk Management snap-in or the vssadmin .exe command-line tool, both of which are installed with the OS.

On a full-server system, you can configure a backup with a few simple choices in the Windows Server Backup UI. On Windows Server Backup’s Action menu, click Backup once to launch the Backup Once Wizard and let it guide you through the configuration process. When you reach the Select backup items page, make sure that the Enable system recovery check box is selected to ensure recovery of the AD database. The Enable system recovery option backs up all volumes that contain systemstate data. Note that you can also schedule a backup; however, this option requires a dedicated local disk that’s used only by Windows Server Backup.

The best way to deploy DCs, however, is on a Server Core system, as it is more secure by default and thus reduces the attack surface on your DCs. But of course, a Server Core deployment means that you have to do most administration through the command line. Here’s how to perform a backup from the command line:

1. To back up the full system, including all critical volumes (i.e., those that contain system data such as the AD database), thus allowing bare-metal recovery, run the command

WBADMIN Start Backup –backupTarget:D:  -allCritical

replacing D: with the target drive on which you’ll store the backup. If the target is a network location, enter the Universal Naming Convention path to the share (e.g., \Server2.corp.netBackupData).

2. To back up only the system state, use the command

WBADMIN Start SystemStateBackup  –backupTarget:C:

Note that this command doesn’t require the -allCritical option; the Start System- StateBackup command always backs up all system data.

With either command, the result is a folder on the target named WindowsImageBackup. The folder contains a subfolder with the server’s short name (“W2K8Full04” in Figure 3). The actual backup data is stored in the server folder, primarily in a VHD file that contains all the blocks of data. Some XML files hold registry and other settings. You can copy the whole WindowsImageBackup folder to a different location (on the network or on disk), but you must keep the same folder structure to allow the recovery process to find the backup data.

Unless you’re using the DC for many other functions (which is most likely for small-to-midsized businesses) and have no opportunity to back up the full system to a local drive, there isn’t much point in creating just a system-state backup for DCs. A full system backup of a Server 2008 DC that doesn’t host a plethora of other services (which is the optimal case for writeable DCs) typically isn’t much larger than a system-state backup of the same machine. More important, with a full system backup you can perform incremental backups, which you can’t when using the system-state backup option. Incremental backup saves considerable time and disk space if you want to keep multiple backup versions on your target disk. Also, you can use full-system-backup files to perform a system-state recovery.

Performing a Complete DC Recovery
Recovering a Server 2008 DC from scratch with Windows Server Backup involves a few more steps than does performing the backup. But compared to the process for earlier Windows OSs, which used Ntbackup to perform full system recoveries, the new process is fairly simple: It doesn’t require you to first reinstall the OS, but simply applies the image of the system volume(s) stored in the backup’s VHD file(s).

1. Boot the server from Server 2008 installation media. Doing so boots the server into the same Windows Preinstallation Environment session that you use to deploy a new Server 2008 instance.

2. At the Install Windows screen, choose Repair your computer at the bottom left. This option starts the Windows Recovery Environment (Windows RE), which lets you perform various repair and recovery tasks on the server. Windows RE tries to determine which OS is installed on the server and requires access to the local disks at this time; if necessary, you can load drivers from CD, DVD, USB, or the floppy drive.

3. After Windows RE finds and selects your OS, click Windows Complete PC Restore to do a full system recovery. The Windows Server Backup restore procedure searches the local, USB, and DVD drives for the disk-based backup media to use as the source for the system recovery. You can also manually connect to a network share to recover the system from a backup stored on a remote machine.

4. Choose the backup source you want to use for the actual recovery operation. A complete recovery wipes all data from the target disk and performs a block-level restore. If your system has multiple volumes, you can choose to recover specific volumes; only those you choose to recover will be erased during the recovery procedure. You’ll be prompted to acknowledge the erasure of all data on the target disk before the recovery proceeds.

5. After completing the restore, the system will automatically reboot the DC and bring it back online. The DC will then synchronize with AD to replicate all changes that were made since the backup was performed.

Combining a full system recovery of a Server 2008 DC with an authoritative restore of objects (e.g., to recover an accidentally deleted object) requires special precautions. You need to ensure that the server boots into DSRM (press F8 during the boot sequence to choose DSRM) immediately after the system recovery is complete (i.e., before replicating with other DCs). Server 2008 still requires DSRM to allow access to the AD database for performing authoritative restores using the Ntdsutil tool. This process hasn’t changed from earlier OS versions.

Performing a System-State Recovery
If you need to recover only AD, you can restore just the DC’s system state. However, a system-state restore requires a fully operational OS. Also, because the Windows Server Backup UI doesn’t support a systemstate restore, you need to use the Wbadmin command-line tool. A system-state recovery of a Server 2008 DC is a bit tedious because you must use the command line, but the process is similar to that of restoring the system state of an earlier version of Windows.

1. Boot the DC into DSRM by pressing F8 during the boot sequence and use the recovery password to log on as Administrator. If necessary, you can recover the system state to a brand-new, similarly configured Server 2008 server on which the Windows Server Backup feature is installed.

2. Open a command prompt and locate available backup versions via Wbadmin by using the command

wbadmin get versions  -backupTarget:drive_or_share  machine:servername

where drive_or_share is the path to the backup target and servername is the name of the machine being restored. The output will resemble that in Figure 4.

3. From the output, identify the backup version to use for the system-state recovery. You can recover the system state from any backup that lists System State in the Can Recover line. Copy the version identifier (e.g., 01/27/2008-15:18) for use in the next step.

4. Start a system-state recovery of the desired backup version using the following Wbadmin command:

wbadmin Start SystemStateRecovery  -version:versionID  backupTarget:drive_or_share  machine:servername

where versionID is the version identifier from the Get Versions output. When prompted, confirm the recovery. Wbadmin will mount the backup’s VHD file and copy the required files to the source drive. Be prepared: A system-state restore can take considerably longer than a full-volume recovery, which is block-based.

5. After recovery, the server will want to reboot. If you want to perform an authoritative restore of AD objects, don’t reboot until you’ve run Ntdsutil with the appropriate options.

6. Reboot the system to replace all files that were in use during recovery. Rebooting takes time, and the server might have to reboot more than once to replace specific files and complete the system-state recovery, but rebooting is an important part of the recovery process. Successful systemstate recovery is confirmed by a command prompt at the first logon after rebooting.

Forest Recovery Considerations
With this background information, you should be well prepared to plan your own DC backup and recovery. This information might even affect how you plan to set up the volumes used on a DC for data and for backup, because you’ll need a separate target volume for your backups when using the full-system backup method. I recommend performing a volume-based fullsystem backup over a system-state backup if your DC configuration allows it—a fullsystem backup is more efficient and lets you perform fast incremental backups. Both methods let you restore just the system state (which is required to restore the AD database on a DC). However, a volume-based system recovery outperforms a file-based system-state recovery.

Forest recovery continues to be a special challenge, which I don’t have room to go into here. But as long as you back up your DCs regularly and have at least two DCs per domain in your forest, you’re prepared to perform a forest recovery as well.

A major benefit of Server 2008 is that ideally you’ll deploy writable DCs only within your well-connected hub sites and use RODCs in all locations outside of your hub data centers that contain DCs. The benefits of using RODCs include a smaller attack surface and improved security for your overall IT infrastructure. However, RODCs also provide benefits from a forest-recovery perspective because they don’t require the same attention as writeable DCs during recovery. RODCs can’t replicate data to the hub, and that makes for a much smoother and faster forest recovery. RODCs help you concentrate on your hubs and recovering your DCs without worrying about interference from remote DCs. After the hubs are online and working, you can tackle the RODCs at the remote sites.

Taming the AD Backup Beast
AD backup and recovery is still a complex process in Server 2008. You have powerful new options to help you with this task, but you need to learn how to use them correctly. In an upcoming article, I’ll explain how VSS snapshots provide a feasible way to recover attribute data from AD, letting you implement a real online recovery of objects that you might have accidentally deleted. I’ll also show you some new options in Server 2008 that help prevent accidental deletion of AD data.