Crash-Consistent vs Application-Consistent EBS Snapshots?

This article explains the differences between crash-consistent Amazon Elastic Block Store snapshots and application-consistent multi-volume snapshots on Amazon EC2. It covers how data in memory and disk caches is handled during the backup process, the mechanisms used to coordinate snapshots across multiple volumes, and the recovery implications for stateful applications and databases running on AWS.

What is a Crash-Consistent EBS Snapshot?

A crash-consistent snapshot captures the state of an Amazon EBS volume at the exact moment the snapshot is initiated, including only the data that has already been written and flushed to the underlying storage disk. It does not capture any data currently residing in the operating system memory, file system buffers, or application caches that has not yet been committed to disk.

The term crash-consistent comes from the fact that restoring from this type of snapshot is equivalent to rebooting a physical server after an unexpected power outage or hard reset. When a new EBS volume is created from a crash-consistent snapshot and attached to an EC2 instance, the operating system and database engines treat the state as an unclean shutdown. File systems like ext4 or XFS will replay their journals, and relational databases will run crash recovery routines by rolling back uncommitted transactions and rolling forward committed ones from transaction logs.

For single-volume workloads or stateless applications, standard crash-consistent snapshots are often sufficient. Furthermore, AWS supports multi-volume crash-consistent snapshots through the CreateSnapshots API, which coordinates point-in-time backups across all EBS volumes attached to an EC2 instance simultaneously without requiring you to stop the instance or manually freeze I/O across disks.

What is an Application-Consistent Multi-Volume Snapshot?

An application-consistent multi-volume snapshot captures not only the data on the disks at the same point in time, but also ensures that applications and the operating system have completed all pending I/O operations and flushed their in-memory caches to disk before the snapshot occurs.

When an application-consistent backup is triggered across an EC2 instance with multiple attached EBS volumes—such as a database server storing data files on one volume and transaction logs on another—the backup process interacts directly with the guest operating system and running applications. The process follows a specific sequence:

1. Applications are notified that a backup is about to begin and are instructed to quiesce, pausing new write transactions and flushing internal memory buffers.
2. The operating system file system flushes its dirty pages and buffers to the EBS volumes and freezes write operations.
3. AWS initiates coordinated, simultaneous snapshots across all targeted EBS volumes attached to the instance.
4. Once the point-in-time checkpoint is established by EBS, the file system and applications are immediately thawed to resume normal read and write operations while the snapshot data transfers to Amazon S3 in the background.

When you restore an instance or database from an application-consistent snapshot, the software starts cleanly without needing to perform complex log replays or consistency checks, as the storage state reflects a clean, coordinated transaction boundary.

How They Are Implemented on Amazon EC2

Windows Instances with VSS

On Windows Server instances running on Amazon EC2, application-consistent snapshots rely on the Microsoft Volume Shadow Copy Service (VSS). By installing the AWS Systems Manager Agent (SSM Agent) and the AWS VSS components on the EC2 instance, you can run the AWSEC2-CreateVssSnapshot Systems Manager document or use AWS Backup with VSS enabled. VSS communicates with VSS-aware applications like Microsoft SQL Server or Active Directory to freeze transactions, flush caches, and coordinate the multi-volume EBS snapshot via the EC2 API.

Linux Instances with Custom Scripts or AWS Backup

Linux does not have a single built-in equivalent to Windows VSS that covers both the OS and all third-party databases uniformly. To achieve application consistency on Linux EC2 instances across multiple volumes, administrators typically use pre-freeze and post-thaw scripts executed via AWS Systems Manager Run Command, AWS Data Lifecycle Manager (DLM), or AWS Backup.

In a typical Linux workflow:

1. A pre-script connects to the database (such as MySQL, PostgreSQL, or Oracle) and places it into backup mode or acquires a global read lock.
2. The script runs the sync command and uses fsfreeze -f on mounted file systems to halt new I/O operations.
3. The CreateSnapshots API is called to capture all attached volumes at that exact instant.
4. A post-script runs fsfreeze -u to unfreeze the file systems and releases the database lock.

Key Differences Between the Two Approaches

Mathematical View of Recovery Time Objective (RTO)

The choice between crash-consistent and application-consistent snapshots directly affects the Recovery Time Objective (\(\text{RTO}\)) when restoring large, high-throughput workloads.

For an application-consistent snapshot, the total recovery time \(T_{\text{app}}\) is primarily a function of volume provisioning and instance boot time:

\[T_{\text{app}} = T_{\text{provision}} + T_{\text{boot}} + T_{\text{service\_start}}\]

For a crash-consistent snapshot, the recovery time \(T_{\text{crash}}\) includes an additional variable for transaction log replay and file system verification, which scales with the volume of uncommitted or uncheckpointed transactions \(N_{\text{tx}}\) at the moment of the snapshot and the disk read/write throughput \(R_{\text{io}}\):

\[T_{\text{crash}} = T_{\text{provision}} + T_{\text{boot}} + \frac{N_{\text{tx}}}{R_{\text{io}}} + T_{\text{service\_start}}\]

While EBS Fast Snapshot Restore (FSR) can minimize \(T_{\text{provision}}\) and boost \(R_{\text{io}}\), eliminating the crash recovery phase entirely requires application-consistent snapshots.

When to Use Each Snapshot Type

When to Use Crash-Consistent Multi-Volume Snapshots

• Stateless web and application tiers: Servers that do not store persistent transactional data locally.
• Modern ACID-compliant databases with low recovery overhead: Many modern relational databases (such as PostgreSQL, MySQL with InnoDB, and Oracle) are designed to recover reliably from crash-consistent storage snapshots, provided that data volumes and write-ahead log (WAL) volumes are snapped at the exact same moment using the multi-volume CreateSnapshots API.
• Environments without guest OS access: Compliance or security boundaries where installing agents or running administrative scripts inside the guest operating system is prohibited.

When to Use Application-Consistent Multi-Volume Snapshots

• Microsoft Windows workloads: Enterprise applications running on Windows Server (such as SQL Server, Exchange, or Active Directory) that natively expect VSS-coordinated backups for supported recovery scenarios.
• Databases spanning multiple volumes without atomic cross-volume recovery: Legacy applications or custom storage engines that cannot reconcile state if in-flight memory operations are lost across striped (RAID 0) or separated data/log volumes.
• Strict RTO requirements: Production systems where waiting for lengthy database log replay or file system checks during a disaster recovery event is unacceptable.