RDB Snapshotting

RDB persistence saves Redis' in-memory dataset as a point-in-time snapshot.

The idea is:

memory now -> compact snapshot file -> memory later

RDB is not a command history. It does not record every step that produced the dataset. It records the dataset itself.

Snapshotting Fits Redis' Shape

Redis keeps its primary state in memory, so a natural persistence strategy is to serialize that state. An RDB file contains enough information to reconstruct the keyspace: databases, keys, value types, payloads, expiration timestamps, and supporting metadata.

On startup, Redis can read the file and rebuild memory. This is often faster than replaying a very long command log.

The tradeoff is data loss between snapshots. If the last snapshot was five minutes ago and the process crashes now, writes from those five minutes may be gone unless another persistence mode also protected them.

Background Saves And Copy-On-Write

A blocking snapshot would be simple: stop serving clients, write the dataset, then resume. But that would create obvious latency and availability problems.

Redis commonly uses a background save model. The process forks. The child writes the snapshot while the parent continues serving clients.

parent has live dataset
fork creates child with same memory view
child writes snapshot
parent continues processing writes

Operating-system copy-on-write makes this efficient. Parent and child initially share memory pages. If the parent modifies a page while the child is saving, the operating system copies that page so the child still sees the original snapshot view.

This gives Redis a stable point-in-time image without freezing the server for the full duration of the disk write.

Atomic Replacement Matters

A persistence file should not be left half-written as the official snapshot. The safe pattern is:

write temporary file
flush as required
rename temporary file over old snapshot

On most filesystems, rename is atomic. That means recovery sees either the old complete snapshot or the new complete snapshot, not a random partial file.

This kind of file discipline is easy to overlook and painful to get wrong.

Expiration In Snapshots

Expiration timestamps must be stored as absolute times. If a key expires while the server is offline, loading the snapshot should not resurrect it.

During recovery:

if key expiration <= now:
  skip key
else:
  restore key and deadline

This keeps snapshotting compatible with Redis' promise that expired keys behave as missing.

What RDB Is Good At

RDB files are compact, portable, and efficient to load. They are excellent for backups, disaster recovery baselines, replica synchronization, and restarts where some recent data loss is acceptable.

They are less ideal when every acknowledged write must survive a crash. That is where AOF enters the picture.

RDB gives Redis a durable image of memory. It is the persistence mode that most directly mirrors Redis' identity as an in-memory data structure server.