Databases 11 min read

Understanding Redis Persistence: RDB vs AOF Explained

This article provides a detailed analysis of Redis's two persistence mechanisms—RDB snapshots and AOF logging—covering their core concepts, implementation details, trigger conditions, data safety, performance impact, and recovery speed to help engineers choose the appropriate method for their workloads.

Tencent TDS Service
Tencent TDS Service
Tencent TDS Service
Understanding Redis Persistence: RDB vs AOF Explained

1. Overview

Redis is increasingly used not only as an in‑memory cache but also as a durable data store, prompting the need to persist data to disk so that a restart does not lose cached information.

Redis offers two persistence modes:

2. RDB Persistence Mode

2.1 Core Idea

Creates a snapshot of the current memory state and writes it to disk, providing a full backup of the data.

2.2 Challenges

Obtaining a memory snapshot requires forking a child process that shares the parent’s memory via copy‑on‑write.

Disk I/O during the save operation could block other requests, but RDB saving runs in a separate child process, avoiding impact on the main process.

2.3 RDB File Format

The RDB file consists of a fixed header, version, architecture flag, timestamp, memory size, followed by database data and an EOF marker with a checksum.

Database entries are stored as:

SELECTDB marker indicating the start of a database.

Database number (e.g., 0).

Total key count and expired key count.

Key‑value pairs.

2.4 Trigger Conditions

save 900 1          // after 15 minutes if at least 1 write
save 300 10         // after 5 minutes if at least 10 writes
save 60 10000       // after 1 minute if at least 10000 writes

Manual triggers:

>save   // synchronous RDB save
>bgsave // asynchronous RDB save (default)

2.5 Data Safety

If the machine crashes, all data written after the last successful RDB save is lost.

2.6 Core Source (bgsave example)

int rdbSaveBackground(char *filename, rdbSaveInfo *rsi) {
    pid_t childpid;
    long long start;
    if (server.aof_child_pid != -1 || server.rdb_child_pid != -1) return C_ERR;
    server.dirty_before_bgsave = server.dirty;
    server.lastbgsave_try = time(NULL);
    openChildInfoPipe();
    start = ustime();
    if ((childpid = fork()) == 0) {
        closeListeningSockets(0);
        redisSetProcTitle("redis-rdb-bgsave");
        int retval = rdbSave(filename,rsi);
        if (retval == C_OK) sendChildInfo(CHILD_INFO_TYPE_RDB);
        exitFromChild(retval == C_OK ? 0 : 1);
    } else {
        server.stat_fork_time = ustime()-start;
        server.rdb_save_time_start = time(NULL);
        server.rdb_child_pid = childpid;
        server.rdb_child_type = RDB_CHILD_TYPE_DISK;
        updateDictResizePolicy();
        return C_OK;
    }
    return C_OK;
}

3. AOF Persistence Mode

3.1 Core Idea

Appends every write command received by the server to a log file; recovery replays the commands.

3.2 Challenges

The AOF file can grow large due to redundant commands; Redis periodically rewrites the AOF to eliminate waste.

Write operations happen in the main thread, but the costly fsync is performed by a dedicated background thread, preventing main‑thread blockage.

3.3 File Format

The AOF stores raw Redis command protocol entries.

3.4 Trigger Conditions

Enabled via configuration: appendonly yes # enable AOF Flush policies:

# appendfsync always   // flush on every write
appendfsync everysec   // flush once per second (default)
# appendfsync no       // let OS handle flushing

3.5 Performance Impact

Writes occur in the main thread, but fsync runs in a separate thread, so enabling AOF does not severely affect throughput.

3.6 AOF Rewrite

Rewrite removes redundant commands by reconstructing the current dataset into a fresh AOF file, avoiding costly command‑by‑command analysis.

Trigger command:

>bgrewriteaofCommand

3.7 Data Safety

Data loss depends on the appendfsync setting:

always : may lose data due to batch flushing after epoll wait.

everysec : typically loses up to 2 seconds of data because a pending flush can be delayed.

no : loss is unpredictable as the kernel decides when to flush.

4. Recovery Speed: RDB vs AOF

RDB restores faster because it loads a compact snapshot, while AOF may contain many redundant commands; however, after an AOF rewrite, the file is compact and recovery speed becomes comparable.

5. Conclusion

The article thoroughly explains both RDB and AOF persistence mechanisms, enabling engineers to select the most suitable approach based on their specific business requirements.

databaseRedisPersistenceData RecoveryAOFRDB
Tencent TDS Service
Written by

Tencent TDS Service

TDS Service offers client and web front‑end developers and operators an intelligent low‑code platform, cross‑platform development framework, universal release platform, runtime container engine, monitoring and analysis platform, and a security‑privacy compliance suite.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.