How Redis RDB Works: Snapshotting, BGSAVE, and Copy‑On‑Write Explained

What Is RDB?

RDB (Redis DataBase) is Redis’s snapshot‑based persistence strategy. It creates a full‑copy of the in‑memory dataset at a specific moment and writes it to disk as an RDB file.

Full‑Backup and Thread Blocking

Does the backup block the main thread?

Redis processes client commands in a single thread, so operations that block this thread should be avoided. Two commands can generate an RDB file: SAVE – blocks the main thread until the RDB file is finished. BGSAVE – forks a child process to write the RDB file while the parent continues handling requests.

Example of a blocking SAVE:

127.0.0.1:6379> SAVE
OK

Example of a non‑blocking BGSAVE:

127.0.0.1:6379> BGSAVE
Background saving started

Note: The parent process briefly blocks during the fork() call, but the overhead is usually negligible.

The RDB file is created by the rdb.c/rdbSave function. The two commands invoke this function differently. Pseudocode:

void SAVE() {
    // create RDB file
    rdbSave();
}

void BGSAVE() {
    // create child process
    pid = fork();
    if (pid == 0) { // child
        rdbSave();
        signal_parent();
    } else if (pid > 0) { // parent
        handle_request_and_wait_signal();
    } else {
        // error handling
    }
}

Snapshot of a Moment vs. Interval

RDB stores a full snapshot of the dataset at a single point in time, not a range of time. A point‑in‑time snapshot accurately reflects the system state at that moment (e.g., t1), whereas an interval snapshot would mix states and could not guarantee correct recovery.

Can Data Be Modified During Backup?

During a snapshot, Redis must prevent modifications that would corrupt the point‑in‑time view. However, Redis can still accept write requests thanks to its copy‑on‑write (COW) mechanism, which isolates writes from the snapshot process.

Redis Copy‑On‑Write (COW)

COW is an operating‑system feature, not a Redis‑specific invention. When Redis forks, the child shares the parent’s memory pages. Only when the parent modifies a page does the kernel copy that page for the parent, leaving the child with the original data.

Note: COW assumes that write traffic is relatively low; heavy write loads increase memory‑copy overhead.

Automatic Periodic Backups

Beyond manual SAVE and BGSAVE, Redis can automatically trigger BGSAVE based on the save configuration in redis.conf. The default settings are:

save 900 1
save 300 10
save 60 10000

When any of the following conditions is met, Redis runs BGSAVE:

At least 1 change within 900 seconds.

At least 10 changes within 300 seconds.

At least 10,000 changes within 60 seconds.

Example log when the 300‑second/10‑change rule fires:

1:M 24 Nov 2021 07:02:28.081 * 10 changes in 300 seconds. Saving...

1:M 24 Nov 2021 07:02:28.082 * Background saving started by pid 22

22:C 24 Nov 2021 07:02:28.142 * DB saved on disk

22:C 24 Nov 2021 07:02:28.143 * RDB: 0 MB of memory used by copy-on-write

1:M 24 Nov 2021 07:02:28.183 * Background saving terminated with success

saveparams Structure

The server stores the save conditions in an array called saveparams, each element being a saveparam struct:

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

Visually, the default saveparams array looks like:

dirty Counter and lastsave

The server also tracks two fields: dirty – the number of write operations since the last successful RDB snapshot. lastsave – the UNIX timestamp of the last successful snapshot.

Each write increments dirty. For example, a multi‑key SADD adds three to the counter:

redis> SADD fruits apple banana orange

After this command, dirty might be 101, indicating 101 modifications since the previous snapshot, and lastsave could be 1638023962 (2021‑11‑27 22:39:22).

Periodic Check via serverCron

The serverCron function runs every 100 ms and evaluates each saveparam. If the elapsed time since lastsave exceeds seconds **and** dirty is greater than or equal to changes, it triggers BGSAVE:

void serverCron() {
    ...
    for (saveparam in server.saveparams) {
        save_interval = unixtime_now() - server.lastsave;
        if (save_interval > saveparam.seconds && server.dirty >= saveparam.changes) {
            BGSAVE();
        }
    }
    ...
}

Assume the server’s state shows lastsave at 1638023962. When the clock reaches 1638024263 (301 seconds later), the second rule (300 seconds ≥ 10 changes) is satisfied, so Redis launches a BGSAVE. After the background save finishes (e.g., in 4 seconds), the server’s dirty counter resets and lastsave updates, as illustrated by the following diagram:

This automatic mechanism ensures that Redis periodically persists a consistent point‑in‑time snapshot without manual intervention.