Mastering Redis Persistence: RDB vs AOF Explained

What is Redis Persistence?

Redis is an in‑memory key‑value store. Because data resides in RAM, a server shutdown or a crash causes all data to disappear. To avoid data loss, Redis provides persistence mechanisms that can write data to disk.

RDB (Snapshot) Persistence

RDB creates point‑in‑time snapshots of the dataset and saves them to a file (default dump.rdb). The snapshot can be loaded when the server restarts.

Enabling RDB

Clients can trigger a snapshot with the save (synchronous) or bgsave (asynchronous) commands, or by configuring automatic triggers in redis.conf.

1. save command

# Synchronously write data to disk
> save

If the dataset is large, save blocks the server and should be avoided in production.

2. bgsave command

# Asynchronously write data to disk
> bgsave

bgsave

forks a child process to write the snapshot, allowing the main process to continue handling requests, though the fork operation itself can cause a brief pause.

3. Automatic triggers

In redis.conf you can specify conditions such as “save after 900 seconds if at least 1 write operation occurs”. Example:

# At least 1 write in 900 seconds
save 900 1
# At least 10 writes in 300 seconds
save 300 10
# At least 10000 writes in 60 seconds
save 60 10000

When the conditions are met, Redis forks a child process to generate the RDB file.

RDB File Details

The temporary RDB file is written first, then renamed to replace the existing file. The default filename is dump.rdb, but it can be changed in the configuration (e.g., dbfilename redis-6379.rdb).

Advantages of RDB

Fast recovery because the snapshot can be loaded quickly.

Compact file size, suitable for backups.

Minimal impact on server performance since a child process does the I/O.

Disadvantages of RDB

Potential data loss between snapshots (e.g., if the server crashes before the next trigger).

The save command blocks the server.

Forking a large dataset can cause a pause and consume additional memory.

AOF (Append‑Only File) Persistence

AOF logs every write command received by the server. On restart, Redis replays the log to reconstruct the dataset.

Enabling AOF

# Enable AOF persistence
appendonly yes
# AOF filename
appendfilename "appendonly.aof"
# Write policy (always, everysec, no)
appendfsync always
# Do not rewrite AOF on rewrite
no-appendfsync-on-rewrite no
# Directory for AOF file
dir ~/redis/

Write Policies

always : Every write is flushed to disk immediately (safest but slowest).

everysec (default): Writes are flushed once per second, risking up to 1 second of data loss.

no : The OS handles flushing; fastest but least safe.

AOF Rewrite

Because AOF can grow large, Redis can rewrite the file to a minimal set of commands that recreate the current state.

# Trigger asynchronous AOF rewrite
> bgrewriteaof

The rewritten file contains compact commands (e.g., set key value ) rather than the full command history.

Benefits of AOF Rewrite

Reduces disk space usage.

Speeds up data recovery.

Repairing a Corrupted AOF

If the server crashes while writing the AOF, the file may become corrupted. Repair steps:

Back up the current AOF file.

Run redis-check-aof -fix file.aof to fix it.

Restart Redis to load the repaired file.

Advantages of AOF

Writes are appended, causing less performance impact than RDB.

Provides better durability (especially with always policy).

Disadvantages of AOF

The log file can become large even after rewrite.

Recovery is slower compared to loading an RDB snapshot.

Choosing Between RDB and AOF

Both mechanisms have trade‑offs. RDB offers fast recovery and compact files but may lose recent data. AOF provides better durability at the cost of larger files and slower recovery. In many deployments, enabling both gives maximum safety, but the combined I/O load can affect performance, so choose based on your application's consistency and latency requirements.

Conclusion

If Redis is used only as a cache, persistence may be unnecessary. However, when Redis stores critical business data, understanding and configuring the appropriate persistence strategy—RDB, AOF, or both—is essential for data safety.