Mastering Redis Persistence: RDB vs AOF Explained

What is Redis Persistence?

Redis is an in‑memory key‑value store (NoSQL). Because all data lives in memory, it disappears when the server shuts down or the Redis daemon exits, making persistence essential for reliable data storage.

RDB

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

save

(synchronous) or

bgsave

(asynchronous), or by configuring automatic triggers in

redis.conf

.

1. save command

<code># Sync data to disk
> save
</code>

The

save

command blocks other client requests until the snapshot is finished, so it is not recommended for production with large datasets.

2. bgsave command

<code># Asynchronously save dataset to disk
> bgsave
</code>

bgsave

forks a child process to write the RDB file, allowing the main process to continue handling requests, though the fork operation can still cause brief blocking and extra memory usage.

3. Automatic triggers via configuration

In

redis.conf

you can specify conditions such as “at least one write in 900 seconds”:

<code># At least one write in 900 seconds
save 900 1
# At least ten writes in 300 seconds
save 300 10
# At least 10000 writes in 60 seconds
save 60 10000
</code>

Start Redis with the configuration file:

<code># Load configuration on startup
redis-server redis.conf
</code>

RDB File Lifecycle

Generate a temporary RDB file and write data.

Replace the old RDB file with the temporary one.

Delete the previous file.

RDB Advantages

Fast recovery compared with AOF.

Compact file size, suitable for backups.

Minimal impact on server performance because a child process does the write.

RDB Disadvantages

Potential data loss between snapshots if the server crashes.

save

blocks the server.

bgsave

may still block during the fork and consumes extra memory.

AOF (Append‑Only File)

AOF records every write command issued by clients and appends it to a log file. On restart, Redis replays the log to reconstruct the dataset.

Enabling AOF Persistence

Set

appendonly yes

in

redis.conf

and configure additional options:

<code># Enable AOF
appendonly yes

# AOF file name
appendfilename "appendonly.aof"

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

# Do not rewrite AOF by default
no-appendfsync-on-rewrite no

# Directory for persistence files
dir ~/redis/
</code>

Write Policies

always : Every write is flushed to disk immediately – safest but slowest.

everysec (default): Flushes once per second, risking up to 1 second of data loss.

no : Relies on the OS to flush, fastest but least safe.

AOF Rewrite

Because AOF continuously appends commands, the file can grow large. A rewrite creates a compact file containing only the minimal commands needed to rebuild the current state.

<code># Example of many incremental commands
incr num 1
incr num 2
incr num 3
... 
incr num 100000
</code>

After rewrite, the same state can be represented by a single command:

<code>set num 100000
</code>

Rewrite Options

Control automatic rewriting with

no-appendfsync-on-rewrite

(default

no

). Manual rewrite can be triggered with:

<code># Asynchronously rewrite AOF
> bgrewriteaof
</code>

Repairing a Corrupted AOF

Back up the current AOF file.

Run

redis-check-aof -fix file.aof

to repair it.

Restart Redis to load the repaired file.

AOF Advantages

Less impact on performance compared with RDB because writes are appended.

Provides higher durability; data loss is limited to the last second (default).

AOF Disadvantages

The log file can become very large even after rewrite.

Recovery is slower than loading an RDB snapshot.

Choosing Between RDB and AOF

RDB offers fast recovery and compact storage, while AOF provides better durability at the cost of larger files and slower reload. In many deployments both can be enabled, but simultaneous I/O may affect performance, so select the method that matches your reliability and speed requirements.

Summary

If Redis is used only as a cache, persistence may be unnecessary. However, when Redis stores critical business data, understanding and configuring RDB and AOF correctly is essential for data safety.