How Redis Guarantees Fast Recovery: RDB Snapshots and AOF Logging Explained

Redis is commonly used as an in‑memory cache, but a crash can cause all cached data to disappear and force traffic onto the backend database. To avoid data loss and enable quick recovery, Redis provides two persistence mechanisms: RDB snapshots and the AOF (Append‑Only File) log.

RDB Memory Snapshots

RDB creates a point‑in‑time snapshot of the entire dataset and writes it to a binary file on disk. The snapshot is generated either by the SAVE command, which blocks the main thread, or by BGSAVE, which forks a child process using the fork system call. The child writes the snapshot while the parent continues to serve client requests.

During snapshot creation, the child process receives a copy‑on‑write (COW) view of the memory, allowing the parent to modify data without affecting the snapshot. This ensures data consistency without blocking writes, although very frequent snapshots can increase disk I/O and cause the fork operation to pause the main thread for longer periods.

Snapshot Generation Strategy

SAVE

: Executes in the main thread and blocks all operations until the snapshot is finished. BGSAVE: Forks a background child process; the parent remains responsive while the child writes the RDB file.

AOF Write‑After Log

The AOF records every write command that modifies the dataset. On restart, Redis replays the AOF to reconstruct the exact state. Unlike write‑ahead logs, AOF writes after the command has been applied, avoiding extra syntax‑checking overhead.

AOF File Format

Each command is stored in a RESP‑style format, e.g., *3 followed by $3 for the command name, then the key and value sizes.

fsync Policies

Redis controls how often the AOF buffer is flushed to disk using the appendfsync setting:

always : Flush after every write (maximum durability, lowest performance).

everysec : Flush once per second (good balance between safety and speed).

no : Let the operating system decide (best performance, risk of data loss).

AOF Rewrite Mechanism

To prevent the AOF file from growing indefinitely, Redis provides the bgrewriteaof command. A background child process rewrites the log by compacting multiple operations into a minimal set of commands, then replaces the old file atomically.

The rewrite runs in a separate process to avoid blocking the main thread and to prevent file‑access contention.

Hybrid Persistence (Redis 4.0)

Redis 4.0 introduced a hybrid model that stores an RDB snapshot together with the incremental AOF generated since the snapshot. On restart, Redis first loads the RDB data and then replays the small AOF segment, dramatically reducing restart time for large datasets.

Practical Recommendations

When zero data loss is required, combine RDB snapshots with AOF (preferably the everysec fsync policy).

If occasional data loss is acceptable, rely on periodic RDB snapshots only.

For pure performance, disable AOF or use the no fsync setting, but be aware of the risk.

Overall, Redis balances high performance, high availability, and scalability through its dual persistence strategy, copy‑on‑write snapshotting, configurable AOF policies, and the hybrid persistence model introduced in version 4.0.