There are three backup states in the VDP backup state: consistency level is not applicable, application-consistent backup (Application-Consistent Backup), crash-consistent backup (Crash-consistent backup)
1 , The consistency level is not applicable, which means that the object of backup is not a Windows system;
2, Application-Consistent Backup, which means that the data in the memory and IO stack is backed up;
< p>3. Crash-consistent backup (Crash-consistent backup), which means that only the hard disk status is successfully backed up;
2. Specific details:
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 W indows 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 hav e 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.
Application-Consistent
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 consi stency 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 proc ess.
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 writerscommand. N otice 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:
| Operation | Crash-consistent | Application-consistent |
| Consistent point in time backup of files | Yes | Yes |
| Utilizes Volume Shadow Copy for block-level backup | Yes | Yes |
| Application consistency | No | Yes |
| Aware of in memory and pending I/O< /td> | No | Yes |
| Utilizes VSS writers | No | Yes |
| Requires no special steps for application data restore | No | Yes |