Why architecture matters here
Snapshots without a plan are storage overhead. Snapshots with a plan are the difference between a resolvable incident and data loss. The architecture matters because you must understand what the snapshot captures (references), what happens on compaction (refcount protects HFiles), and how export works cross-cluster.
Getting this right gives you point-in-time recovery, clone-for-analytics, and DR without heavy machinery.
The architecture: every piece explained
The top strip is the capture. Snapshot cmd names the table + snapshot label. Coordinator orchestrates Region Servers + Master. Metadata capture records the list of current HFiles per region and their metadata — no data copy. Snapshot manifest is a durable listing that survives Region Server restarts.
The middle row is what you do with it. Clone creates a new table from the snapshot; it shares HFiles until diverging writes. Restore reverts the original table to the snapshot state — powerful but destructive. Export snapshot ships the referenced HFiles to another cluster for DR. Cleanup + retention policies remove old snapshots.
The lower rows are the safety mechanics. HFile refcount ensures a compaction cannot delete an HFile referenced by a snapshot. Observability tracks snapshot count and storage overhead from retained HFiles. Ops schedules snapshots, monitors overhead, and runs DR drills.
End-to-end flow
End-to-end: a scheduled job snapshots the users table nightly. Coordinator captures the current HFile list; snapshot is created in seconds. Compactions continue; refcount prevents removing HFiles still referenced. A month later, a bad app update corrupts data. Ops clones the previous night's snapshot into a new table, inspects, and restores the original. Data recovered. Weekly, a snapshot is exported to a DR cluster; DR drills validate restore from the exported snapshot on the remote cluster. Cleanup removes snapshots older than 30 days.