Redis Persistence Mechanisms: RDB Snapshots and AOF Append‑Only Files

Redis Persistence Overview

Redis stores all data in memory, so a sudden crash would lose everything; therefore Redis provides persistence mechanisms to protect data from failure.

Two Persistence Methods

Redis supports two ways to persist data: snapshot files ( RDB ) and an append‑only log ( AOF ).

RDB (Redis DataBase) Snapshots

What it is : At configured intervals Redis forks a child process that writes the entire in‑memory dataset to a temporary file, then replaces the previous dump.rdb file. The parent process continues serving clients without I/O, giving high performance.

Configuration : The default snapshot rule is save 60 1000 (save if at least 1000 keys change within 60 seconds). Manual snapshots can be triggered with SAVE (blocking) or BGSAVE (background, non‑blocking). To disable snapshots: redis-cli config set save "" .

Recovery : Copy the dump.rdb file to the Redis data directory and start the server (or use CONFIG GET dir to locate the directory).

Advantages :

The dataset is a single compact file, easy to back up and restore, especially for large‑scale recovery.

Minimal impact on the main process because persistence is done by a forked child.

Faster startup for large datasets compared with AOF.

Disadvantages :

Data created after the last snapshot can be lost if a crash occurs.

Forking a child duplicates memory, potentially causing a pause of several hundred milliseconds to a second for very large datasets.

AOF (Append‑Only File) Logging

What it is : Every write command is appended to appendonly.aof . On restart Redis replays the log to rebuild the dataset. The file is write‑only; reads are not logged.

Configuration : Enable with appendonly yes (default is no ) and set the persistence directory via APPEND ONLY MODE . The AOF can be rewritten to a compact form using bgrewriteaof .

Startup / Repair / Recovery :

Normal recovery: enable AOF, copy the AOF file to the data directory, restart Redis.

Corrupted AOF: create a backup, run redis-check-aof --fix , optionally compare with diff -u , then restart.

Rewrite Mechanism : When the AOF grows beyond a threshold (default >64 MB and twice the size after the last rewrite), Redis forks a child that writes a new compact AOF containing only the minimal set of commands needed to reconstruct the current dataset. The parent continues appending new writes to the old file; once the child finishes, the new file replaces the old one atomically.

fsync Options (how often data is flushed to disk):

Every write (very safe, very slow).

Every second (default; balances speed and safety, loses at most one second of data).

Never (fastest, least safe).

Advantages :

Higher data durability; three sync strategies (every write, every second, never).

Append‑only writes protect existing data from corruption during crashes.

Automatic rewrite keeps the file size manageable.

The log is human‑readable and easy to parse or edit for manual recovery.

Disadvantages :

AOF files are typically larger than RDB files and slower to load.

Depending on the sync policy, write performance can be lower than RDB.

Switching Between RDB and AOF

From Redis 2.2 onward you can enable AOF without restarting:

redis-cli> CONFIG SET appendonly yes

redis-cli> CONFIG SET save ""

After enabling, ensure the key count remains unchanged and that new write commands are appended to the AOF.

Choosing the Right Strategy

• Use RDB snapshots on slaves for periodic backups (e.g., every 15 minutes) when fast restart is needed. • Enable AOF for near‑real‑time durability (max 1 second data loss) but be aware of continuous I/O and occasional rewrite pauses. • For maximum availability, run both; on restart Redis prefers AOF because it contains a more complete dataset.

Performance Recommendations

Keep the AOF rewrite threshold high (e.g., >5 GB) if disk space permits.

Consider disabling AOF if I/O overhead is unacceptable and you can tolerate a few minutes of data loss using master‑slave replication.

Overall, RDB offers compact backups and fast restarts, while AOF provides stronger durability; the best choice depends on your workload and recovery requirements.