Crash-Consistent vs. Application-Consistent Backup
Brandon Lee, posted on April 3, 2017
It goes without saying that backup data consistency is of utmost importance. In other words, is the backed-up data usable? Is it in a state that can provide a reliable restore point? Generally speaking, there are a couple of different options when it comes to creating usable backups that you may hear about today – crash-consistent and application-consistent. What is each of these types of backups? When do you need to have an application-consistent backup instead of a crash-consistent?
Crash-consistent backups allow for consistent backups of files on disk. A crash-consistent backup takes a snapshot of all the files at the exact same time. This means that any files that rely on each other are at the same point in time, and thus they are consistent. The very term “crash-consistent” refers to the fact that capturing the backup is like capturing a restore point at the instant leading up to the server crashing or being powered off or reset.
You may wonder how backup software is able to take a snapshot of an entire set of data at the same point in time. This is accomplished by leveraging Microsoft’s Volume Shadow Copy service which is a part of most modern-day Windows OS’s. Volume Shadow Copy or VSS quickly freezes I/O operations on a volume which are then queued and records the blocks currently in use by the volume. This is done in just a few seconds of time. So, it knows what blocks were in use during that “point in time” snapshot. The backup software can then, at its leisure, copy all the physical data from the disk even after the blocks have changed since it knows which blocks were in use for that snapshot.
The crash-consistent backup is vastly superior to the old inconsistent backup which basically amounts to a copy of the files on the disk. However, if files change during the duration of the backup, files that depend on each other would be left in an inconsistent state since a file that another file depends on may have changed during the backup window.
Even with the advantages of the crash-consistent backup over the inconsistent backup, the crash-consistent backup has a pretty significant flaw when it comes to making sure application data that may be in memory or pending I/O operations is consistent. This especially is true of database applications such as Microsoft SQL Server or Microsoft Exchange. How do we make sure our application data is consistent? We use application-consistent backups.
Unlike crash-consistent backups, application-consistent backups have the ability to see application information both in memory as well as pending I/O operations. Application-consistent backups are able to do this by using VSS writers. We already mentioned how Volume Shadow Copy works on a volume level. VSS writers are application-specific components for Microsoft’s Volume Shadow Copy Service, which ensure the consistency of application data when a shadow copy is created.
Microsoft VSS writers or third party writers allow VSS to have control over specific application data, not just files on disk, and allow those applications to be backed up with transactional consistency. For instance, Microsoft SQL Server may have data living in memory as well as I/O operations that are pending. A normal crash-consistent backup of files on disk even though consistent at a file level, would miss the data residing in those locations. However, with application-consistent backups, the VSS writer for Microsoft SQL server allows the information in memory to be purged and the pending I/O operations to be flushed to disk in the correct transactional order so the backup of the disk with the application data contains consistent transactional information. Application-consistent backups are sometimes referred to as “application aware” since they are aware of these transactional requirements as part of the backup process.
Another critical difference with application-consistent backups as opposed to crash-consistent backups is the amount of work that you need to do once a restore has taken place. With crash-consistent backups, since the application data may not be consistent, you must follow the procedure for bringing applications up to a consistent state. This process varies between products such as Microsoft Exchange or Microsoft SQL Server. However, with application-consistent backups, the application data is already consistent, since VSS writers made sure all the transactions in memory and pending I/O were committed to disk before the snapshot was taken. In a disaster recovery scenario of application data, it is hugely beneficial to have application-aware backups as opposed to crash-consistent backups of application servers, especially database servers.
You can see the state of the VSS writers in Windows by using the vssadmin list writers command. Notice below, we can see the special VSS SqlServerWriter as well as for Exchange Microsoft Exchange Writer. The vssadmin is a powerful troubleshooting tool for VSS writers and many options are available from the command line.
The Microsoft Exchange Writer shown below.
Commands supported by the vssadmin utility.
Crash-Consistent vs Application-Consistent Backup
Here’s a quick overview of the differences between crash-consistent and application-consistent backups:
|Consistent point in time backup of files||Yes||Yes|
|Utilizes Volume Shadow Copy for block-level backup||Yes||Yes|
|Aware of in memory and pending I/O||No||Yes|
|Utilizes VSS writers||No||Yes|
|Requires no special steps for application data restore||No||Yes|
Failing to think about the difference in backup types such as crash-consistent and application-consistent can leave you with unexpected backup results and potentially even corrupted data. There are definite differences in how crash-consistent and application-consistent backups handle application data such as Microsoft SQL Server or Microsoft Exchange. Crash-consistent backups are unaware of the in-memory data and pending I/O operations by these types of applications. Application-aware backups are aware of these types of transient data and are equipped to handle them by leveraging VSS writers as components of the VSS service in Windows to correctly quiesce the application by flushing memory and pending I/O to disk, allowing it to be backed up properly with transactional consistency.