Understanding Redis Persistence: AOF and RDB Mechanisms

Preface

If someone asks you, "In which business scenarios would you use Redis?" you will most likely answer that you use it as a cache because it stores data from the backend database in memory and reads directly from memory, offering very fast response times. However, a critical issue is that if the server crashes, all data in memory is lost.

Redis provides two main persistence mechanisms: Append‑Only File (AOF) logging and RDB (Redis DataBase) snapshots.

1. AOF

How the log is implemented

Unlike the Write‑Ahead Log (WAL) used by many databases, which records changes before they are applied, AOF is a write‑behind log: Redis first executes the command, updates the in‑memory data, and then records the command.

AOF records every command received by Redis in plain text. For example, after the command *3 (indicating three parts) the log contains entries such as $3 set , where the number after the dollar sign denotes the byte length of the following token.

Advantages and Risks of Write‑Behind Logging

Because Redis records a command only after it has been successfully executed, erroneous commands are not logged, avoiding recovery errors. Additionally, logging after execution does not block the current write operation.

However, two risks exist:

Risk 1: If the server crashes before the command is logged, that command and its data are lost. This is tolerable when Redis is used as a cache (data can be reloaded from the backend), but not when Redis serves as the primary database.

Risk 2: AOF logging runs in the main thread; if writing the log to disk is slow, subsequent operations may be blocked.

Write‑back Strategies

Redis offers three AOF write‑back strategies, configured via the appendfsync option:

Always: Synchronously write each command to disk immediately after execution.

Everysec: Buffer commands in memory and flush to disk every second.

No: Let the operating system decide when to flush the buffered data.

Choosing a strategy depends on the balance between performance and reliability: "No" for highest performance, "Always" for strongest durability, and "Everysec" for a compromise.

Log Rewriting

Purpose

Since AOF continuously appends commands, the file can grow large, leading to file‑system limits, slower appends, and slow recovery after a crash.

Log rewriting creates a new, compact AOF file by reading the current dataset and writing a single command for each key, effectively converting many incremental commands into one.

Process

The rewrite is performed by a background child process bgrewriteaof , avoiding main‑thread blockage. The steps are:

The main thread forks a child process, which receives a copy of the current in‑memory data.

The child writes the new AOF file based on this snapshot.

Meanwhile, the main thread continues handling new commands, logging them to the original AOF buffer (first log).

The child also logs its own operations to a second buffer (second log).

When rewriting finishes, the new AOF file replaces the old one, and both logs ensure no data loss.

This two‑log approach guarantees that commands arriving during rewriting are not lost and that the rewrite does not block normal operations.

2. RDB

RDB creates point‑in‑time snapshots of the dataset, storing the entire state in a file. If a crash occurs, the snapshot can be loaded quickly, providing reliable recovery.

RDB records data, not commands, so restoration is faster than replaying an AOF.

Snapshot Mechanics

Redis provides two commands to generate 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 (the default).

During bgsave , Redis uses copy‑on‑write (COW) so that the child writes the original data while the parent can continue handling writes, copying modified pages as needed.

Mixed AOF/RDB

Frequent full snapshots can strain disk I/O and cause long fork pauses. Redis 4.0 introduced a hybrid approach: periodic RDB snapshots combined with AOF logging of commands between snapshots. This reduces snapshot frequency, limits AOF size, and balances performance with durability.

3. Summary

When choosing between AOF and RDB, consider the following:

If data loss is unacceptable, use a hybrid of snapshots and AOF.

If minute‑level data loss is tolerable, RDB alone may suffice.

If using only AOF, the everysec setting offers a good trade‑off between reliability and performance.

References

GeekTime – Jiang Dejun’s "Redis Core Technology and Practice" (highly recommended).

"Redis Core Technology and Practice" study notes Day13.