Mastering Redis Persistence: RDB vs AOF Explained

In this article we continue learning about Redis by exploring its persistence mechanisms.

What is Redis persistence?

Redis is an in‑memory key‑value NoSQL database; data resides in memory and would be lost if the server shuts down, so persistence is needed to save data to disk.

Redis offers two persistence methods: RDB (snapshot) and AOF (append‑only file).

RDB

RDB creates point‑in‑time snapshots saved as dump.rdb and loads them on startup.

Enabling RDB

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

save command

# Synchronously save data to disk
> save

Using save in production can block the server if the dataset is large.

bgsave command

# Asynchronously save data to disk
> bgsave

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

Automatic triggers

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

These settings are placed in redis.conf and loaded when the server starts.

RDB file creation

Generate a temporary RDB file and write data.

Replace the old RDB file with the temporary one.

Delete the previous file.

Configuration options such as rdbcompression, dbfilename, and dir control compression, filename, and storage directory.

Advantages of RDB

Fast recovery.

Compact files suitable for backups.

Minimal performance impact due to child‑process generation.

Disadvantages of RDB

Potential data loss between snapshots. save blocks the server.

Large datasets can cause blocking and high memory usage during fork.

AOF

AOF logs every write command to an append‑only file, which is replayed on restart to reconstruct the dataset.

Enabling AOF

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

Write policies

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

everysec : default; writes are flushed every second – up to 1 s of data loss.

no : OS handles flushing – fastest but unsafe.

AOF rewrite

Since AOF can grow large, Redis can rewrite it to a minimal set of commands.

# Example of rewrite to a single command
set num 100000

AOF is a binary format; the example shows a simplified representation.

Rewrite triggers

Controlled by no-appendfsync-on-rewrite and the bgrewriteaof command.

Benefits of rewrite

Compresses the file, reducing disk usage.

Speeds up data recovery.

Repairing a corrupted AOF

Backup the current AOF file.

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

Restart Redis to load the repaired file.

Advantages of AOF

Lower performance impact than RDB.

Faster writes.

Disadvantages of AOF

File size can become large even after rewrite.

Recovery is slower than RDB.

Choosing between RDB and AOF

Both can be enabled for maximum safety, but simultaneous I/O may affect performance; choose based on data loss tolerance and speed requirements.

Summary

If Redis is used only as a cache, persistence may be unnecessary, but when it stores business data, understanding and configuring RDB and AOF is essential.