Redis Persistence Deep Dive: RDB, AOF, and Hybrid Persistence Explained

Overview

Redis provides a mature persistence mechanism that ensures data safety for this high‑performance in‑memory database. The three main approaches are RDB snapshots, AOF command logging, and the hybrid persistence mode added in Redis 4.0.

1. RDB (Redis Database)

RDB creates a binary snapshot of the in‑memory dataset at specified intervals and writes it to a file (default dump.rdb).

How it works

Persistence is triggered (e.g., at least one key change within 900 seconds).

Redis forks a child process.

Parent process continues handling client requests.

Child process writes the dataset to a temporary RDB file.

After writing, the temporary file replaces the old RDB file.

The process uses Copy‑On‑Write to maintain performance.

Configuration example

save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
dbfilename dump.rdb
dir ./

Pros

High performance; persistence runs in a child process.

Fast recovery because the file is compact.

Suitable for backups.

Cons

Data may be lost since the last snapshot.

Forking large datasets can block the main process.

2. AOF (Append Only File)

AOF records every write command and appends it to a log file; on restart Redis replays the log to rebuild the dataset.

How it works

Write commands are written to the aof_buf buffer.

According to the sync policy, the buffer is flushed to disk.

Sync policy

appendfsync everysec   # default & recommended: lose at most 1 second of data
appendfsync always    # safest: flush every command, but slowest
appendfsync no        # fastest: OS decides, may lose dozens of seconds

AOF Rewrite

Solves unlimited growth of the AOF file.

BGREWRITEAOF spawns a child process that creates a new file containing the minimal command set.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Pros

High data safety (everysec loses at most 1 second).

AOF file is human‑readable and can be manually repaired.

Cons

File size larger than RDB.

Recovery is slower because commands must be replayed.

Write‑heavy workloads see a slight performance drop.

3. Hybrid Persistence (RDB + AOF)

Introduced in Redis 4.0, this mode combines the benefits of RDB and AOF.

How it works

Enable AOF with appendonly yes.

When an AOF rewrite occurs, the first part of the file is an RDB snapshot, followed by the incremental AOF log.

Pros

Fast recovery: load the RDB snapshot then replay a small number of commands.

Minimal data loss (same as AOF everysec).

File size smaller than a pure AOF file.

4. Practical Tips

File safety : regularly back up RDB and AOF files to different disks or hosts; use redis-check-rdb and redis-check-aof to repair corrupted files.

AOF rewrite memory consumption : rewrite relies on fork, doubling memory usage; monitor memory to avoid OOM.

Compatibility : hybrid files can only be restored on Redis 4.0+; be careful when multiple Redis versions coexist.

Cluster considerations : persistence guarantees safety per node only; combine master‑slave replication with external cold backups (e.g., OSS/S3).

5. Production‑grade Configuration

# Enable AOF (hybrid persistence)
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes

# Keep RDB as insurance
save 900 1
save 300 10
save 60 10000

6. Strategy Selection Guidance

Pure cache, data loss acceptable : use only RDB.

Data important, up to 1 second loss allowed : combine AOF everysec with RDB.

Most scenarios : adopt hybrid persistence (recommended).

Financial/transactional data : use AOF always + high‑performance disks + master‑slave replication.

Conclusion

RDB : snapshot‑based, fast restore, suitable for backups, but may lose recent data.

AOF : logs every write, higher safety, slower recovery, larger files.

Hybrid persistence : recommended for balancing performance and safety.

Best practice : enable persistence, use master‑slave replication, and perform regular cold backups to avoid single points of failure.