Snapshots and recovery | Storage: capacity, performance, and recovery

Concept and mechanism

An EBS snapshot captures data written to the volume at the relevant point; it does not automatically include changes still only in application or operating-system cache. Define a service-appropriate consistency procedure with the application owner. Snapshot completion alone does not certify business consistency. Under the EBS incremental model, deleting an earlier snapshot preserves blocks required by the remaining snapshots. This behavior belongs to the documented service and should not be generalized to every backup format. Similarly, a snapshot existing does not establish that keys, dependencies, and recovery steps will be available when needed.

Guided application

In a fictional exercise, a recoverable point at 02:00 leaves a forty-minute window before failure at 02:40, with no later logs or copies. This exceeds a fifteen-minute RPO even if restore is quick. RPO concerns tolerance relative to the data point; RTO concerns time to recover service. After restoring, confirm startup, integrity, and agreed functional criteria. A volume created from a snapshot may still experience initialization latency on first reads. Report volume availability, application validation, and service acceptance separately. Do not announce full recovery solely because the technical job completed without error.

IN PRACTICE

02:00 to 02:40 is a forty-minute window, not fifteen, regardless of restore speed.

Common pitfalls

Cache as snapshot; universal chain; green restore as acceptance; RTO as RPO; available as warmed.

Related topics: Interfaces and dependencies · Capacity and growth · Performance and measurement

Take this idea with you

Demonstrate that the right point can recover the application within agreed objectives.

Create account

Reference: EBS snapshot consistency and cached data · DR Storage 2026-09; selected Linux and AWS storage behavior