Mastering Redis Persistence: RDB vs AOF Explained

What is Redis Persistence?

Redis is an in‑memory key‑value NoSQL database; all data resides in memory, which means a server shutdown or daemon exit would 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 becomes essential.

RDB

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

Enabling RDB Persistence

Clients can trigger RDB generation with save (synchronous) or bgsave (asynchronous), 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 with large datasets.

2. bgsave command

# Asynchronous background save
> bgsave

bgsave

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

3. Automatic triggers via configuration

In redis.conf you can specify conditions such as "save 900 1" (at least one write in 900 seconds) to trigger RDB creation.

# Example triggers
save 900 1
save 300 10
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 files suitable for backups.

Minimal performance impact because a child process performs the write.

Disadvantages of RDB

Potential data loss between snapshots. save blocks the server.

Large forks during bgsave can cause temporary blocking and high memory usage.

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:

# Enable AOF
appendonly yes

# File name
appendfilename "appendonly.aof"

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

Write Policies

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

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

no : OS handles flushing – fastest but least safe.

AOF Rewrite

Because AOF grows continuously, Redis can rewrite it to a compact form containing only the minimal commands needed to reconstruct the current state.

# Example rewrite output
set num 100000

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

Triggering Rewrite

Configure no-appendfsync-on-rewrite in redis.conf or issue the bgrewriteaof command.

# Asynchronously rewrite AOF
> bgrewriteaof

Benefits of Rewrite

Compresses the AOF file, saving disk space.

Reduces recovery time by keeping only essential commands.

Repairing a Corrupted AOF

If Redis crashes while writing the AOF, the file may become malformed. 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.

Pros and Cons of AOF

Pros: Lower performance impact than RDB, more durable because every write is logged.

Cons: AOF files can become large; 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 at the cost of larger files and slower recovery. In many deployments both are enabled, with Redis preferring AOF for recovery, though simultaneous I/O can affect performance.

Summary

If Redis is used solely as a cache, persistence can be ignored. However, when Redis stores business‑critical data, understanding and configuring RDB and AOF correctly is essential to balance data safety and performance.