Understanding Redis Persistence: RDB and AOF Mechanisms

Redis is an in‑memory key‑value database that must persist data to survive power loss; it offers two persistence mechanisms: RDB (snapshot) and AOF (append‑only file).

RDB persistence creates a compressed dump file using the SAVE or BGSAVE commands. SAVE blocks the server until the dump is finished, while BGSAVE forks a child process so the main server continues handling requests. Both ultimately invoke rdbSave() . The RDB file consists of a 4‑byte db_version , a databases section containing all key‑value pairs, an EOF marker, and an 8‑byte check_sum .

def save():
    rdbSave()

def BGSAVE():
    # create child process
    pid = fork()
    if pid == 0:
        # child creates RDB file
        rdbSave()
        signal_parent()
    elif pid > 0:
        # parent continues serving and waits for signal
        handle_request_and_wait_signal()
    else:
        handle_fork_error()

AOF persistence records every write command in the Redis protocol format. After each write, the server appends the command to an in‑memory buffer aof_buf . At the end of each event loop the buffer is flushed to the AOF file according to the appendfsync setting:

appendfsync

option

flushAppendOnlyFile behavior

always

Write and sync

aof_buf

to the AOF file on every loop.

everysec

Write

aof_buf

each loop; sync at most once per second in a dedicated thread.

no

Write

aof_buf

each loop; OS decides when to sync.

Example AOF content for three write commands:

*2
$6
SELECT
$1
0
*3
$3
SET
$3
msg
$5
hello
*5
$4
SADD
$6
fruits
$5
apple
$6
banana
$6
cherry
*5
$5
RPUSH
$7
numbers
$3
128
$3
256
$3
512

The AOF file grows over time, so Redis provides an AOF rewrite feature that creates a new compact AOF from the current dataset without reading the old file, optionally splitting large collections into multiple commands.

Configuration of appendfsync determines the trade‑off between durability and performance: always is the safest but slowest, everysec offers a good balance (at most one second of data loss), and no is fastest but may lose all data written after the last OS‑level sync.