Crash-Consistent vs. Application-Consistent Backup Comparison

The reliability of backups, and data protection strategies in general, depends on whether the backup data is valid and usable immediately when needed. Restore failures in 2021 have been reported at 34% of jobs by some organizations.

The issue of swift and successful restores is of particular concern for live database workloads like Microsoft SQL Server and Exchange Server. These are usually critical and cannot be stopped for the duration of the virtual or physical machine backup, which depending on the size of the machine can take hours sometimes. To address this issue, modern solutions offer several types of backups including crash-consistent and application-consistent backups. Read this post to discover the main differences between these backup types and understand how each affects backup and recovery of application data.

Before we start
NAKIVO Backup & Replication delivers all the advanced features needed to ensure that backups are valid, accurate and usable for instant recovery of full machines as well as of live database and application objects. Download the latest NAKIVO datasheet to learn more. 

Crash-Consistent Backup

A crash-consistent backup takes a snapshot of all the data found on a disk at the exact same time, while preserving the write order. This means that files that rely on each other are backed up at the same point in time, and thus they are consistent. The term “crash-consistent” describes the capturing of the data for backup, as it is similar to a restore point being captured at the instant leading up to a server crashing or being powered off.

How do backup software take a snapshot of an entire data set at the same point in time? This is accomplished by leveraging Microsoft’s Volume Shadow Copy Service (VSS), which is part of Windows OS starting with Microsoft Server 2003. The VSS Service facilitates communication between the different components in an environment: backup software, production applications that cannot be shut down (with changes written to them as backups are in process) and storage. For Microsoft VSS to work, all these components should support this functionality.

The “VSS requester”, that is the backup software, requests the creation of a shadow copy. VSS quickly freezes I/O operations on a volume, which are then queued. It then records the blocks currently in use by the volume. The backup software then copies all the data from the disk even after the blocks have changed since it knows which blocks were in use for the snapshot.

Note that the crash-consistent backup is vastly superior to the old inconsistent backup, which basically amounts to a copy of the files on the disk. This meant that if files change during the duration of the backup process, 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 over the inconsistent backup, crash-consistent backups have their limitations. Most importantly, information found in memory or in any pending I/O transactions is disregarded. This is especially critical in the case of database applications such as Microsoft SQL Server and Microsoft Exchange Server. With crash-consistent backups of this type of applications, procedures are required post-recovery of data to bring the backup data into a consistent state, thus leading to longer recovery times and risks of data loss.

Application-Consistent Backup

Application-consistent backups, also known as application-aware backups, can capture application information both in memory and in pending I/O operations. This is possible by using application-specific components for Microsoft’s service known as VSS writers. These writers ensure the consistency of application data when a shadow copy is created. When backup software requests the creation of a shadow copy, 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 residing in memory and in I/O operations that are pending. A regular crash-consistent backup of files on disk, even though consistent at the file level, will 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 data.

App-consistent backup for Linux machines

For Linux-based machines for which VSS services are not available, you can use the Linux pre-script and post-script commands.

  • Pre-freeze scripts can be run just before the VM snapshot is taken to quiesce the I/O operations and flush in-memory information to the disk.
  • Post-thaw scripts then run immediately after the VM snapshot is taken to thaw the I/O operations so that the application can resume regular operations.

Recovery from application-consistent backups

Another critical difference between application-consistent and crash-consistent backups is the amount of work that you need to do when you restore data, especially after the recovery has taken place.

  • With crash-consistent backups, since the application data may not be consistent, you must follow a specific procedure to bring applications up to a consistent state. This process varies between products such as Microsoft Exchange Server or Microsoft SQL Server.
  • With application-consistent backups, the application data is already consistent. In a disaster recovery scenario of application data, it is hugely beneficial to have application-aware backups instead of crash-consistent backups since the recovery process is much faster and more reliable.

VSS Writers Commands

The vssadmin is a powerful troubleshooting tool for VSS writers, and many options are available from the command line. You can see the state of the VSS writers in Windows by using the vssadmin list writers command. The image below shows the special VSS SqlServerWriter as well as for Exchange Microsoft Exchange Writer.

sqlserverwriter name in command line

The Microsoft Exchange Writer is shown below.

microsoft exchange writer name in command line

Below are the commands supported by the vssadmin utility.

supported command by vssadmin utility

Crash-Consistent vs Application-Consistent Backup

Here’s a quick overview of the differences between crash-consistent and application-consistent backups:

Operation Crash-consistent Application-consistent
Consistent point-in-time backup of files Yes Yes
Volume Shadow Copy used for block-level backup Yes Yes
Application consistency No Yes
Aware of memory information and pending I/O transactions No Yes
VSS writers used No Yes
Requires no special steps for application data restore No Yes


There are definite differences in how crash-consistent and application-consistent backups handle data in live applications like Microsoft SQL Server or Microsoft Exchange Server. Crash-consistent backups do not copy in-memory data and pending I/O operations. Application-aware backups are aware of these types of transient data and capture 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.

Modern vSphere backup solutions like NAKIVO Backup & Replication offer multiple backup options for different workloads to help you protect your data and ensure recovery following a disaster. Download the Free Edition to check out all the advanced tools and functionalities.