Redis Persistence Strategies: RDB, AOF, and Hybrid Approaches

Background

A candidate was asked in an interview how to recover data when Redis crashes, revealing that interviewers often test a candidate's understanding of Redis persistence strategies.

Why Persistence Is Needed

Redis stores data in memory, so a crash would lose all data. Restoring from a downstream database can overload that database and degrade performance, making Redis persistence essential.

Persistence Strategies

Redis officially supports four persistence modes:

RDB (Redis Database) : Periodic snapshots of the dataset.

AOF (Append‑Only File) : Logs every write command and replays them on restart.

RDB + AOF : Combines both mechanisms.

No persistence : Disables persistence entirely.

RDB

RDB creates a binary snapshot file (default dump.rdb ) using the SAVE or BGSAVE commands. SAVE blocks the main thread, while BGSAVE forks a child process to write the snapshot without blocking.

RDB Configuration (redis.conf)

# Periodic snapshot format
save <seconds> <changes>

# Default settings
save 900 1
save 300 10
save 60 10000

# Disable snapshots
save ""

The three default rules mean a snapshot is taken when at least 1 change occurs within 900 s, 10 changes within 300 s, or 10 000 changes within 60 s.

Copy‑On‑Write (COW)

During BGSAVE , Redis forks a child process that shares the parent’s memory. When the parent modifies data, the changed pages are copied (COW), allowing the child to write a consistent snapshot while the parent continues handling writes.

Snapshot Frequency

Frequent full snapshots reduce potential data loss but increase disk I/O and cause repeated fork operations, which can block the main thread. The optimal frequency depends on business tolerance for data loss.

AOF

AOF records every write command. On restart, Redis replays the log to rebuild the dataset. By default AOF is disabled and can be enabled in redis.conf :

# Enable AOF persistence
appendonly yes

# AOF file name
appendfilename "appendonly.aof"

# Sync policy (choose one)
appendfsync always   # every write is synced to disk
appendfsync everysec # sync once per second
appendfsync no       # let OS decide when to sync

Write‑Back Strategies

Always : Guarantees minimal data loss but incurs high latency.

Everysec : Balances durability and performance; up to one second of data may be lost.

No : Best performance, but data may be lost until the OS flushes buffers.

AOF Rewrite

Over time the AOF file grows. The BGREWRITEAOF background process creates a compacted log that contains only the latest state‑changing command for each key, reducing file size while the main thread continues serving requests.

Hybrid RDB + AOF (Redis 4.0)

The hybrid approach takes periodic RDB snapshots and logs only the operations that occur between snapshots using AOF. This reduces the frequency of costly fork operations, keeps the AOF file small, and combines fast snapshot recovery with near‑real‑time durability.

Conclusion

Both RDB and AOF have strengths and weaknesses. Choose the strategy that matches your business requirements:

If data loss is unacceptable, use the hybrid RDB+AOF method.

If losing a few minutes of data is tolerable, pure RDB may suffice.

If you prefer AOF, the everysec sync option offers a good trade‑off between reliability and performance.

Reference: Redis Persistence Documentation