The new backup system, Windows Server backup, is really cool. WSB is designed to simplify the scenario of performing routine daily backups, and being able to recover from these backups quickly and easily, even from bare metal. It performs volume-level backups instead of file-level backups the way NTBACKUP did. This means that you back up entire volumes, not sets of files. Some of the nice features:
- WSB uses VSS on the source volumes to capture a consistent view of the source (as did NTBACKUP)
- WSB uses VSS snapshots on the source to perform block-level differential reads. This can substantially reduce the amount of disk I/O on the source volume, paticularly if the volume is large and mostly read-only.
- WSB uses VSS snapshots on the target volume to minimize the storage requirements. If you perform multiple full backups, WSB stores one full copy on the target, plus all the changed blocks. This is much better than doing file-level incremental backups.
- WSB stores backup images in VHD format. You can mount the backup images in a virtual machine and use them as regular disk volumes.
WSB only backs up to local disk or to network file shares... there is no support for backing up to tape. You can always copy the saved WSB-generated backup images to tape if you want, and in fact, its probably a better overall backup strategy to back up to disk on all your servers, copy the images to a central location or locations, and then copy the images to tape or optical media there. But the lack of backup to tape support will be a big headache for some people.
System state backup and restore are bit of an afterthought in WS2008... early Beta versions of the OS didn't have system state backup/restore, and even now in RC1 its only available through the command-line. That's no big deal in itself, but there are limitations on system state operations that are a bit, well, limiting. For isntance, you can't perform a system state backup to a file share; the target volume has to be local. I don't know why this is the case, or if it will change, but there it is. The size of the system state image, at least in the default case, has grown substantially as well. On a 32-bit system, with a default DIT, the system state image runs about 6.5GB! This makes system state backups and restore take correspondingly longer. And even though you can stop AD on a domain controller using Service Manager, or NET STOP NTDS, you still can't perform a system state restore unless you boot the DC into DSRM, which effectively takes the DC offline.
But, you can restore the DS from a system state backup without booting into DSRM, and you can do it pretty quickly. I'll start off by saying that this scenario is almost certainly not supported, but it does seem to work ok. The steps are as follows:
- Perform a system state backup to a local backup volume on your DC.
- Share the backup volume on the DC.
- Create a virtual machine in VS 2005 R2 or Hyper-V. Make sure it has access to the network with your DC.
- Either copy the system state .VHD to the VS host, or map a drive from the VS host to the shared backup volume. (You see where I'm going with this, don't you?)
- Add another disk to the VM, and use the system state .VHD as the supporting file.
- Boot up the VM. The guest OS isn't critical... I used WS2003 R2 EE x86. The VM will come up using the system state VHD as its second disk.
- In the VM, share the second disk (the one that uses the system state .VHD file).
- On your DC, stop the DS using the Services MMC or NET STOP NTDS.
- Map a drive to the shared second disk on the VM.
- Copy the entire NTDS (and SYSVOL if you need to) folders from shared VM disk to the appropriate place on the DC.
- If you need to do an authoritative restore, run NTDSUTIL and perform the appropriate auth restore steps.
- Restart the DS using the Services MMC or NET START NTDS .
Voila, you have restored your DIT from a system state backup without booting into DSRM, and while having the DS unavailable only for the time it took to copy the DIT over the network and perform the auth restore.
It gets more complicated if you store the DIT, logs, SYSVOL etc. on separate volumes... the system state backup will create a VHD file for each, and you'll have to mount all of them in the VM. But the basic idea still works.