Redis Persistence: RDB vs AOF Configuration

Redis persistence is a durability decision, not a checkbox: RDB snapshots are compact and fast to load but lose everything since the last snapshot, while AOF replays every write but costs I/O and disk. Most production deployments run both, tuned so that the hybrid format gives fast restarts with a small exposure window. This guide explains the mechanics, shows a configuration that works, and lists the failure semantics you should know before the VM loses power.

RDB snapshots

# redis.conf
save 900 1        # snapshot if 1 key changed in 15 minutes
save 300 10       # snapshot if 10 keys changed in 5 minutes
save 60 10000     # snapshot if 10000 keys changed in 1 minute
dbfilename dump.rdb
dir /var/lib/redis
stop-writes-on-bgsave-error yes

Each line is "snapshot if at least changes keys changed in seconds". Redis forks a child to write the file while the parent keeps serving traffic, using copy-on-write: memory can temporarily roughly double on a write-heavy dataset, which is why an RDB-only configuration on a big instance can surprise you with an OOM kill at exactly the wrong moment.

AOF

appendonly yes
appendfilename "appendonly.aof"
appenddirname "appendonlydir"      # Redis 7 multipart layout
appendfsync everysec               # always | everysec | no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes

• appendfsync always – fsync on every write: strongest durability, but adds millisecond latency to each operation and kills throughput on a busy master.
• appendfsync everysec – the honest default: at most about one second of writes lost on a crash, negligible performance cost.
• appendfsync no – the OS decides; fastest, lose arbitrary amounts on a crash.
• aof-use-rdb-preamble yes – since Redis 4/7 the AOF may start with an RDB section followed by incremental commands, giving fast load plus AOF durability.
• stop-writes-on-bgsave-error yes (default) – correct behaviour: pause writes rather than silently losing snapshots when the disk fills.

What actually happens on restart

Redis loads the AOF when appendonly yes, otherwise the RDB. A truncated AOF from an unclean shutdown is either loaded up to the truncation point (aof-load-truncated yes) or refuses to start, and you may need redis-check-aof --fix. Data restored from a base RDB inside the AOF plus the trailing commands equals the state at the last successful fsync.

Verify persistence rather than assume it

redis-cli INFO persistence | grep -E "rdb_last_bgsave_status|rdb_last_save_time|aof_enabled|aof_last_bgrewrite_status|aof_last_write_status"
redis-cli BGSAVE
redis-cli LASTSAVE
redis-cli BGREWRITEAOF
redis-cli CONFIG GET appendfsync

rdb_last_bgsave_status:err or aof_last_write_status:err is a data-loss countdown, not a warning – both belong in monitoring with high severity.

Operating practice

• Ship RDB files (and AOF where required) off-host to object storage with restic/rclone; a snapshot on the same disk as the data survives exactly nothing.
• Do not run CONFIG SET changes without CONFIG REWRITE, or they disappear at the next restart.
• Size memory with the fork in mind: leave headroom for a full copy-on-write during BGSAVE.
• Test recovery on a copy – persistence that has never been restored is a hypothesis.
• For cache workloads with a rebuildable dataset, disabling persistence entirely is a legitimate choice; document it so nobody mistakes it for an oversight.

Related: Linux iSCSI targets, RAID levels and the write hole, and smartctl disk health monitoring.

原文链接：https://stackharbor.com/en/knowledge-base/redis-persistence-rdb-vs-aof-tradeoffs