If you have ever tried to use Windows Backups in an enterprise environment then you are probably aware of how obtuse the program can be. There is very little documentation available for wbadmin.exe and what little information is on technet doesn’t really cover the more complicated aspects of the program. In this post we have performed a thorough investigation into wbadmin to find out what’s going on under the hood and to help you make the most of the Windows Backup system.
wbadmin takes “block” level backups of your system using the Volume Shadow Copy Service (VSS). Backups are written as complete copies of the volume/s to VHD (virtual hard disks) which are a complete mirror of the volumes / partitions on your system.
Windows 7 / 2008 R2 and earlier create “VHD” backup files. Windows 8 and later create “VHDX” backup files. The VHDX format has a number of improvements over VHD including the ability to easily shrink the disk which is more difficult in VHD format
In addition to the VHDs, wbadmin also writes a GlobalCatalog and a BackupGlobalCatalog file to the backup location which contain information about your current configuration and required in the event of a recovery. It also writes a series of XML files to the backup location which appear to be used as part of the restore process although I have tried deleting these files and the restore job seems to be unaffected so I would question how important these are.
wbadmin can perform both full and incremental (differential really) backups. The differential is made on a block-by-block basis and relies on the Volume Shadow Service (vss). Before overwriting a changed block in the backup location, the older block is pushed out into a VSS shadow copy which is stored on a hidden part of the disk. Because historical backups are created using VSS they can only be performed when the job is backing up to a full volume and do not work when backing up to a network share. This is because VSS is block level so it cannot work within the constraints of an SMB file share (it has no concept of what a file or folder even is).
You cannot amend the built-in backup schedule – which is to run a full-backup followed by 14 incrementals (then another full, another 14, etc.) – and wbadmin automatically handles the retention policy so as your backup archive runs out of space it will automatically clear it down. Because wbadmin is built upon VSS your latest backup (i.e. the main copy of the volume) will always be retained and wbadmin will delete the oldest VSS shadow copies of the volume until enough space becomes available. I have actually found in testing that wbadmin will keep more than 14 backups although I’m still unsure what triggers the clean-up of the backup store.
Note that if you are backing up to a network share then a full backup will be run every time (because VSS is unavailable) overwriting the previous full backup. In this case there is no backup policy at all, you are simply maintaining a remote shadow/copy of the system.
It is possible to create your own schedule of sorts by alternating back ups to different drives (or rotating your backup media). So for example you could backup to drive A on Monday, drive B on Tuesday, drive C on Wednesday, etc. Or if you wanted a level-style system you could do A: on Monday-Saturday, B: Sunday , C: 1st of each month and keep rotating like that which would give you partial backups for up to a year, stored over 3 backup sets. Obviously the limiting factor here is space since a level system like this requires a minimum total backup space of 3x the size of your data (for each full backup) plus some extra space for the differentials.
From Windows 7 onwards the OS includes built-in functionality to work with VHD files and the quickest & easiest way to restore data is simply to mount the VHD in your backup as a new drive and copy back whatever data you need. You can manage VHDs in Windows via the DISKPART command line tool or using the Disk Management GUI under Administrative Tools.
Differentials are stored as VSS shadow copies of the volume instead of as incremental backup files typically found in other commercial backup systems. The easiest way to restore data from your historical backups is to use the Windows Server Backup utility bundled with Windows Server 2008 R2 or later however if you want to work with Windows 10 backups then the only version of this tool which worked for us was on the Windows Server 2016 tech preview (although I didn’t try 2012 r2)
For those of you who don’t have access to Windows server then you can also mount the shadow copy as a new drive using this guide (http://forensicswiki.org/wiki/Mount_shadow_volumes_on_disk_images) or alternatively you can use the utility “Shadow Explorer” which allows you to access shadow copies for any drive (http://www.shadowexplorer.com/). In both cases you are mounting a historic version of the volume which then allows you to mount the historic VHD files to restore older files (see point above)
For a full system recovery you need to use the Windows System Image Recovery tool which is available through the Windows Recovery Environment (RE) – basically boot from any Window installation disk and choose the “REPAIR” option. You will also need to run wbadmin backups with the option “-allCritical” (Windows 7 or newer) to ensure that all critical system files are backed up as part of the backup job.
You can tell if your backup configuration is suitable for a full system recovery because the wbadmin “get versions” command will show the tags “Bare Metal Recovery, System State” next to the backup information in the list.
The first major shortcoming with wbadmin is that it will only restore from archives made with the same version of wbadmin (i.e. newer versions of the app are incapable of recovering from older archives). What this means is that you are going to have to match up your version of Windows RE (i.e. your installation media) with the version of the backup you are recovering from. To make matters worse the build (32bit or 64bit) must also match so a Windows 7 64bit installation disk cannot be used to recover a Windows 7 32bit backup. I know, complete madness right? Thankfully once you get through the marketing talk (“starter”, “professional”) there are not that many different versions of Windows (https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions) so you only need to keep a handful of boot ISO in your toolbox.
The next major shortcoming is that the restore process is very temperamental and even slight changes to your configuration (which is not such a crazy scenario following a major outage) can create errors in the restore wizard. The most common one is disk space. Even if your volumes are mathematically small enough to fit on the target drive, the RE will flat out refuse to do it unless the drive is the same size (or bigger) than the one used to create the backup. No amount of shrinking the VHD or editing the XML files in the backup location can get around this limitation (your original configuration is encoded into the GlobalCatalog file and uneditable). In a real disaster scenario you should try to match hardware as best as you can and make absolutely sure that you stick an equivalent -or larger – disk into the recovery system if you want things to run smoothly.
If you do want to image a larger drive onto a smaller one (for example when moving to an SSD) then the only solution is to resize your partitions before making the backup using a tool like Partition Wizard (http://www.partitionwizard.com/free-partition-manager.html). Just shrink your partitions so they comfortably fit on the target drive, then run wbadmin (with -allCritical) then run a full system restore process. Don’t worry about over shrinking your partitions here as you can always expand them again once you have completed the restore job to the SSD.
One big positive with wbadmin backups is that ultimately your data is just being stored in a VHD shadow so if everything goes to shit with the recovery job you can still use another PC to manually ghost the volume/s in the VHD back to another disk. Partition Wizard is great again for this as it allows you to both shrink and copy a volume as one job which saves a lot of time. For those who like their Linux tools there is also DD for Windows (http://www.chrysocome.net/dd) which can be used for copying partitions – if you Google there are lots of examples of how to do it.
One caveat with manually copying the partitions though is that your system probably won’t boot after you’ve done it so you will have to use the Windows “bootrec” tool to manually rebuild your boot sectors. This post contains a full guide on how to do this (https://social.technet.microsoft.com/Forums/windowsserver/en-US/f15bfe2f-e265-479a-afa3-f055530c97f5/windows-server-backup-0x80042407-seriously) or see this Microsoft Support article (https://support.microsoft.com/en-us/kb/927392) for help recreating your boot records
One final nifty trick is that you can use your own VHD file (easily created using the Disk Management tool in Windows) to circumnavigate the VSS limitations and store incremental backups in a file system. Simply create the VHD file, copy it to your desired location (a network share for example) and then mount the VHD as a new drive on the system you are backing up. The DISKPART tool can be used to reconnect the VHD after a reboot or there is a Mount VHD utility available (https://www.jmedved.com/vhdattach/) if you don’t want to write a batch script.
When it comes to restoring from the VHD – either copy the backup archive out of it onto a blank removable USB drive (using another computer, prior to launching Windows RE) or use the DISKPART tool in Windows RE command prompt to mount the VHD before launching the System Image Recovery wizard.
I have spent almost two weeks now playing around with wbadmin and it is a very poweful tool although severely lacking in both documentation and customizability. For those looking for a Norton Ghost replacement like we were then it should do everything you need but just be prepared to get your hands dirty with diskpart utility and various partition managers because whilst backing up is a doddle, restoring you data back can become a more complex task.
I read the guide and feel I can approach any backup job with wbadmin with more insight, comfortably knowing its boundaries. I needed it and I thank you for the writing.
thank you for summarizing your results.
One question here:
“you can still use another PC to manually ghost the volume/s in the VHD back to another disk”
Could you specify on how this procedure would be done? Righ now, I did not find any information on how to export shadow copies properly from one to another system.
Thanks in advance!
Nice Job. This write-up is thorough and understandable. I appreciate your effort.
Thanks so much for sharing this info with the IT community!
I’m on Win10 64bit 1803 build 17134.228 and wbadmin fails to a local disk but the backup & restore Win7 works just fine. PS Wbadmin fails with server exception error. Looking at the event viewer there’s an app error on wbengine.exe. But when I was doing the backup & restore Win7 I saw the wbengine.exe running just fine!
Very informative guide. Glad you mentioned the issue with recovery to a smaller drive than the original. It does seem crazy.
But have you ever tried backup a win7 client to a mounted vhd (located on network share)?
It doesn’t work.
Yes this tested fine. I’d make sure you are using a VHD and not a VHDX (which isn’t supported by Win 7). Also if your device is on SMB try elevating it to use SMB2 or SMB3 (this would have to be enabled on the server).
On Win7 client I deaktivated smbv1 and couldn’t connect to old smb1 shares.
On Server (Win10, Win2016) there was only Smb2 and 3 active.
I am able to attach the vhd and can save any files but wbadmin fails with “not a supported backup storage location”
thanks and sorry
it is now working
it was a wrong parameter who was ignored in win8,10, server 2016 but not in win7.
How to restore an older version from vhd?
Mount VHD from fileshare on client
wbadmin start backup -allCritical -vssFull -backupTarget:\\%BAKUPSRV%\%WORKSTATION%$ -quiet > %sLog%
UnMount VHD from fileshare on client
My restore scenario looks like:
1. attach the vhd on the BackupServer self: with drive letter X
2 boot a client and use WinRE DVD
but there is only shown the last version of backup (no older versions)
If I want to grab an older backup, the only way I found:
attach the vhd on the BackupServer self
apply an older shadow copy in explorer (but this takes 30min time)
2 boot a client and use WinRE DVD
then I have the older version
Thanks in advance