Understanding Redis Persistence: RDB vs AOF Explained

Introduction

Redis stores all data in memory, which gives it high performance but makes the dataset volatile when the server crashes or restarts. Redis provides two persistence mechanisms—RDB (Redis Database Backup) and AOF (Append‑Only File)—to write the in‑memory state to disk and recover it after a restart.

Persistence Overview

Both mechanisms periodically dump the dataset to disk. The process of writing the dataset to a file is called Redis persistence.

RDB (Snapshot)

What is RDB?

RDB creates a compressed binary snapshot of the entire dataset (default file dump.rdb) and stores it on disk.

Creating an RDB File

SAVE – synchronous command that blocks the server until the snapshot is finished.

BGSAVE – asynchronous command that forks a child process to write the snapshot while the parent continues serving clients.

def SAVE():
    # create RDB file synchronously
    rdbSave()

def BGSAVE():
    pid = fork()
    if pid == 0:
        # child creates RDB file
        rdbSave()
        signal_parent()
    elif pid > 0:
        # parent continues processing requests
        handle_request_and_wait_signal()
    else:
        handle_fork_error()

Loading an RDB File

When the server starts, it automatically loads the latest dump.rdb. The server is blocked until the load completes.

RDB Configuration

The save option defines automatic BGSAVE triggers. Example:

save 900 1
save 300 10
save 60 10000

These rules mean a snapshot is taken if at least 1 change occurs within 900 seconds, or at least 10 changes within 300 seconds, etc. The internal serverCron function runs every 100 ms, checks the configured save conditions, and invokes BGSAVE when they are satisfied.

Internally Redis stores each condition in a saveparam struct:

struct saveparam {
    time_t seconds;   // seconds threshold
    int    changes;   // number of write operations
}

The dirty counter tracks how many write operations have occurred since the last successful SAVE or BGSAVE. The lastsave timestamp records the time of the last successful snapshot.

Default RDB Settings

# Snapshotting configuration (default)
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir ./

AOF (Append‑Only File)

What is AOF?

AOF records every write command in the Redis protocol format. It is a write‑ahead log that is appended to a file after each command.

How AOF Works

When a write command is executed, it is appended to the in‑memory buffer aof_buf.

Before each event‑loop iteration ends, Redis calls flushAppendOnlyFile to write the buffer to disk and optionally invoke fsync based on the appendfsync policy.

Append Strategies

always – every command is synchronously flushed to disk.

everysec (default) – the buffer is flushed once per second.

no – the OS decides when to flush, based on its own policies.

Loading an AOF File

Create a pseudo‑client without a network connection.

Read the next write command from the AOF file.

Execute the command using the pseudo‑client.

Repeat until the file is exhausted.

AOF Rewrite

To prevent unbounded growth, Redis can rewrite the AOF file: a new compact file is generated that contains a minimal set of commands representing the current dataset, discarding redundant history.

Rewrite Implementation

No modification of the existing AOF file is required.

The current key values are read directly from the database.

One command per key is written to the new file, replacing many older commands.

Background Rewrite

The rewrite runs in a child process so the parent can continue serving clients. While the child rewrites, the parent appends new write commands to both the normal AOF buffer and a separate rewrite buffer.

AOF Configuration

# Enable AOF persistence
appendonly no
# AOF file name
appendfilename "appendonly.aof"
# Flush policy (default every second)
appendfsync everysec
# Trigger rewrite when file grows 100% and exceeds 64 MB
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# Ignore the last possibly corrupted command on load
aof-load-truncated yes
# Use RDB preamble for faster loading
aof-use-rdb-preamble yes

Choosing Between RDB and AOF

For large‑scale applications that need both data integrity and high performance, enable both RDB and AOF.

If durability is the primary concern and a slight write latency penalty is acceptable, prefer AOF.

If fast recovery of massive datasets is critical, prefer RDB.

Illustrative Diagrams