Understanding 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 data is lost when the server shuts down or the Redis process exits.

When Redis is used only as a cache, occasional data loss may be acceptable, but when it stores critical business data, loss can be catastrophic. Therefore Redis provides persistence mechanisms to dump data to disk.

RDB (Redis Database Backup)

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

Enabling RDB

Clients can trigger snapshot generation with the SAVE (synchronous) or BGSAVE (asynchronous) commands, or by configuring save rules in redis.conf.

1. SAVE command

# Synchronously write data to disk
> save

The SAVE command blocks the server until the snapshot is finished, which can stall other clients.

For large datasets the blocking time may be long; avoid using SAVE in production.

2. BGSAVE command

BGSAVE

forks a child process to write the snapshot, allowing the parent to continue serving requests, although the fork operation itself can cause a brief pause.

# Asynchronously save the dataset to disk
> bgsave

3. Automatic triggers

In redis.conf you can set conditions such as “save 900 1” (snapshot if at least one write occurs within 900 seconds). When the condition is met Redis forks a child to generate the RDB file.

RDB file handling

Generate a temporary RDB file and write data.

Replace the old file with the new one.

Delete the previous file.

Typical configuration options include rdbcompression yes, dbfilename redis-6379.rdb, and dir ~/redis/.

RDB advantages

Fast recovery because it loads a compact snapshot.

Small file size, suitable for backups.

Minimal impact on server performance due to child‑process generation.

RDB disadvantages

Potential data loss between snapshots. SAVE blocks the server.

Large forks can consume memory and cause brief pauses.

AOF (Append‑Only File)

AOF records every write command received by the server and appends it to an .aof file. On restart Redis replays the file to rebuild the dataset.

Enabling AOF

Set appendonly yes in redis.conf and configure options such as appendfilename "appendonly.aof" and appendfsync (always, everysec, no).

Write strategies

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

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.

AOF rewriting

Because the AOF file can grow indefinitely, Redis can rewrite it to a minimal set of commands (e.g., SET num 100000). Triggered by the BGREWRITEAOF command, the rewrite runs in a child process.

Handling corrupted AOF

If the server crashes while writing the AOF, the file may become malformed. Repair it with redis-check-aof -fix file.aof and then restart Redis.

AOF advantages

Less impact on performance compared with RDB.

Faster writes; smaller memory overhead.

AOF disadvantages

File size 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 backups, while AOF provides higher durability. In many deployments both are enabled, but using both simultaneously increases I/O load, so the choice depends on the required balance between performance and data safety.

Conclusion

If Redis is used only as a cache, persistence can be ignored. When Redis stores business‑critical data, understanding and configuring the appropriate persistence method—RDB, AOF, or both—is essential to prevent data loss.