Mastering Redis Persistence: RDB vs AOF Explained

What Is Redis Persistence?

Redis is an in‑memory key‑value store; data lives in RAM and would be lost if the server shuts down or the Redis process exits.

To prevent data loss, Redis offers persistence options that write data to disk.

RDB (Redis Database)

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

Enabling RDB

Use the save or bgsave commands, or configure automatic triggers in redis.conf.

1. save command

# Synchronous save to disk
> save

Because save blocks the server, it is not recommended for production workloads.

2. bgsave command

# Asynchronous save to disk
> bgsave

bgsave

forks a child process to write the snapshot, allowing the main process to continue handling requests, though the fork itself briefly blocks new commands.

3. Automatic triggers

Configure save rules in redis.conf, e.g.:

# Save after 900 seconds if at least 1 write
save 900 1
# Save after 300 seconds if at least 10 writes
save 300 10
# Save after 60 seconds if at least 10000 writes
save 60 10000

RDB File Generation Process

Create a temporary RDB file and write data.

Replace the old RDB file with the temporary one.

Delete the previous file.

Advantages of RDB

Fast recovery compared to AOF.

Compact file size, suitable for backups.

Minimal impact on server performance because the write is done in a child process.

Disadvantages of RDB

Potential data loss for the interval between snapshots. save blocks the server; bgsave can still cause brief pauses and uses extra memory.

AOF (Append‑Only File)

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

Enabling AOF

Set appendonly yes in

redis.conf</b> and configure options such as <code>appendfsync

:

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

Write Policies

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

everysec : default; syncs once per second, risking up to 1 second of data loss.

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

AOF Rewrite

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

# Example of rewrite output
set num 100000

The actual AOF file uses Redis's internal binary format; the example is simplified for illustration.

Triggering Rewrite

Configure no-appendfsync-on-rewrite or manually run bgrewriteaof:

# Asynchronously rewrite AOF
> bgrewriteaof

Advantages of AOF

Lower performance impact than RDB during normal operation.

More durable – can recover up to the last synced command.

Disadvantages of AOF

Log files can become large even after rewrite.

Recovery is slower than loading an RDB snapshot.

Choosing Between RDB and AOF

RDB offers fast recovery and compact files, while AOF provides better durability at the cost of larger files and slower restores. In many deployments both can be enabled, but simultaneous I/O may affect performance, so choose based on data safety requirements and workload characteristics.

Conclusion

If Redis is used only as a cache, persistence can be ignored. When Redis stores critical business data, understanding and configuring RDB and AOF correctly is essential for reliable operation.