Databases 13 min read

Mastering Redis Persistence: RDB vs AOF Explained

This article explores Redis's persistence mechanisms, detailing how RDB snapshots and AOF logs work, how to configure and trigger them, their advantages and drawbacks, and guidance on choosing the appropriate method for reliable data storage.

Efficient Ops
Efficient Ops
Efficient Ops
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

# Sync data to disk
> save

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

# Asynchronously save dataset to disk
> bgsave
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”:

# 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

Start Redis with the configuration file:

# Load configuration on startup
redis-server redis.conf

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:

# 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/

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.

# Example of many incremental commands
incr num 1
incr num 2
incr num 3
... 
incr num 100000

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

set num 100000

Rewrite Options

Control automatic rewriting with no-appendfsync-on-rewrite (default no). Manual rewrite can be triggered with:

# Asynchronously rewrite AOF
> bgrewriteaof

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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

databaseredisConfigurationPersistenceAOFRDB
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.