Redis Data Persistence: RDB and AOF

Analogy categoryAnalogies

Because Redis keeps its dataset in RAM, a process crash, server reboot, or redis-cli SHUTDOWN NOSAVE would normally wipe every key instantly. To avoid this, Redis offers two persistence mechanisms that can be used independently or together: RDB (Redis Database), which writes point-in-time binary snapshots of the whole dataset to disk, and AOF (Append Only File), which logs every write operation as it happens so the dataset can be reconstructed by replaying the log.

🏏

Cricket analogy: A team keeps both a full scorecard photo taken at the end of each session (a snapshot) and a ball-by-ball radio commentary transcript (a log), so the match can be reconstructed either from the last photo or replayed ball by ball — exactly like RDB and AOF.

RDB Snapshots

RDB persistence works by forking a child process that writes the entire dataset to a compact binary .rdb file, either on a schedule defined by save rules in redis.conf (e.g. save 900 1 means save if at least 1 key changed in 900 seconds) or on demand via the SAVE (blocking) or BGSAVE (non-blocking, forked) commands. RDB files are small and load fast on restart, making them ideal for backups and disaster recovery, but because snapshots only happen periodically, any writes since the last snapshot are lost if Redis crashes — a real risk for workloads that can't tolerate losing even a few minutes of data.

🏏

Cricket analogy: A ground's official photographer takes a team photo at the end of each session rather than continuously filming, so anything that happened in the final few minutes before a rain delay isn't captured in that day's photo — the same gap risk RDB has between snapshots.

ini

# redis.conf: save an RDB snapshot if at least 1 key changed in 900s,
# or at least 10 keys changed in 300s, or at least 10000 keys changed in 60s
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis

# AOF configuration
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec   # fsync policy: always | everysec | no

# Trigger snapshots/rewrites manually via redis-cli
redis-cli BGSAVE
redis-cli BGREWRITEAOF

AOF (Append Only File) and Choosing a Strategy

AOF persistence logs every write command to an append-only file as it executes, and Redis replays this log on startup to rebuild the dataset. The appendfsync setting controls durability versus performance: always fsyncs after every write (safest, slowest), everysec fsyncs once per second (the default, losing at most one second of writes on crash), and no lets the OS decide when to flush (fastest, least safe). Because the log would grow forever otherwise, Redis periodically runs BGREWRITEAOF to compact it into the minimal set of commands needed to reproduce the current dataset. Most production deployments enable both RDB and AOF together — RDB for fast, compact backups and quick restarts, AOF for minimal data loss — accepting the modest extra disk I/O and complexity as a reasonable trade-off for durability.

🏏

Cricket analogy: A stadium that keeps both a full ball-by-ball radio commentary archive (AOF, durable but verbose) and a condensed match highlights reel (RDB, compact and fast to review) gives fans both quick highlights and the full replay if needed.

Enabling appendfsync always guarantees the strongest durability but can reduce write throughput dramatically because every single write blocks on an fsync to disk; most teams use everysec as the practical default, accepting a worst-case one-second data loss window in exchange for far better performance.

RDB persistence writes periodic point-in-time binary snapshots (.rdb files) via SAVE or BGSAVE.
RDB is compact and fast to restore from, but can lose all writes since the last snapshot on a crash.
AOF persistence logs every write command to an append-only file and replays it on startup.
appendfsync controls the durability/performance trade-off: always, everysec (default), or no.
BGREWRITEAOF compacts the AOF log periodically to prevent unbounded growth.
Most production deployments enable both RDB and AOF together for fast restarts plus minimal data loss.
The choice between RDB, AOF, or both depends on how much data loss a workload can tolerate versus performance and complexity needs.