Understanding Redis Persistence Mechanisms: RDB and AOF

What is Redis Persistence?

Redis is an in‑memory key‑value store (NoSQL) that keeps all data in RAM. Because data resides only in memory, a server shutdown or a crash would cause all data to be lost unless persistence is enabled.

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 start to restore data.

Enabling RDB Persistence

Clients can trigger RDB generation with the save (synchronous) or bgsave (asynchronous) commands, 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 finished, which can cause noticeable latency for large datasets.

It is recommended not to use save in production when the data size is large.

2. bgsave command

# Asynchronously save the dataset to disk
> bgsave

bgsave forks a child process that writes the snapshot while the parent continues to serve requests. The fork operation itself is synchronous and may briefly block new connections.

3. Automatic triggers via configuration

In redis.conf you can specify conditions such as "save after N seconds if at least M write operations occurred":

# At least 1 write in 900 seconds
save 900 1
# At least 10 writes in 300 seconds
save 300 10
# At least 10000 writes in 60 seconds
save 60 10000

Start Redis with the configuration file:

redis-server redis.conf

RDB File Generation Process

Generate a temporary RDB file and write data into it.

Replace the existing RDB file with the temporary one once writing completes.

Delete the old file.

Typical configuration options:

# Enable compression
rdbcompression yes
# Set RDB filename
dbfilename redis-6379.rdb
# Set directory for RDB files
dir ~/redis/

Advantages of RDB

Fast recovery because the snapshot can be loaded quickly.

Compact file size, suitable for backups.

Minimal impact on server performance since a child process handles the I/O.

Disadvantages of RDB

Potential data loss between snapshots (e.g., if the server crashes before the next save).

The save command blocks the server.

Large forks for big datasets can consume significant memory and cause temporary blocking.

AOF (Append‑Only File)

AOF records every write operation received by the server. On restart, Redis replays the logged commands to rebuild the dataset.

Enabling AOF Persistence

In redis.conf enable AOF and configure its behavior:

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

Write Policies

appendfsync always   # Sync after every write (safest, slowest)
# appendfsync everysec   # Sync every second (default, may lose up to 1 s)
# appendfsync no          # Let OS decide when to sync (fastest, least safe)

1. always

Every write is flushed to disk immediately, providing maximum durability at the cost of performance.

2. everysec

The default policy; Redis syncs once per second, balancing safety and speed.

3. no

Redis relies on the operating system to flush data, offering the best performance but the weakest durability; not recommended for production.

AOF Rewrite

Because AOF grows continuously, Redis can rewrite it to a compact form that contains only the minimal set of commands needed to reconstruct the current dataset.

# Trigger asynchronous AOF rewrite
> bgrewriteaof

Benefits of rewrite:

Compresses the AOF file, reducing disk usage.

Creates a minimal command set, speeding up recovery.

Repairing a Corrupted AOF

If the server crashes while writing the AOF, the file may become malformed. Repair steps:

Back up the existing AOF file.

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

Restart Redis to load the repaired AOF.

Advantages of AOF

Append‑only logging has a lower impact on performance than RDB, provides finer‑grained durability, and typically consumes less memory.

Disadvantages of AOF

The log file can become very large, even after rewrite.

Recovery is slower compared to loading an RDB snapshot.

Choosing Between RDB and AOF

RDB offers fast recovery and compact backups but may lose recent data; AOF provides better durability but can be slower and larger. In many deployments both are enabled, with Redis preferring AOF for recovery because it contains more complete data.

Conclusion

If Redis is used only as a cache, persistence may be unnecessary. However, when Redis stores critical business data, understanding and configuring the appropriate persistence strategy (RDB, AOF, or both) is essential for data safety and system reliability.