The Disk Images & System State tab allows you to incorporate regularly scheduled native Windows disk backups or system state backups into the backups done by your branded client. We leverage the wbadmin command that is built into Windows to make bare-metal disk images that are used to recover a system through a Windows Recovery Environment or to make a system state image that can be used to roll back server settings to a prior good state.
The wbadmin command was introduced with Windows Server 2008 and Windows Vista, so earlier versions of Windows are not able to utilize this client-side feature.
We use the following syntax for the Disk Image backups:
wbadmin start backup -backupTarget:x: [-include:y:] -allCritical [-vssFull] -quiet
The 'backupTarget' syntax designates the drive the disk images will be saved to.
The 'include' syntax allows for non-critical drives to be added to the disk images. If no non-critical drives are selected, it is not included in the syntax.
The 'allCritical' syntax is key for creating a system-restorable disk image backup.
There is an option to turn off the 'allCritical' syntax for Disk Image backups. Do NOT enable this setting unless the computer has a FAT32 EFI boot partition. The wbadmin command cannot back up FAT32 partitions, and the EFI boot partition is marked as a "critical" partition. This combination leads to the disk image backup to fail because of the FAT32 partition. This option should only be enabled if past disk image backups have failed because of this.
Disk images made without the 'allCritical' syntax are not supported by Microsoft to do bare metal restores.
The 'vssFull' syntax will be added if you have selected the VSS_FULL backup mode on the Expert Settings tab, which is visible when you enter Expert mode on the client.
The 'quiet' syntax prevents wbadmin from waiting for user input when performing the disk image backup.
When the Disk Image backups are enabled, the above command will run with every scheduled backup, and it will save the disk images to the destination hard drive; it will create a WindowsImageBackup folder, that will contain sub-folders with the Windows disk image (.VHD), as well as many small meta-data files.
The destination drive can be either a local hard drive, network mapped drive, or (preferably) a local USB hard drive. A local drive is preferable to a network mapped drive because if it is done to a local drive, it will fully utilize VSS snapshots to keep a history of prior disk image backups. Done over the network, this is not possible, so only the latest disk image will be available.
When done to a local USB drive, it allows you to have a portable solution with multiple versions available for you to use in a Windows Recovery Environment to restore a system to its original hardware, or on to replacement hardware.
In addition to this local copy of the disk image, you can add the disk images to your backup selections to your remote backup server.
The .VHD and .VHDX files associated with these disk image backups will be very large. On a very minimal Windows Server 2008 R2 install, the .VHD is over 25 GB. On a fully deployed server environment running services like SQL or Exchange, it will be much larger. You should account for this when you perform the initial remote backup for this data. One option would be to do a local seed that can then be moved to your remote server. Thankfully, these .VHD and .VHDX files perform well under differential scans, so after the initial seed the subsequent backups of these files will be quicker.
The initial time you run the disk image backup, it will take a long time to run. This is due to first the wbadmin command taking a long time to create the initial .VHD, and second the time it takes to compress and encrypt the .VHD. Please be sure to allow a few extra hours for the backup to run the first time a disk image backup is done.
We use the following syntax for System State backups:
wbadmin start systemstate backup -backupTarget:x -quiet
The 'backupTarget' syntax designates the drive the system state backup will be saved to.
The 'quiet' syntax prevents wbadmin from waiting for user input when performing the system state backup.
As a general rule, the system state backups will be smaller in size than their full disk image counterparts, but also can't be used to do a bare metal restore for the server. Instead, its purpose is to provide a way to roll back the settings and configurations on a server to a prior known good state. An example where this can be useful is if you're doing a major Windows update, or trying to upgrade Exchange Server or SQL Server to a newer version, and something goes wrong.
The file and folder structure for system state backups is very similar to what gets generated by a full disk image, and the same rules apply for the destination drive.
Installing the Windows Server Backup Feature
Although wbadmin comes installed by default on consumer-grade Windows, on the server versions of Windows, you need to ensure that the 'Windows Server Backup' features are installed. To make sure you have the feature installed, you can check from the Server Manager:
1) Open Server Manager
2) Go to Features, click on 'Add Features'
3) If 'Windows Server Backup Features' is not selected, select it and make sure 'Command-line Tools' is also selected.
4) If you had to select them, make sure to install the features.
Enabling and Configuring Disk Images or System State
To enable a disk image backup, select the 'Recovery Disk Image' option from the drop-down menu.
This will then allow you to select the Destination disk, which may be any local drive attached to the computer. The destination disk can NOT be the same as one of the disks you intend to back up in this manner. This is another reason a USB hard drive is preferable.
With the Destination set, you should then select which other local drives you want backed up in the "Selected disk(s) to image" field. The Destination disk will be greyed out to prevent its selection. You also cannot deselect any critical system volumes (usually the C:\).
Similarly, to enable a system state backup, click the 'System State Backup' option from the drop-down menu. You will then select a Destination disk, like with a disk image backup, but you will not be able to select additional disks, since a system state backup doesn't have an option for such.
With the above options set, the disk image or system state backup will run with every scheduled backup, but it will be only to the local destination disk. If you want the disk images/system state to be uploaded to your server, you will need to enable remote backups as described below.
Remotely Backing Up Disk Images & System State
With disk images or system state enabled, you are then able to add the image backups to your scheduled remote backup data set. This is done by selecting the days of the week you want the backup to be backed up remotely. Selecting Everyday, Weekday, or Weekend will select the appropriate individual days.
As with all large files, it will take a noticeable amount of time for the backup process to compress, encrypt, and do a differential scan on the large .VHD or .VHDX generated by the disk image/system state backup. This will be the case even after the initial backup of the .VHD and .VHDX, because the compression and encryption must be run each time a file is to be differentially scanned for backup. With older versions of our software .VHDX files did not perform well under differential scans, so selecting them for backup often meant backing them up entirely each day they are selected for backup. Thanks to the way we now perform differential scans on these files, we can back these up with significant deduplication savings which means you can get regular offsite image backups with less storage concerns.
You must ensure that there is enough free cache space available for the compression and encryption of the .VHD can be done. It is recommended that there is 2.5 to 3 times as much free space available for cache space as the largest file that is being backed up, which is likely to be the .VHD file. It is a good idea to not include the Windows disk image backup in your remote backup set until you know the overall size of the .VHD. If you are unsure where the client's cache folder is pointing to, you can check here.