Mastering Redis Persistence: RDB vs AOF Explained

RDB Persistence

RDB (Redis Database) is the default snapshotting mechanism. It writes the in‑memory dataset to a dump.rdb file at configured intervals, allowing recovery after restarts or crashes.

Configuration

The save directive defines snapshot conditions. Multiple rules can be set, for example:

save 900 1   // at least 1 change within 900 seconds
save 300 10  // at least 10 changes within 300 seconds
save 60 10000 // at least 10000 changes within 60 seconds

To disable RDB, comment out all save lines or set save "". Other relevant options: stop-writes-on-bgsave-error yes – stops writes if a background save fails. rdbcompression yes – compresses the snapshot with LZF (default). Disable to save CPU at the cost of larger files. rdbchecksum yes – adds a CRC64 checksum (≈10% overhead). dbfilename dump.rdb – name of the snapshot file. dir ./ – directory where the snapshot is stored.

Theory

When a snapshot is triggered, Redis forks a child process. The child writes the dataset to a temporary RDB file; the parent then atomically replaces the old dump.rdb with the new one, leveraging copy‑on‑write to avoid blocking the main process.

How to Trigger Snapshots

Default save rules in the configuration file.

Manual SAVE (blocking) or BGSAVE (asynchronous) commands.

Running FLUSHALL or SHUTDOWN (generally not recommended for snapshots).

Restoring from RDB

Copy the dump.rdb file to the Redis working directory (or the directory specified by dir) and restart the server; the file is automatically loaded.

Pros and Cons

Pros : Compact file, fast backup, easy transfer to remote storage, minimal impact on the main process.

Cons : Potential data loss of a few minutes on crash; fork overhead can block the server for large datasets.

AOF Persistence

AOF (Append‑Only File) logs every write operation. It is disabled by default; enable it with appendonly yes. The log can be replayed on restart to reconstruct the dataset.

Configuration

appendonly no

– default; set to yes to enable. appendfilename "appendonly.aof" – name of the AOF file. appendfsync – sync strategy:

appendfsync always   // every write is flushed (slow, safest)
appendfsync everysec // default, flush once per second (good trade‑off)
appendfsync no       // never explicitly flush (fast, riskier)

no-appendfsync-on-rewrite yes

– disables fsync during AOF rewrite to avoid blocking, at the risk of losing up to 30 seconds of data. auto-aof-rewrite-percentage 100 and auto-aof-rewrite-min-size 64mb – control automatic AOF rewrite triggers. aof-load-truncated yes – loads a truncated AOF with a warning; no aborts startup. aof-use-rdb-preamble yes – prefixes AOF with an RDB snapshot for faster rewrite and recovery.

Rewrite Mechanism

During a rewrite, Redis forks a child that creates a new compact AOF file. The parent continues to append new commands to the old file; once the child finishes, the parent appends the buffered commands to the new file and atomically replaces the old AOF.

Repairing a Corrupted AOF

Backup the existing appendonly.aof.

Run redis-check-aof --fix appendonly.aof to fix syntax errors.

Optionally compare the fixed file with the backup using diff -u.

Restart Redis to load the repaired AOF.

Pros and Cons

Pros : Near‑real‑time durability (max 1 second loss), log is human‑readable, automatic safe rewrite, higher data integrity.

Cons : Larger file size than RDB, potentially slower writes depending on appendfsync policy.

Comparison and Recommendations

For PostgreSQL‑level safety, enable both RDB and AOF. If occasional minute‑scale data loss is acceptable, RDB alone may suffice. AOF offers better real‑time durability and is the mainstream choice; combining both gives fast snapshot restores and continuous logging.

When both are enabled, Redis prefers AOF on startup because it usually contains the most complete data.

Backup Strategies

Schedule hourly cron jobs to copy RDB files to a backup directory and daily copies to an off‑site location.

Include timestamps in filenames and prune old snapshots with find.

For high availability without AOF, rely on master‑slave replication and periodic RDB backups.

Performance Tips

Persist RDB only on slaves with a simple save 900 1 rule if disk I/O is a concern. Enabling AOF adds continuous I/O overhead but limits data loss to a few seconds. Adjust auto-aof-rewrite-min-size (e.g., 5gb) to reduce rewrite frequency on large datasets.