Automated System Recovery or ASR as it is more commonly known is the Windows API set to capture the configuration of disks and volumes on a system and restore them in bare metal recovery scenarios. During such recoveries, backup applications (requesters) invoke ASR to restore the disks and volumes prior to putting back the operating system, applications and data.
For the purpose of bare metal recovery scenarios, the disks and volumes in a system can be divided into two broad categories – critical and non-critical. Critical volumes are those containing system state or operating system components and include the boot and system volumes. A volume containing the Active Directory database on a domain controller is also an example of a critical volume. Critical disks as you’ve likely guessed are those that contain critical volumes.
Once the operating system and data have been put back, requesters may perform more recovery operations after the system is booted into the restored operating system.
ASR Writer: ASR in Vista and Server 2008 is tightly integrated with the Volume Shadow Copy Service (VSS) and presents a writer interface, which is a significant change from Server 2003 and XP. During a backup the ASR writer reports metadata describing all the disks and volumes on the system. During the restore the requester passes the same metadata back to the writer which recreates disks and volumes as necessary.
The ASR writer will fail a restore if it cannot find or recreate all the critical disks necessary to restore all the critical volumes. Non critical disks are restored on a best effort basis and requesters may control that behavior using include and exclude options.
During a restore, disks with layouts identical to that during backup are not recreated. Exactly what constitutes an identical layout is described in detail in the documentation on MSDN. Note that in the case of dynamic disks the granularity of restores is at the pack level. In the event that a disk is intact, ASR will still format all the critical volumes on that disk and leave any data volumes untouched.
To avail of ASR functionality for bare metal recoveries, backup applications must build their solutions on a WinPE environment. It is important to note that the VSS service itself doesn’t run in WinPE and in fact ASR is the only VSS writer available for restores in WinPE.
ASR ships with the same feature set in Vista SP1 and Server 2008, which includes all the functionality in Vista.
Support for EFI systems: The most notable addition since Vista is support for EFI systems i.e. ASR in Server 2008 and Vista SP1 can recreate EFI system partitions in a bare metal recovery. This was done to support the industry move to EFI based systems which are becoming increasingly common.
Dynamic disks: In Vista, ASR would always recreate dynamic disks even if they had layouts identical to that during backup. With SP1 and Server 2008 that behavior has been modified so that the writer will treat dynamic disks like basic disks and not recreate them during restore if it detects that the layout is unchanged from the time of the backup.
This prevents the accidental loss of data volumes when dynamic disks are recreated to restore critical volumes since restores of dynamic disks happen at the granularity of packs.
Improved Tracing: ASR in SP1 and Server 2008 supports ETW tracing which among other things is more performant and can be configured easily at run time. This makes for easier diagnostics and trouble shooting and was motivated by feedback from Vista customers.
That’s about it for the changes to ASR in Vista SP1 and Windows Server 2008. You can find a detailed explanation of all the APIs and their usage on MSDN. If you have comments, feature requests or anything you would like to know more about, write us at asr(nospam)@microsoft.com.