Redis Persistence - RDB vs AOF (High-level)

Redis can persist data to disk so it survives restarts. The two main mechanisms are RDB (snapshots) and AOF (append-only log of write commands). Each has tradeoffs between durability, performance, and recovery time. This article gives a high-level comparison and when to use which (or both).

Overview

• RDB: Periodically (or on demand) Redis creates a point-in-time snapshot of the dataset and writes it to a file (e.g. dump.rdb). Compact and fast to load; data between snapshots can be lost (e.g. last 5 minutes).
• AOF: Every write command is appended to a file. On restart, Redis replays the AOF to reconstruct state. Can be more durable (fsync every second or every write); file is usually larger and replay can be slower than loading RDB.
• Hybrid (RDB + AOF): Redis 4+ can use both: AOF is the main persistence; RDB is used as a base when rewriting AOF. Combines fast reload (RDB base) with incremental durability (AOF).

Example

Example 1: RDB configuration

ConfCopy
save 900 1    # after 900 s if at least 1 key changed
save 300 10   # after 300 s if at least 10 keys changed
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis

• RDB is written when one of the save rules is met. BGSAVE runs in a background process; the main thread keeps serving. Last snapshot to last shutdown = potential data loss window.

Example 2: AOF configuration

ConfCopy
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec   # fsync every second (default); or always / no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

• appendfsync everysec: at most ~1 s of writes can be lost. always: every write fsynced (durable, slower). no: OS decides (lowest durability, best throughput). Rewrite compacts AOF by replaying in memory and writing a new file.

Example 3: Recovery

• RDB only: Restart loads dump.rdb; data after last snapshot is lost.
• AOF only: Restart replays appendonly.aof; if AOF is corrupted, use redis-check-aof --fix to trim to last valid command.
• RDB + AOF: If both enabled, Redis prefers AOF on startup (AOF is considered more complete). Rewritten AOF can use RDB preamble for faster load.

Core Mechanism / Behavior

• RDB: Fork child; child writes snapshot; parent continues. Copy-on-write can cause memory spike under write load. Snapshot is a single file; easy to backup and restore.
• AOF: Append-only; rewrite merges old AOF into a compact form (or RDB preamble). Fsync policy trades durability for latency and throughput.
• Durability vs performance: Stronger durability (e.g. AOF with always) costs more disk I/O and latency; RDB or AOF everysec reduces cost but allows a small loss window.

Aspect	RDB	AOF
Format	Binary snapshot	Text (or RDB preamble when rewritten)
Durability	Up to last snapshot	Depends on fsync (everysec / always)
Restart load	Fast	Slower (replay); RDB preamble speeds it up
File size	Compact	Larger; rewrite compacts
Write cost	Periodic fork + write	Every write (and optional fsync)

Key Rules

• Use RDB when you accept losing the last few minutes of data and want fast restarts and simple backups. Use AOF when you need better durability (e.g. everysec or always).
• In production, many deployments use both: RDB for backups and fast base load; AOF for incremental durability. Enable AOF with appendonly yes and tune appendfsync and rewrite settings.
• Monitor fork time (RDB) and AOF rewrite; ensure disk has enough space and I/O for fsync. Test recovery (load RDB/AOF on a test instance) periodically.

What's Next

See Expiration Strategy for TTL (expired keys are not persisted in RDB). See Cache-Aside and Caching Pitfalls for how cache usage interacts with persistence (e.g. cache is often rebuildable from DB).