Understanding Storage Snapshots: Use Cases and Implementation Principles

The Storage Networking Industry Association (SNIA) defines a snapshot as a fully usable copy of a specific data set that reflects the data at a particular point in time when the copy starts. A snapshot is a completely usable copy, but not a complete duplicate of the source data.

Use Cases

Scenario 1: Snapshots serve as a data protection measure, often described as a "regret pill". After creating a snapshot at time t1, if the source data is damaged at time t2 (due to accidental deletion, system errors, etc.), the snapshot can be rolled back to restore the source to its state at t1, minimizing data loss between t1 and t2. This is commonly used in banks, public security registries, research institutions, and during OS or software upgrades where data is snapshotted before high‑risk operations.

Scenario 2: Because a snapshot is a fully usable copy, it can be presented to upper‑level applications as source data. After creating a snapshot, the snapshot volume can be mapped to other workloads for data mining, development testing, or content moderation (e.g., providing a segment of video to law‑enforcement for analysis). Reads from the snapshot do not affect the source volume.

Implementation Principles

Snapshot implementations are vendor‑specific but generally fall into two categories: Copy‑On‑Write (COW) and Redirect‑On‑Write (ROW).

Copy‑On‑Write (COW)

When a snapshot is created, any subsequent write to the source volume triggers the system to first copy the original data block (Y) to the snapshot volume, then write the new data (X) to the source. This results in a mapping table that records the logical addresses of changed blocks on both the source and snapshot volumes. Reads from the snapshot are served directly from the snapshot volume; reads from the source use the mapping table only when needed.

Rollback (rollback) involves locking the source volume, then copying the relevant data from the snapshot back to the source using the mapping table. Deleting a COW snapshot simply destroys the snapshot volume and its mapping table, leaving the source untouched.

Redirect‑On‑Write (ROW)

After a snapshot is created, write requests to the source are redirected to pre‑allocated space in the snapshot volume. The source volume receives only one write operation, while the snapshot stores the new data. Reads from the source before the snapshot point come from the source; reads after the snapshot point are redirected to the snapshot volume.

Rollback for ROW snapshots merely removes the read redirection, as the source volume still holds the original pre‑snapshot data. Deleting a ROW snapshot requires copying data from the snapshot back to the source for each affected block, which can be time‑consuming when multiple snapshots exist.

Comparison

COW incurs a copy operation on every write, which can degrade write performance under heavy workloads, but reads from the source are unaffected and snapshot deletion is simple. ROW adds only a redirection step on writes, so write performance is almost unchanged, but reads must consult the mapping table, potentially impacting read performance, especially when many snapshots exist. Deleting ROW snapshots may involve large data copy‑back operations.

Conclusion

Snapshots are widely used across various industries for data protection, testing, and analysis. Both COW and ROW have their advantages and trade‑offs, and vendors often implement hybrid or proprietary variations. The optimal snapshot technology depends on the specific business scenario and workload characteristics.