How Redis Persists Data: RDB vs AOF Explained Through a Story

RDB Persistence

Redis decides to implement snapshot persistence (RDB) by periodically traversing all in‑memory data and writing it to a binary file. To save space it defines a custom binary format. Because full snapshots are costly, Redis adds a configurable save directive with conditions such as save 900 1, save 300 10, save 60 10000, which trigger a snapshot when the specified number of write operations occurs within the given seconds. To avoid blocking the main process, Redis forks a child process to perform the snapshot.

When a crash or power loss occurs, Redis can restart by loading the RDB file and quickly restoring its previous state.

MySQL: binlog

MySQL stores every data‑changing operation (INSERT, UPDATE, DELETE, etc.) in binary log files (e.g., mysql-bin.000001). These logs can be used for point‑in‑time recovery, making them a useful reference for persistence strategies.

AOF Persistence

Inspired by MySQL’s binlog, Redis introduces Append‑Only File (AOF) persistence, recording every write command to a log file. To balance performance, Redis buffers commands in an aof_buf and flushes them to disk based on the appendfsync setting, which can be always, everysec, or no.

AOF Rewrite

Because the AOF file can grow large, Redis implements an AOF rewrite process. It forks a child process that rewrites the log by keeping only the minimal set of commands needed to reconstruct the current dataset, merging consecutive operations where possible. During rewrite, new write commands are copied to a separate rewrite buffer and appended to the new AOF after the child finishes, ensuring consistency.

Easter Egg

The story ends with a humorous dialogue showing that with both RDB and AOF in place, Redis can recover quickly from crashes, and suggests running multiple instances for higher reliability.