Understanding Redis Persistence: AOF, RDB, and Hybrid Mechanisms

Introduction

Redis is a core in‑memory data store used in micro‑service architectures; while it provides fast data access, its memory‑only nature means data is lost on server crashes. To mitigate this, Redis offers three persistence mechanisms: AOF, RDB, and a hybrid mode.

AOF Persistence

AOF (Append Only File) records every write command to an append‑only log, allowing the server to replay the log on restart. Only modifying commands are logged; read commands are ignored.

Unlike traditional WAL implementations, Redis writes the command to the AOF after it has been applied to memory, ensuring that the logged command is always valid.

What is stored in an AOF file?

The AOF file contains the raw Redis commands in RESP format. For example:

redis> SET mufeng handsome
OK

The corresponding RESP packet is *3\r\n$3set\r\n$6mufeng\r\n$8handsome , which is the exact byte sequence stored in the AOF.

Risk of data loss

If a crash occurs before the command is flushed to disk, the latest write is lost. The timing of the flush is controlled by the appendfsync setting.

Three AOF fsync strategies

appendfsync no : The OS decides when to write the buffer to disk, offering the highest performance but no guarantee of durability.

appendfsync everysec : Redis flushes the buffer every second, balancing durability and performance.

appendfsync always : Every write is synchronously flushed, providing the strongest durability at the cost of higher latency.

In most production environments the everysec policy is recommended for a good reliability‑performance trade‑off.

AOF Rewrite

Over time the AOF file grows because it stores every command. A rewrite creates a compacted AOF that contains only the latest state for each key.

The rewrite is performed by forking a child process that walks the current dataset and writes a new temporary AOF. While the child rewrites, the parent continues to serve clients, appending new commands to both the old AOF buffer and the rewrite buffer. After the child finishes, the temporary file atomically replaces the old AOF.

Rewrite is triggered manually with BGREWRITEAOF or automatically when the file size exceeds auto-aof-rewrite-percentage and auto-aof-rewrite-min-size . The command implementation (simplified) is:

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);
    }
}

Advantages of AOF

Fine‑grained durability configuration.

Human‑readable command log.

Disadvantages of AOF

Larger file size compared with RDB.

Slower recovery because commands must be replayed.

RDB Persistence

RDB creates point‑in‑time snapshots of the entire dataset. The snapshot is a compact binary file that can be loaded quickly on restart.

Snapshot generation process

When a snapshot is requested (via SAVE , BGSAVE , or the periodic save configuration), Redis forks a child process. The child walks the dataset and writes the RDB file, while the parent continues to serve clients. The fork uses copy‑on‑write, so only pages that are modified after the fork are duplicated.

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

Triggering RDB snapshots

Manual SAVE (blocking) or BGSAVE (non‑blocking).

Automatic snapshots configured with save directives, e.g., save 900 1 , save 300 10 , save 60 10000 .

Risks and drawbacks

Because snapshots are taken at intervals, any writes that occur between snapshots can be lost if the server crashes. Additionally, the fork operation can be costly for large datasets, temporarily increasing memory usage and blocking the parent process.

Advantages of RDB

Fast recovery – the entire dataset is loaded in one step.

Compact on‑disk representation.

Ideal for full backups.

Disadvantages of RDB

Potential data loss between snapshots.

Forking large datasets can cause noticeable latency.

Hybrid Persistence

Since Redis 4.0, the aof-use-rdb-preamble yes option enables a hybrid mode that writes an RDB preamble to the AOF during rewrite. The child process creates an RDB‑style snapshot and then appends subsequent commands in AOF format, combining the fast load of RDB with the durability of AOF.

Pros

Benefits of both RDB (compact snapshot, fast load) and AOF (continuous durability).

Cons

Only available in Redis 4.0+; older versions cannot use it.

Conclusion

The article examined the inner workings, trade‑offs, and configuration details of Redis's AOF, RDB, and hybrid persistence mechanisms. Understanding these mechanisms helps engineers design a persistence strategy that matches their reliability and performance requirements, and illustrates why deep knowledge of middleware internals is essential for robust system design.