In the world of backup technology, things have come a long way since the early days of backup software simply capturing files on disk. In the early days of backup software, backups would parse through files on the disk(s) in a server and literally run a file copy of the data that was included on the disks. The problem with this type of backup is that data could be left in an inconsistent state. Why inconsistent? Well, if you had interdependent files that were backed up at different points in time, you would be left with one file that had a certain time stamp and another file that had a different time stamp that could be inconsistent with one another especially if they were linked together in some way. Hence, intuitively, this type of backup was called an inconsistent backup.
A simple example of a way to create inconsistent backups would be using utilities such as xcopy or robocopy to copy files from one drive/folder to another. While both of these command line utilities are powerful tools to be used in certain use cases, neither are able to create consistent backups on their own since they work their way through a file structure copying resources as mentioned above. If a file is changed during the process, xcopy or robocopy isn’t aware of those changes. ***Note*** There are ways to utilize utilities such as xcopy or robocopy in conjunction with other volume shadow copy (more on this below) utilities and operations to capture consistent backups like those found here.
So we have talked about backups that are inconsistent or have files that may not be synced correctly even though we have copies of them in our backups. What kind of backups are consistent? Most modern backup solutions have a couple of options when it comes to thinking about creating consistent backups. This includes backups of virtual machines. Many VMware or Hyper-V backup solutions include a couple of options with backing up virtual machines. They support crash-consistent backups and application-consistent backups. Let’s focus on the crash-consistent backup and how it relates to having consistent backups of files on disk.
A crash-consistent backup captures a consistent backup that behaves like a server that is powered off immediately after a successful backup has completed, hence the name “crash-consistent”. How does crash-consistent backup accomplish creating a consistent backup that may include a lot of data? As we stated earlier, the xcopy and robocopy utilities potentially could be used in conjunction with volume shadow copy utilities to produce consistent backups. Volume shadow copy or VSS is the service that is built into most current versions of Windows that allows for quickly pausing I/O operations and recording blocks currently in use by the disk volume. This typically only takes a few seconds. This operation is referred to as a VSS “snapshot”. Since the blocks in the snapshot are now known, backup software can then at its leisure copy data even after the blocks have changed since it knows which blocks have changed when compared to the VSS snapshot.
Volume shadow copies is the technology behind the “shadow copies” setting in the modern versions of Windows that allows for having multiple points in time of files on a volume. If you right-click the volume and select properties, notice the shadow copies tab.
By default, the shadow copies functionality is turned off. However, Windows still uses Volume Shadow Copy as needed or when called upon by backup software or other Windows processes. Notice the service is set to “Manual” by default. It can be started by any operation that calls for VSS.
When VSS is triggered to be utilized, you will see VSS messages in the Windows Application log, such as this Event 7036.
You can also filter your Application log for an event source of VSS.
To show the point of how a crash-consistent restore behaves, we have taken a crash-consistent backup of a VMware VM and then restored that VM to another VMware environment to simulate what would happen if we restore the entire VM in the crash-consistent state. The restore job runs and finishes the restoration process.
After restore, the VM boots.
What we see after the VMware virtual machine boots confirms we have indeed performed a crash-consistent backup and restore. As you can see, Windows displays the Shutdown Event Tracker and indicates it has experienced an unexpected shutdown. This is the behavior that you see when as was mentioned, the crash-consistent backup is like taking a consistent backup and then immediately turning the server off.
Crash-consistent backups are consistent backups that utilize Windows Volume Shadow Copy to perform a consistent snapshot of the blocks used on a volume. The currently used blocks in the snapshot then allow for modern backup solutions to know which blocks have changed since the last backup. As we saw in the example of a VMware VM crash-consistent backup that was restored, the virtual machine boots and behaves as it has recovered from a crash. While crash-consistent backups are way more effective than inconsistent backups, they are lacking when it comes to applications such as SQL Server, Exchange, SharePoint and others. Next, we will take a look at application-aware backups and how they solve the issues experienced with using crash-consistent backups on transactional database systems.