Mastering Redis Persistence: A Deep Dive into AOF, RDB, and Hybrid Strategies

Overview

Redis provides three persistence mechanisms to protect in‑memory data from loss: Append‑Only File (AOF), snapshot files (RDB), and a hybrid mode that combines both. Each mechanism has distinct trade‑offs in durability, recovery speed, and storage overhead.

AOF Persistence

AOF records every write command in the Redis Serialization Protocol (RESP) format. On restart Redis replays the log to reconstruct the dataset. Because commands are logged only after they have been applied to memory, the log always contains valid, executable commands.

AOF File Content

Example command and its RESP representation:

redis> SET mufeng handsome
*3
$3
SET
$6
mufeng
$8
handsome

Data‑Loss Risk and appendfsync Options

appendfsync no – the operating system decides when to flush the AOF buffer (lowest durability).

appendfsync everysec – the buffer is flushed every second (balanced durability and performance).

appendfsync always – each write is synchronously flushed to disk (highest durability, highest latency).

In most deployments appendfsync everysec is recommended.

File‑Size Growth and Rewrite

Because every write is appended, the AOF file can become large. Redis mitigates this by rewriting the AOF: a child process traverses the current dataset and writes a compacted file that contains only the latest command for each key, discarding obsolete operations.

Fork and Copy‑On‑Write (COW)

The rewrite (and RDB snapshot) is performed in a forked child process. The child receives a copy‑on‑write view of the parent’s memory, sharing pages until a write occurs, which minimizes additional memory consumption.

AOF Rewrite Process

Redis checks that no AOF rewrite or RDB dump is already running.

If clear, it forks a child process.

The child iterates over the dataset and writes a compacted AOF to a temporary file.

The parent continues serving clients, appending new writes to both the old AOF buffer and the temporary rewrite buffer.

When the child finishes, the temporary file atomically replaces the old AOF.

AOF Pros and Cons

Pros: fine‑grained durability configuration; log is easy to understand.

Cons: larger file size than RDB; recovery requires replaying every command, which is slower.

RDB Persistence (Snapshots)

RDB creates point‑in‑time snapshots of the entire dataset. Snapshots can be generated manually with SAVE (blocking) or BGSAVE (forks a child), or automatically based on save directives in redis.conf (e.g., save 900 1, save 300 10, save 60 10000).

RDB Generation Process

int rdbSaveBackground(char *filename, rdbSaveInfo *rsi) {
    pid_t childpid;
    if (server.aof_child_pid != -1 || server.rdb_child_pid != -1) return C_ERR;
    if ((childpid = fork()) == 0) {
        /* child creates RDB file */
        retval = rdbSave(filename, rsi);
        exitFromChild(retval == C_OK ? 0 : 1);
    } else {
        /* parent continues serving */
    }
    return C_OK;
}

The parent may be briefly blocked during fork(), especially with large datasets, but once the child is running the parent can continue handling client requests.

Trigger Timing

Manual commands: SAVE (blocking) and BGSAVE (non‑blocking).

Automatic: configured intervals in redis.conf.

Replication: a slave’s full sync triggers an RDB snapshot on the master.

Data‑Loss Risk

Since snapshots are taken at intervals, any writes that occur after the last snapshot and before a crash are lost.

RDB Pros and Cons

Pros: fast recovery (single file load), compact file size, suitable for full backups.

Cons: potential data loss between snapshots; heavy I/O during snapshot creation; fork‑induced pause.

Hybrid Persistence

Available from Redis 4.0 onward, hybrid persistence enables the AOF rewrite to start with an RDB‑style preamble. The resulting file begins with a compact snapshot (fast load) followed by incremental AOF commands (fine‑grained durability).

Hybrid Pros and Cons

Pros: combines fast recovery of RDB with the durability granularity of AOF; resulting file is smaller than pure AOF.

Cons: only supported on Redis 4.0+; older deployments cannot use it.

Key Implementation Details

Automatic AOF Rewrite Trigger

Redis rewrites AOF automatically when both of the following conditions are met:

if (server.rdb_child_pid == -1 &&
    server.aof_child_pid == -1 &&
    server.aof_rewrite_perc &&
    server.aof_current_size > server.aof_rewrite_min_size) {
    long long base = server.aof_rewrite_base_size ? server.aof_rewrite_base_size : 1;
    long long growth = (server.aof_current_size * 100 / base) - 100;
    if (growth >= server.aof_rewrite_perc) {
        serverLog(LL_NOTICE, "Starting automatic rewriting of AOF on %lld%% growth", growth);
        rewriteAppendOnlyFileBackground();
    }
}

Manual AOF Rewrite Command

void bgrewriteaofCommand(redisClient *c) {
    if (server.aof_child_pid != -1) {
        addReplyError(c, "Background append only file rewriting already in progress");
    } else if (server.rdb_child_pid != -1) {
        server.aof_rewrite_scheduled = 1;
        addReplyStatus(c, "Background append only file rewriting scheduled");
    } else if (rewriteAppendOnlyFileBackground() == REDIS_OK) {
        addReplyStatus(c, "Background append only file rewriting started");
    } else {
        addReply(c, shared.err);
    }
}

Conclusion

Understanding the inner workings, strengths, and weaknesses of Redis’s persistence options—AOF, RDB, and hybrid—allows engineers to choose a durability strategy that matches application reliability requirements and performance constraints, thereby improving overall system stability.