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.

	Inconsistent	Crash-Consistent	Application-Consistent	Image
Live backup
Interdependent files guaranteed to be the same version
Protection against transactional data loss (application-aware)

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.