Redis Data Persistence: AOF and RDB Mechanisms Explained

Redis Data Persistence

Redis stores data in memory, so a power loss would erase all information; persistence mechanisms are therefore required to avoid data loss.

Redis provides two main persistence strategies: RDB snapshots and AOF (Append‑Only File) logging.

AOF Persistence

What is AOF?

AOF records every write command executed by the server, allowing the database state to be reconstructed by replaying the logged commands.

Why log after execution?

1. Logging after execution ensures only successful commands are persisted, preventing erroneous commands from being recorded.

2. Because logging occurs after the command, it does not block the current write operation.

Potential Risks

If the server crashes after a command succeeds but before the log is written, that command is lost.

Heavy disk I/O can slow AOF writes, affecting overall performance.

These issues can be mitigated by adjusting the timing of AOF writes to disk.

AOF Write and Sync Strategies

The AOF persistence workflow consists of three steps: append, write, and sync. The appendfsync setting controls when data is flushed to disk:

always : sync after every write command.

everysec : sync once per second.

no : let the operating system decide when to flush.

AOF Rewrite Mechanism

Because every command is appended, the AOF file can grow large. Redis solves this by rewriting the AOF: it creates a new file that contains only the minimal set of commands needed to reconstruct the current state.

Example of rewrite output:

192.168.56.118:6379> set name "xiaoming"
OK
192.168.56.118:6379> get name
"xiaoming"
# After several updates
192.168.56.118:6379> set name "xiaoli"
OK
# Rewritten AOF contains only the final command
192.168.56.118:6379> set name "xiaoli"

The rewrite runs in a child process, so the main thread continues serving client requests without blocking.

Data Recovery with AOF

On restart, Redis reads the AOF file and re‑executes each command, fully restoring the database to its pre‑shutdown state.

RDB Persistence

What is RDB?

RDB creates point‑in‑time snapshots of the in‑memory dataset and writes them to disk as a binary file.

How Snapshots Are Made

Two commands are available:

save : performed in the main thread (blocks other operations).

bgsave : forks a child process to write the snapshot, avoiding blocking the main thread.

Configuration example (from redis.conf )

# Save the DB on disk:
#   save 900 1   # after 900 sec if at least 1 key changed
#   save 300 10  # after 300 sec if at least 10 keys changed
#   save 60 10000 # after 60 sec if at least 10000 keys changed

Snapshot Consistency and Copy‑On‑Write

During a snapshot, the child process shares the parent’s memory. If the parent modifies data, the changed pages are copied (Copy‑On‑Write), allowing writes to continue while the snapshot is being written.

How Often to Snapshot

Too frequent snapshots increase disk I/O; too infrequent snapshots risk larger data loss windows. The optimal interval depends on workload and tolerance for data loss.

Expiration of Keys

Expired keys are omitted from RDB files. When loading an RDB, a master server discards expired keys, while a replica loads all keys and relies on later synchronization to handle expirations.

For AOF, expired keys are not immediately removed; a DEL command is appended only when the key is actually deleted. During AOF rewrite, expired keys are omitted from the new file.

Summary

AOF : Flexible durability with configurable sync policies; larger file size and slower recovery compared to RDB.

RDB : Fast recovery via binary snapshots; requires careful tuning of snapshot frequency to balance performance and data loss risk.

Redis 4.0 introduces a hybrid approach that combines periodic RDB snapshots with continuous AOF logging, offering a balanced solution for data safety and performance.