It’s no secret that data backup is a crucial practice for any organization. However, it’s important to ensure your backups occur in a format that makes it as fast to restore as possible. Ideally, for database applications, your data protection solution will capture complete cloud workloads with application-consistent or crash-consistent backups. But what, exactly, is the difference between the two terms?
Crash-Consistent Backup
Crash-consistent copies are taken at the storage layer without involving the application layer. The term refers to the data state following an abrupt application termination, as in a sudden loss of power or a server crash. Normally, applications may have data in cache or in memory that is not written to disk. Relative to the disk image at a given point in time, that in-memory data is lost.
Depending on the application, recovery using such a data copy may be:
- Successful with no transaction data loss
- Partial (with some data loss)
- Impossible (complete data loss)
- Possible through an application-specific recovery process (e.g. using transaction logs) which takes more time
Application-Consistent Backup
An application-consistent copy, on the other hand, is one where the application has been notified and allowed to flush its memory before the copy was taken. Recovery from a healthy application-consistent point in time is always successful with no data loss and is usually the fastest. When designing a recovery scheme, organizations need to evaluate the risk of not being able to recover from a point-in-time copy, and having to revert to older copies. One way to eliminate that risk is to test every copy for recoverability and the other is to use application-consistent copies. Testing for recoverability often is still a healthy practice.
The table below (inspired by one created by Nakivo) illustrates the differences between application-consistent and crash-consistent backups:
| Operation | Crash-Consistent | Application-Consistent |
| Captures point-in-time backup of VMs | ✔ Yes | ✔ Yes |
| Block-level backup | ✔ Yes | ✔ Yes |
| Application consistency | ❌ No | ✔ Yes |
| Aware of in-memory and pending I/O | ❌ No | ✔ Yes |
| Requires no special steps for application data restore | ❌ No | ✔ Yes |
Why It Matters
As an IT administrator, it is your duty to oversee and maintain all aspects of a company’s data infrastructure, and data backup is a crucial component of that. While data protection operations are often treated as “set it and forget it,” it’s vital that an organization continues to evolve recovery processes until it is confident that RTO will be met or exceeded in a data loss scenario. Data must be backed up in a format that, in the unfortunate event that there is a sudden power shutdown, for example, you are able to restore workloads to their previous state with no struggle or manual reconstruction.
Capture application-consistent and crash-consistent backups of your cloud environment with the only native data protection solution for OpenStack.
By default, TrilioVault copies are crash consistent. Alternatively, customers can configure any VM for application-consistent copies by setting up “freeze” and “thaw” hooks for TrilioVault. Once set up, the application will be quiesced using a very short freeze/thaw cycle that lasts only as long as it takes the Cinder storage to create a temporary snap using the QEMU engine. Trilio provides certified hook scripts for a growing list of applications, including Oracle, MySQL, Microsoft SQL, PostgreSQL, Sybase, MariaDB, and SharePoint.
Download the TrilioVault Solution Overview to learn more about its features and functionality for OpenStack cloud recovery.
