VSS Crash-Consistent vs. Application-Consistent VSS Backups (post 1 of 2)
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]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image00116_thumb.png "clip_image001[16]"){kind=small} |
![clip_image001[17]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image00117_thumb.png "clip_image001[17]"){kind=small} |
![clip_image001[18]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image00118_thumb.png "clip_image001[18]"){kind=small} |
 |
| Interdependent files guaranteed to be the same version | ![clip_image002[1]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image0021_thumb.png "clip_image002[1]"){kind=small} |
![clip_image001[19]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image00119_thumb.png "clip_image001[19]"){kind=small} |
![clip_image001[20]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image00120_thumb.png "clip_image001[20]"){kind=small} |
![clip_image001[21]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image00121_thumb.png "clip_image001[21]"){kind=small} |
| Protection against transactional data loss (application-aware) | ![clip_image002[2]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image0022_thumb.png "clip_image002[2]"){kind=small} |
![clip_image002[3]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image0023_thumb.png "clip_image002[3]"){kind=small} |
![clip_image001[22]](http://www.altaro.com/blog/wp-content/uploads/2012/04/clip_image00122_thumb.png "clip_image001[22]"){kind=small} |
 |
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.
Backup Hyper-V
We hope you found this article useful, if you’re interested in backing up your Hyper-V environment, check out our free Hyper-V Backup which backs up 2 VMs for free, or try our unlimited Hyper-v backup version for 30 days.
11 Responses
[...] what vendor are available, but for that check out vWorld.nl somewhere this week Check it out at : http://www.altaro.com/blog/vss-crash-consistent-vs-application-consistent-vss-backups-post-1-of-2 [...]
[...] Altaro has a good posting about crash versus application consistent backups here. Share this:EmailPrint This entry was posted in Backup/restore and disaster recovery, Hyper-V. [...]
[...] You can continue the article here: http://www.altaro.com/blog/vss-crash-consistent-vs-application-consistent-vss-backups-post-1-of-2/ [...]
[...] 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 [...]
[...] [...]
[...] [...]
[...] couple of days ago I mentioned this article about VSS Backups. Here you can find the second part. I especially like the part what [...]
[...] Crash-Consistent vs. Application-Consistent VSS Backups Teil 1 und Teil 2 auf Altaro [...]
I was looking up info on “crash consistent state” and found this. It’s a nice and simple, well written explanation.
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?
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.