Understanding Redis Persistence: A Deep Dive into AOF and RDB

Introduction

Redis is an in‑memory database that offers high speed but faces data‑loss risks when the server crashes and restarts. Persisting data and enabling fast recovery are therefore essential.

What Is AOF?

AOF (Append Only File) is a write‑behind log that records each command only after it has been successfully executed, avoiding the inclusion of failed commands.

Benefits of AOF include:

Only successful commands are logged, preventing erroneous entries.

Logging occurs after command execution, so it does not block the command itself.

However, AOF has risks:

If the server crashes before the log is flushed to disk, the last commands are lost.

Since logging runs in the main thread, a disk‑write stall can delay subsequent commands.

Three Write‑Back Strategies

AOF provides three appendfsync policies: Always: Synchronously writes each command to disk immediately. Everysec: Buffers commands in memory and writes them to disk every second. No: Relies on the operating system to decide when to flush the buffer.

Each strategy balances reliability and performance: Always offers high reliability but incurs significant performance overhead. Everysec provides moderate performance with a potential loss of up to one second of data. No gives the best performance but may lose more data during a crash.

AOF Rewrite Mechanism

When the AOF file grows large, Redis can rewrite it to a compact form. The rewrite creates a new AOF file that contains only the latest state of each key, replacing many incremental commands with a single SET command. set key1 value1 The rewrite runs in a background child process ( bgrewriteaof), so the main thread continues handling client requests.

During rewrite, two logs exist:

The original AOF continues to record new commands.

The new AOF being rewritten records the compacted state.

After the rewrite finishes, the new file replaces the old one, ensuring no data loss.

AOF Drawbacks

Even after rewriting, restoring data from AOF is slow because commands must be replayed sequentially in a single thread.

What Is RDB?

RDB (Redis DataBase) is a snapshot‑based persistence method that saves the entire memory state to disk at a point in time.

Snapshots enable rapid recovery because the whole dataset is loaded at once, without replaying individual commands.

Snapshot Commands

Redis provides two commands for snapshots: save: Executes in the main thread and blocks other operations. bgsave: Forks a child process to write the RDB file, avoiding main‑thread blockage (default configuration).

Copy‑On‑Write (COW) Technique

During a snapshot, the child process shares the parent’s memory. If the parent modifies data, the OS creates a copy of the affected pages, allowing the child to write a consistent snapshot while the parent continues processing writes.

Snapshot Frequency and Incremental Snapshots

Frequent full snapshots can degrade performance, so Redis introduced incremental snapshots that record only changes since the last full snapshot.

Incremental snapshots reduce I/O overhead but require additional memory to track modified keys.

Hybrid AOF + RDB Strategy

Since Redis 4.0, a hybrid approach combines periodic RDB snapshots (e.g., every hour) with AOF logging of commands that occur between snapshots. This leverages fast RDB recovery and the detailed command log of AOF while keeping the AOF file size manageable.

The hybrid method avoids frequent full snapshots and limits AOF growth, offering both quick recovery and reduced rewrite overhead.

Overall Summary

AOF provides durable, command‑level persistence with three configurable write‑back policies that trade off reliability against performance. AOF rewrite compacts large logs without blocking the main thread.

RDB captures a point‑in‑time memory snapshot, enabling rapid recovery. The bgsave command uses forked child processes and copy‑on‑write to avoid blocking the main thread.

Combining AOF and RDB gives the best of both worlds: fast recovery from RDB and minimal data loss from AOF, while controlling log size and performance impact.