Redis Persistence Explained: RDB vs AOF and How to Choose the Right Strategy

Redis Persistence Overview

To achieve high availability, Redis relies on data persistence, master‑slave replication, automatic failover, and clustering. Persistence also serves as a backup mechanism to protect data integrity when an instance crashes.

Persistence Mechanisms

Data persistence

Master‑slave replication

Automatic failover

Clustering

RDB (Redis Database Backup)

What is RDB

RDB stands for Redis Database Backup file, a snapshot of the entire dataset.

Generate an RDB file with the save command (foreground) or the bgsave command (background). The background version uses the operating‑system fork system call and copy‑on‑write to avoid blocking client requests.

Advantages

RDB files are compressed, making them smaller than the in‑memory dataset.

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

Disadvantages

RDB captures the state at a single point in time, so recent writes may be missing.

Creating an RDB file consumes significant CPU and memory resources.

Typical Use Cases

Full data sync for master‑slave replication.

Periodic database backups.

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

Configuring Periodic RDB Generation

Redis provides configuration options to trigger RDB generation automatically (see image).

AOF (Append‑Only File)

What is AOF

AOF stands for Append Only File . It records every write command with full arguments, appending them to a log file in real time.

Sync Strategies

appendfsync always

: flush to disk after every write – highest data safety, highest I/O cost. appendfsync everysec: flush once per second – balances performance and safety, at most one second of data loss. appendfsync no: rely on the operating system’s flush policy – lowest overhead, lowest safety.

Pros and Cons

Pros: AOF provides more up‑to‑date data, reducing loss risk during recovery. Cons: The AOF file grows over time, and frequent flushing increases disk I/O and can degrade write performance. AOF rewrite (compact) reduces file size but consumes CPU.

AOF Rewrite

When the AOF file becomes large, Redis can automatically rewrite it to a smaller, compact version. This process scans the dataset and creates a new AOF file, consuming CPU resources.

Performance Impact

If appendfsync always is used, write throughput drops sharply because each command must be flushed to disk. The everysec mode is commonly chosen to maintain good performance while limiting potential data loss to one second.

Choosing Between RDB and AOF

RDB is ideal for backups and scenarios where occasional data loss is tolerable, such as full‑sync replication. AOF suits data‑sensitive workloads (e.g., financial transactions) where minimizing data loss is critical. Using both together can provide both safety and performance.

Summary Table