Mastering Redis Persistence: RDB vs AOF Explained

What Is Redis Persistence?

Redis is an in‑memory key‑value NoSQL database; all data resides in RAM, which means a server shutdown or daemon exit will cause data loss.

When Redis is used only as a cache, occasional data loss may be acceptable, but when it stores critical business data, persistence is essential.

RDB

RDB creates point‑in‑time snapshots of the dataset and saves them to a file (default dump.rdb). The file is loaded on server start to restore data.

Enabling RDB Persistence

Clients can trigger RDB generation with save (synchronous) or bgsave (asynchronous), or by configuring automatic triggers in redis.conf.

1. save Command

# Synchronously write data to disk
> save

The save command blocks other client requests until the snapshot is complete, so it is not recommended for production with large datasets.

2. bgsave Command

# Asynchronously write dataset to disk
> bgsave

bgsave

forks a child process to write the RDB file, allowing the main process to continue handling requests, though the fork itself can cause brief blocking.

3. Automatic Triggers via Configuration

In redis.conf, the save directive defines conditions such as "save after 900 seconds if at least 1 write command".

# Example triggers
save 900 1
save 300 10
save 60 10000

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

RDB File Generation Process

Create a temporary RDB file and write data.

Replace the old RDB file with the temporary one.

Delete the previous RDB file.

RDB Advantages

Fast recovery compared to AOF.

Compact file size, suitable for backups.

Minimal performance impact because a child process handles the write.

RDB Disadvantages

Potential data loss between snapshots if the server crashes. save blocks the server; bgsave can also block during a large fork.

Forked child consumes additional memory.

AOF (Append‑Only File)

AOF records every write operation received by the server, appending them to an .aof file. On restart, Redis replays the commands to rebuild the dataset.

Enabling AOF Persistence

Set appendonly yes in redis.conf and configure the write policy with appendfsync:

# Enable AOF
appendonly yes

# AOF filename
appendfilename "appendonly.aof"

# Write policy (always, everysec, or no)
appendfsync always

Write Policies

always : every write is flushed to disk – safest but slowest.

everysec : default; writes are flushed once per second – may lose up to 1 second of data.

no : OS decides when to flush – fastest but least safe; not recommended.

AOF File Rewrite

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

# Example of many incr commands
incr num 1
incr num 2
... 
incr num 100000

# After rewrite, only the final state is needed
set num 100000

Rewrite can be triggered automatically via no-appendfsync-on-rewrite or manually with bgrewriteaof:

# Manually trigger AOF rewrite
> bgrewriteaof

AOF Rewrite Benefits

Compresses the AOF file, reducing disk usage.

Creates a minimal command set, speeding up data recovery.

Handling Corrupted AOF Files

If the server crashes while writing the AOF, the file may become corrupted. Recover it by backing up the file and running redis-check-aof -fix, then restart Redis.

# Fix corrupted AOF
$ redis-check-aof -fix file.aof

AOF Advantages

Low performance impact, faster than RDB for writes, and consumes less memory.

AOF Disadvantages

The AOF file can become large even after rewrite.

Recovery is slower than RDB.

Choosing Between RDB and AOF

RDB offers fast recovery and compact backups but may lose recent data; AOF provides better durability with minimal data loss but larger files and slower recovery. In many cases, enabling both gives maximum safety, though the combined I/O load can affect performance.

Conclusion

If Redis is used solely as a cache, persistence can be ignored. However, when Redis stores business‑critical data, understanding and configuring the appropriate persistence strategy—RDB, AOF, or both—is essential for data safety and system reliability.