VSS Crash-Consistent vs Application-Consistent VSS Backups (post 1 of 2) VSS Crash-Consistent vs Application-Consistent VSS Backups (post 1 of 2)

01 May by Eric Siron     10     Hyper-V Articles

When designing any IT solution, many administrators often consider “Backup” to be little more than another box on a long list of items to check off. They verify that the software and hardware they’re using will handle the load, configure it to back up on a reasonable schedule, and forget about it. Some will take the extra step of restoring some data to an alternate location as a test. Hardly any go through the full exercise of simulating an actual catastrophe. Most of the time, this practice is completely harmless. Unfortunately, if disaster does strike, there are often more questions than answers. Planning ahead is critical, and that involves knowing what sort of backup you need and if your backup application can provide it.

NOTE: This is the first blog post in a 2-series post.  You can read the second post in this series here.

Consistency Definitions

To determine what sort of backups you need, you must first understand the terminology in use. The backup types applicable to this discussion are inconsistent, crash consistent, and application consistent.

Live backup clip_image001[16] clip_image001[17] clip_image001[18] clip_image002
Interdependent files guaranteed to be the same version clip_image002[1] clip_image001[19] clip_image001[20] clip_image001[21]
Protection against transactional data loss (application-aware) clip_image002[2] clip_image002[3] clip_image001[22] clip_image003


Inconsistent Backup

An inconsistent backup is the oldest type. Backup software starts at the beginning of the file structure and copies out data until it gets to the end. If any file changed after it was backed up but before the job completed, then the result is an inconsistent backup. It means, simply, that the files contained in the backup job are mismatched. In some instances, this isn’t a problem. Inconsistent backups are often acceptable for things like simple file servers and data locations that rarely change. These can be dangerous to the point of uselessness for database systems. Databases are typically composed of multiple interdependent files, so they must all be synchronized in order for a backup to be considered successful. Also, an inconsistent backup method only grabs what is on disk at the time; if a database has a pending operation in memory, it is completely lost.

A software program can take an inconsistent backup at any time without any real interaction with anything except the operating system. It may struggle if it isn’t running with sufficient permissions to grab a file or encounters a file that’s locked for reading, but otherwise it’s just another process running on the system.


Crash-Consistent Backup

The most important distinction between a crash-consistent backup and an inconsistent backup is that all data within a crash-consistent backup set is captured at exactly the same time. This is the most common method in use by commercial backup software today and is almost always sufficient for applications that do not rely on a database. One thing it shares with the inconsistent method is that it does not capture the contents of memory or any pending I/O operations. If a crash-consistent backup is restored in its entirety, then the data will be in the same state it would have been if the system had crashed at the exact moment that the backup was taken. This is reason it is considered “crash-consistent”. If a database system is restored to a crash consistent state, then it is necessary to follow any procedures that would be followed if the system had actually crashed at that point. Many applications, like Active Directory, have an automated recovery mechanism and will attempt to handle the problem without administrator intervention. If these automated systems aren’t successful, ensure that you know what the application vendor’s process is for crash recovery and be prepared to follow those steps. For Microsoft Exchange, you may need to know how to set up a recovery group and use its utilities to integrate log files. For Microsoft SQL, you may need to know how to replay logs into a database file.

A crash-consistent backup requires more effort on the part of backup software than inconsistent backups. Techniques vary, but in the Windows world, the Volume Shadow Copy Service (VSS) was designed as a component of the operating system specifically to assist backup software. A backup application coordinates its efforts with VSS. When triggered, VSS pauses I/O on the volume and takes a block-level snapshot of it, and then the backup software pulls its backup from that snapshot at its leisure.


Application-Consistent Backup

An application-consistent backup is the most involved but also the most desirable. Again, techniques vary, but the general process for Windows applications is for the application manufacturer to provide a VSS writer. When the VSS service is triggered, it will notify these writers that a backup is occurring. It’s then up to the VSS writer how to handle it. In general terms, a database application will respond to its VSS writer being triggered by flushing all of its memory and I/O operations so that the database is completely consistent. In doing so, there is nothing in memory and no pending I/O to be lost. A proper VSS writer should effectively place all the data for an application in the same state it would be if the application were properly closed. When the VSS snapshot is complete, it signals the VSS writers, which are then to resume normal operation of the attendant application while the backup software safely copies out of the snapshot.

If an application does not provide or properly register a VSS provider but its data resides on a volume with VSS enabled, the data is backed up in a crash-consistent state.

Image-Level Backup

