Understanding Redis Persistence: RDB Snapshots and AOF Append‑Only Logs

Starting this series, we introduce the mechanisms that make Redis highly available. High availability relies on data persistence, master‑slave replication, automatic failover, and clustering. This article focuses on the persistence layer, which is essential for data safety and backup.

Persistence Methods

Redis offers two main persistence approaches:

RDB – creates a point‑in‑time snapshot file.

AOF – appends every write command to a log file.

Each method fits different scenarios, which we will examine in detail.

RDB

RDB stands for Redis Database Backup file, also known as a Redis snapshot. You can trigger a snapshot with the SAVE or BGSAVE commands, producing a file that contains a near‑complete copy of the dataset.

Advantages:

The snapshot is compressed, so the file size is smaller than the in‑memory data.

Loading an RDB file after a crash is fast, enabling rapid recovery.

Disadvantages:

It captures data only at a specific moment, so recent writes may be missing.

Generating the file consumes significant CPU and memory resources.

Typical use cases:

Full data synchronization between master and slave.

Database backups.

Scenarios where occasional data loss is acceptable and fast recovery is needed.

Periodic RDB Generation

Redis can automatically create RDB files based on write activity thresholds:

# If at least 1 write occurs within the last 15 minutes
save 900 1
# If at least 10 writes occur within the last 5 minutes
save 300 10
# If at least 10000 writes occur within the last 1 minute
save 60 10000

When any condition is met, Redis generates a new snapshot, reducing the gap between the file and the live dataset.

Copy‑On‑Write (COW)

Both SAVE and BGSAVE can create RDB files, but SAVE runs in the foreground and blocks the server. BGSAVE forks a child process that writes the snapshot while the parent continues to serve clients.

The fork system call creates a child that shares the parent’s memory pages. As the parent writes new data, the operating system copies only the modified pages (COW), which means the snapshot process can work without blocking reads, but the fork operation itself can be CPU‑ and memory‑intensive.

AOF

AOF stands for Append Only File. Unlike RDB, AOF records every write command with its arguments, appending them to a log in real time.

To enable AOF, add the following to redis.conf:

# Enable AOF
appendonly yes

# AOF file name
appendfilename "appendonly.aof"

# Sync policy
appendfsync everysec

Sync Options

Redis offers three fsync policies:

appendfsync always – sync to disk after every write (highest durability, lowest performance).

appendfsync everysec – sync once per second (good balance, up to 1 second of data loss).

appendfsync no – let the OS decide (best performance, lowest durability).

AOF provides more up‑to‑date data than RDB, making recovery more complete. When both files exist, Redis prefers AOF for restoration.

AOF Rewrite

Because the AOF file grows continuously, Redis can rewrite it to a compact form when it becomes large. The rewrite process also consumes CPU.

# Trigger rewrite when file growth exceeds 100% of the previous size
auto-aof-rewrite-percentage 100
# Minimum size (in MB) to consider rewriting
auto-aof-rewrite-min-size 64mb

AOF is ideal for workloads that cannot tolerate data loss, such as financial transactions.

Performance Impact

If appendfsync always is used, write throughput drops dramatically due to disk I/O. In practice, most deployments choose appendfsync everysec, which offers acceptable performance while limiting potential data loss to one second.

Conclusion

Choosing between RDB and AOF depends on business requirements. RDB is suitable for backups and fast recovery when occasional data loss is acceptable; AOF provides near‑real‑time durability at the cost of larger files and higher I/O. Combining both gives the best of safety and performance.