Snapshotting

Taking a snapshot of a running database is like photographing a moving train. Data is constantly being written, and you need a frozen, consistent view without stopping the writes.

Redis uses fork() and copy-on-write to create BGSAVE snapshots. PostgreSQL uses MVCC so every transaction already reads from a consistent snapshot. ZFS marks the current block tree as immutable and writes changes to new locations. AWS EBS copies metadata pointers and lazily copies blocks on first read. Each approach makes different trade-offs between memory overhead, I/O impact, and how long the snapshot takes to become usable.

Snapshotting is the foundation of backups, point-in-time recovery, read replicas, analytics queries, and database branching (Neon, PlanetScale). If you do not understand how snapshots work at the storage level, you cannot reason about recovery time, backup costs, or replication lag.

1. Fork + Copy-on-Write (Redis BGSAVE)

Redis calls fork(). The child process inherits the parent's entire address space through shared memory pages. The parent keeps serving reads and writes. When the parent modifies a page, the OS kernel copies just that one 4 KB page before the write lands, so the child still sees the original data. The child iterates every key and writes the RDB file to disk.

Cost: the fork() system call itself takes 10-25ms per GB of RSS on Linux because the kernel copies the page table entries (not the pages themselves). On a 64 GB Redis instance, that is a 640ms pause. During the snapshot, memory can temporarily double if every page gets modified.

2. MVCC Snapshots (PostgreSQL)

Every PostgreSQL transaction gets an xid (transaction ID) at start time. When the transaction reads a row, it only sees row versions created by transactions with a lower xid that had already committed. No data is ever copied. The "snapshot" is just the xid number itself plus a list of in-flight transactions to exclude.

Cost: old row versions must stick around until no active snapshot needs them. VACUUM reclaims dead rows, but a long-running query (like a 3-hour analytics report) blocks vacuum from cleaning anything written after it started. This is the "MVCC bloat" problem that bites every Postgres team eventually.

3. Filesystem Snapshots (ZFS, Btrfs)

ZFS uses a Merkle-like tree of block pointers. A snapshot pins the current root node. All future writes go to new blocks, the old blocks stay referenced by the snapshot's root. Creating a snapshot is an atomic metadata operation that takes microseconds regardless of dataset size.

Cost: disk usage grows by the size of the diff between the live dataset and the snapshot. If you keep 30 daily snapshots and your dataset changes 5% per day, you need roughly 2.5x the base storage. ZFS tracks this as the "used by snapshots" metric.

4. Cloud Block Snapshots (EBS, Persistent Disk)

AWS EBS snapshots copy block-level metadata to S3. The first snapshot copies every allocated block. Subsequent snapshots are incremental, only modified blocks since the last snapshot get copied. The snapshot is immediately usable because EBS lazily fetches uncopied blocks from S3 on first read.

Cost: S3 storage for the snapshot data, plus potential first-read latency of 5-50ms per block while EBS fetches from S3 in the background. AWS recommends pre-warming volumes restored from snapshots if you need consistent read latency from the start.