Two Persistence Mechanisms
Redis offers two distinct persistence mechanisms that can be used independently or together. RDB (Redis Database) takes point-in-time snapshots of the entire dataset at configured intervals or on demand, producing a single compact binary file that's fast to load on restart. AOF (Append Only File) instead logs every write command as it happens, giving much finer-grained durability at the cost of a larger file and slower restarts, since Redis must replay the whole log (or an AOF-rewritten compact version) to rebuild state. Neither is strictly better — they trade off recovery point objective against recovery time and runtime overhead differently.
Cricket analogy: It's like the difference between a full scorecard photo taken at the end of every over (RDB) versus a ball-by-ball commentary log (AOF) — the photo is quick to review later, but the commentary lets you reconstruct exactly what happened on any single ball.
AOF Fsync Policies
AOF's durability is governed by appendfsync, which controls how often the log is flushed from the OS buffer to disk. always fsyncs on every write, giving the strongest durability but the worst throughput since every command pays a disk round trip. everysec (the default) fsyncs once per second in a background thread, bounding potential data loss to roughly one second of writes while keeping throughput close to no-fsync levels. no disables explicit fsyncing and lets the OS decide when to flush, which can lose much more data on a crash but avoids fsync overhead entirely — generally discouraged except for specific throughput-critical, loss-tolerant workloads.
Cricket analogy: It's like a scorer who updates the official paper scorebook after every single ball (always, safest but slowest), once at the end of each over (everysec, a good balance), or only at the end of the innings from memory (no, risky if he forgets details).
Configuring Both RDB and AOF
# redis.conf
# RDB: snapshot if >= 1 change in 900s, >=10 in 300s, >=10000 in 60s
save 900 1
save 300 10
save 60 10000
# AOF
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
# Trigger AOF rewrite when the file grows 100% past its base size
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mbRecovery Behavior and Combining Both
When both RDB and AOF are enabled, Redis uses AOF for recovery on restart because it's more current, only falling back to the RDB file if AOF is disabled or missing. Since Redis 7, AOF uses a multi-part format (base file + incremental files + manifest) so the periodic rewrite that compacts the log doesn't require holding the entire old and new AOF in memory at once. A common production pattern is running both: RDB snapshots for fast, portable backups (easy to copy to another region or load into a fresh instance quickly) and AOF with everysec for tight recovery-point guarantees during a crash.
Cricket analogy: It's like a team keeping both a quick highlights reel (RDB, fast to review and share) and the full ball-by-ball archive (AOF, detailed enough to reconstruct any disputed moment) — you use whichever fits the situation.
RDB alone can lose everything written since the last successful snapshot — potentially minutes of data on a busy instance — because it's inherently point-in-time. If your workload can't tolerate that loss window, enable AOF (at least everysec) rather than relying on RDB alone.
Both RDB snapshotting (via fork) and AOF rewriting momentarily double memory usage in the worst case, since the child process shares pages with the parent under copy-on-write but diverges as writes continue — size your instance's available memory with this headroom in mind.
- RDB creates compact point-in-time snapshots; AOF logs every write for finer-grained durability.
- appendfsync controls AOF durability: always (safest, slowest), everysec (default, ~1s loss window), no (fastest, riskiest).
- On restart with both enabled, Redis recovers from AOF since it's more current than the last RDB snapshot.
- Redis 7+ AOF uses a multi-part format (base + incremental + manifest) to make rewrites more memory-efficient.
- A common production setup combines RDB (fast portable backups) with AOF everysec (tight recovery point).
- Both RDB fork-based snapshotting and AOF rewrite can transiently increase memory usage via copy-on-write.
- RDB alone risks losing all writes since the last snapshot; that gap is the key argument for enabling AOF.
Practice what you learned
1. What is the fundamental difference between RDB and AOF persistence?
2. What does appendfsync everysec do?
3. If both RDB and AOF are enabled, which does Redis use to recover on restart?
4. What is the main durability risk of relying on RDB alone?
5. What did Redis 7 change about the AOF file format?
Was this page helpful?
You May Also Like
Redis Eviction Policies
How Redis decides which keys to remove when memory is full, the available eviction policies, and how to choose the right one for your workload.
Redis Replication
How Redis copies data from a primary to one or more replicas for read scaling and failover readiness, and the consistency tradeoffs that come with it.
Redis Cluster Explained
How Redis Cluster shards data across multiple nodes using hash slots, and how it handles failover and multi-key operations.