michelangelus - Fotolia
Storage 101: Crash-consistent vs application-consistent snapshots
We look at crash-consistent and application-consistent snapshots and backup, how they are defined, the pros and cons of each and the benefits and limits of Windows VSS
When it comes to snapshots and backups, it is important to understand and specify whether to take application-consistent or crash-consistent copies.
Why does it matter? Because either crash-consistent or application-consistent copies might be just fine for your workloads – or they may not. There are important differences.
A crash-consistent copy is analogous to the state of data at the point at which hardware crashed or the power went down.
Most data will be safely written to disk, but some will be in transit, residing in memory and waiting to be committed.
Data from crash-consistent copies can be rebuilt – but not always – but these copies are quicker and less draining in terms of time and overhead. That may be fine for some workloads, such as file and print, but will not be acceptable for anything involving databases.
Application-consistent copies are made after making sure that current application operations are temporarily ceased (quiesced/stunned) and any data in memory is flushed to disk.
Obviously, application-consistent snapshots and backups are much more reliable and don’t require any nail-biting rebuild processes. So, they are suitable for even the most sensitive applications and databases. But they come at the price of an interruption to application processing.
You may get the option to choose crash-consistent backups in your backup or snapshot environment. They are more than likely to be the only option with array-based snapshots, but they can also be chosen in backup software and hypervisor data protection features. And all that is fine if you only need to be certain of retaining what has been written to disk.
Restore crash-consistent
Crash-consistent copies of the state of data at a point in time can be rebuilt. That may involve reintegrating log files via a recover group (in Exchange, for example) or replaying log files into a database.
Some applications – Active Directory, for example – automate that, but you need to check for the applications in your stack to determine the risk profile if choosing crash-consistent copies.
Windows VSS
If you need application-consistent copies, Windows VSS (Volume Shadow Copy Services) is the mechanism, in Windows environments including VMware and Hyper-V virtualisation.
Using VSS, applications – which are provided with a VSS writer – deal with pending I/O and ensure that data in memory is flushed to disk. After the snapshot is taken, services are resumed as normal.
VSS was introduced in Windows Server 2003 and operates at block level. The core component is the Volume Shadow Copy Service, which initiates the snapshot creation process. Volume Shadow Copy Providers deal with all the data transfer processes.
Crucial to the entire process are VSS Writers. These ensure that all applications involved in transactions are consistent with each other and that the entire stack is backup-ready. VSS Writers have 60 seconds to carry this out before the VSS Providers start data transfer and have 10 seconds to carry out the snapshot.
You can see from this that the whole process can be time-consuming, measured in seconds rather than fractions of seconds. Also, timeout errors are possible in VSS.
Read more on snapshots
- Snapshots 101: Array vs backup software. We run the rule over snapshots in storage arrays and backup software and find a range of capabilities that go from mere support to fully snapshot-centric approaches.
- Storage 101: Snapshots vs backup. We go over the basics of snapshots. They are a quick and accessible way of protecting data, but they are not a substitute for backup. So how do you combine the two?
