Redis Persistence: RDB vs AOF

Introduction¶

Redis holds data in RAM. Persistence controls what survives a restart or crash. There are two mechanisms and they're not mutually exclusive.

RDB — snapshots¶

A point-in-time binary dump of the whole dataset, written to dump.rdb.

# redis.conf
save 900 1        # snapshot if >=1 key changed in 900s
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis
rdb-del-sync-files no

• How: Redis fork()s; the child writes the snapshot from the copy-on-write memory image while the parent keeps serving.
• Pros: compact, fast to load on restart, low runtime overhead, great for backups (copy the file).
• Cons: you lose everything since the last snapshot on a crash (could be minutes). The fork can cause a latency blip and, worst case, a large memory spike (see below).

AOF — append-only file¶

Every write command is appended to a log. On restart, Redis replays it.

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec      # fsync once a second (default) — lose <=1s on crash
# appendfsync always      # fsync every write — safest, slowest
# appendfsync no          # let the OS decide — fastest, least safe
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

• appendfsync everysec — the sane default. At most ~1 second of writes lost.
• always — durable per-write, but throughput drops hard.
• AOF rewrite — the log grows forever, so Redis periodically rewrites it to the shortest set of commands that recreate the current dataset (also via fork).

Redis 7+ uses a multi-part AOF: a base (RDB-format) file plus incremental AOF files in an appendonlydir/.

Run both¶

The common production choice:

save 900 1
save 300 100
appendonly yes
appendfsync everysec

On restart Redis loads the AOF (more complete). RDB still gives you a fast, compact artifact for offsite backups. Best of both: bounded data loss (~1s) and easy backups.

The fork / copy-on-write memory spike¶

Both RDB save and AOF rewrite fork(). The child shares the parent's memory pages copy-on-write. If the parent is taking heavy writes during the save, many pages get copied and Redis's RSS can approach 2× the dataset size briefly.

Mitigations:

• Keep maxmemory well below physical RAM (leave headroom for the fork).
• vm.overcommit_memory = 1 (sysctl) so fork() doesn't fail under pressure — Redis logs a warning at startup if this isn't set.
• Disable Transparent Huge Pages (madvise or never) — THP makes COW copy 2 MB at a time, hugely inflating the spike and latency.
• On cloud/replica setups, run saves on a replica, not the primary.

Choosing per use case¶

Verification and troubleshooting¶

redis-cli INFO persistence
# rdb_last_save_time, rdb_last_bgsave_status, rdb_changes_since_last_save
# aof_enabled, aof_last_rewrite_time_sec, aof_last_bgrewrite_status, aof_rewrite_in_progress
redis-cli LASTSAVE
redis-cli BGSAVE
redis-cli BGREWRITEAOF

• rdb_last_bgsave_status: err — the fork failed (out of memory / overcommit), disk full, or no write permission on dir. Check the Redis log.
• Restart lost recent data — RDB only, and the crash was after the last save window. Enable AOF.
• Restart is slow — large AOF replay. Trigger a rewrite so the base file does most of the work; or accept it (it's a one-time cost).
• Latency spikes every few minutes — the save/rewrite fork, made worse by THP. Disable THP, move saves to a replica, lower write rate during saves.
• MISCONF Redis is configured to save RDB snapshots, but ... last bgsave error — Redis is refusing writes because it can't persist. Fix the disk / permissions / memory, or (cache-only) set stop-writes-on-bgsave-error no.
• AOF corrupted after an unclean shutdown — redis-check-aof --fix appendonly.aof truncates the last partial command. You lose that one write.
• Disk filling — AOF between rewrites, or old RDB files. Tune auto-aof-rewrite-*; don't delete the live AOF.

Related tools and reading¶

• On-site: Timestamp converter.
• Related posts: Redis as a cache: eviction policies, cgroups v2 basics.