An image-level backup is quite different from the other types. All previously mentioned methods operate in some fashion within a machine that is actively running. Since no backup software can properly capture the active state of memory and I/O, the most reliable way to completely replicate all aspects of a machine is to shut it down. Then, the storage medium can be copied out block-by-block and there is absolutely no concern of anything being lost. Virtualization does add another option; Hyper-V manifests this as “Saved State”. This is similar to hibernation on a physical machine, except that the virtual machine itself is unaware of the state change. I/O in the virtual machine is paused and the contents of memory are copied to a file on disk. As long as every single file related to the virtual machine is copied, a restore of that backup will result in a virtual machine that is in exactly the same state it was when it was saved.

NOTE: This is the first blog post in a 2-series post.  You can read the second post in this series here.

Have any questions?

Leave a comment below!


Backing up Hyper-V

If you’d like to make backing up your Hyper-V VMs easy, fast and reliable, check out Altaro Hyper-V Backup v4. It’s free for up to 2 VMs and supports Hyper-V Server 2012 R2! Need more? Download a 30-day trial of our Unlimited Edition here: http://www.altaro.com/hyper-v-backup/.


Receive all our free Hyper-V guides, checklists and ebooks first via email!

Thank you, your sign-up request was successful! Please check your e-mail inbox.
Given email address is already subscribed, thank you!
Please provide a valid email address.
Oops. Something went wrong. Please try again later.
(Don’t worry, we hate spam too!)

Eric Siron

I have worked in the information technology field since 1998. I have designed, deployed, and maintained server, desktop, network, and storage systems. I provided all levels of support for businesses ranging from single-user through enterprises with thousands of seats. Along the way, I have achieved a number of Microsoft certifications and was a Microsoft Certified Trainer for four years. In 2010, I deployed a Hyper-V Server 2008 R2 system and began writing about my experiences. Since then, I have been writing regular blogs and contributing what I can to the Hyper-V community through forum participation and free scripts.

10 Responses to “VSS Crash-Consistent vs Application-Consistent VSS Backups (post 1 of 2)”

  1. [...] than a company that does backup for a living.  Queue Altaro and the first on their series on VSS Crash-Consistent vs. Application-Consistent VSS Backups. Unfortunately, if disaster does strike, there are often more questions than answers. Planning [...]

  2. SysAdmin-E.com

    I was looking up info on “crash consistent state” and found this. It’s a nice and simple, well written explanation.

  3. Shengli

    As above visitor, I found this also by searching ‘crash-consistent copy’. I have a question here for image level backup. It is said somewhere that image level backup is same as crash-consistent backup. But in your article, image level backup keeps best data integrity. No offense, is this defined yourself? Or have other references?

    • Eric Siron
      Eric Siron

      A crash-consistent backup can only happen if the machine is running when the backup is taken. The “crash” part of crash-consistent means that memory contents and the operations of any current or queued processor threads are lost, just as in an actual crash. The “consistent” part means that all the drive contents are precisely up-to-date as of the point at which the “crash” occurred, just as they would be in an actual crash.

      In a true image, the machine is offline when the image is captured. There are no memory contents or running threads to be lost. Think of utilities like Clonezilla.

      I don’t know if there as an industry defined term called “image-level backup”. I derived the definition from the industry-defined term of “image” as it is used in imaging applications such as the aforementioned Clonezilla.

  4. ashwin

    Hi Eric,

    Great explanation. I don’t think you can get any easier explanation than this. Brilliant!!

    I just have a thought here, you mentioned -”the data will be in the same state it would have been if the system had crashed at the ‘exact moment’ that the backup was taken”. I don’t think it’s necessary that system crashed at the exact moment that the back was taken”, b’cos even if the system is running and you capture a backup [with IO paused as in VSS] it will only backup the data that is made it to the disk. Any pending IOs or memory contents will be lost.

    I just thought the word – crash consistent meant, state of the machine after the crash.

    Do you agree?

    Thanks you Eric.


    • Eric Siron
      Eric Siron

      We might be splitting hairs over wording, but I believe my phrasing is accurate. If the system crashes, in-flight I/O never lands on disk. In a crash-consistent backup, in-flight I/O doesn’t get into the backup. The actual backup contains data that would look like the disk would have if its host system crashed at that moment in time. Of course, when you spin up such a backup, it then looks like the system would have after a crash.

  5. ashwin

    Thank you Eric. I agree with you completely. I must say your knowledge sharing is of very high quality and yet simple.

    Keep up the great work.


Leave a comment