Understanding Redis Persistence: RDB and AOF Mechanisms

Redis is an in‑memory, non‑relational database that offers fast data access, but many systems require data durability after power loss or service failure, which leads to the need for persistence.

The article first discusses the motivation for persistence: storing in‑memory data to external storage so that data can be recovered after a restart.

1. RDB

RDB creates point‑in‑time snapshots of the entire dataset. The basic commands are SAVE (blocks client requests) and BGSAVE (forks a child process to perform the snapshot while the server continues handling requests).

Automatic periodic saving is configured in redis.conf with lines such as:

save 600 1
save 300 10
save 60 100
save 30 1000

These rules trigger a BGSAVE when the specified number of write operations occurs within the given time window.

The server stores the configuration in the redisServer structure, particularly the saveparams array and the dirty and lastsave fields. A simplified view of the relevant structs:

// Redis server state structure
 struct redisServer {
   // ...
   struct saveparam *saveparams;   // array of save rules
   long long dirty;                // number of changes since last save
   time_t lastsave;                // timestamp of last successful save
   // ...
 }
 // Save rule structure
 struct saveparam {
   time_t seconds;   // time interval
   int changes;       // number of modifications
 }

The server’s serverCron function runs every 100 ms, checks the saveparams , and launches BGSAVE when conditions are met.

The RDB file format starts with the magic string “REDIS”, followed by a 4‑byte version, the database payload, an EOF marker, and a checksum.

2. AOF

AOF records every write command that modifies the dataset. When the server starts and detects an AOF file, it replays the commands to rebuild the state (AOF takes precedence over RDB if both exist).

Enabling AOF is done by adding appendonly yes to the configuration. The server buffers commands in aof_buf (type sds ) and flushes them according to the appendfsync policy, which can be always , everysec , or no :

always : write and sync on every command (slowest, safest).

everysec : write immediately, sync at most once per second (balanced, recommended).

no : write without explicit sync, OS decides when to flush (fastest, least safe).

The relevant part of the server structure is:

struct redisServer{
   // ...
   sds aof_buf;   // buffer for AOF commands
   // ...
}

During normal operation, after a command is executed, it is appended to aof_buf and, before the event loop ends, flushAppendOnlyFile is called to handle the actual file write based on appendfsync .

2.2 Data Loading

When Redis starts and finds an AOF file, it parses the protocol‑encoded commands and replays them to reconstruct the dataset. If both RDB and AOF exist, AOF is preferred.

2.3 AOF Rewrite

Because the AOF file grows indefinitely, Redis can rewrite it into a compact form that contains only the minimal set of commands needed to recreate the current state. The rewrite runs in a background child process (triggered by BGREWRITEAOF ) to avoid blocking clients.

While the child rewrites, the parent continues serving requests and writes new commands to an AOF rewrite buffer. After the child finishes, the parent merges the buffer into the new file and atomically replaces the old AOF.

3. Summary

Redis provides two complementary persistence mechanisms—RDB snapshots for fast recovery and AOF command logging for durability. Each has its own strengths and suitable scenarios; using them together offers a balanced solution for data safety in production environments.