Persistence: RDB and AOF

Redis · Advanced · 12 min

Whether Redis is a cache or a source of truth depends entirely on how it persists data.

Redis offers two persistence mechanisms, usable together.

RDB snapshots write a compact point-in-time dump (dump.rdb) at intervals, configured with save <seconds> <changes> rules or triggered by BGSAVE. Redis forks; the child writes the snapshot while the parent keeps serving, thanks to copy-on-write memory. RDB files are great for backups and fast restarts, but a crash loses everything since the last snapshot, possibly minutes of writes.

AOF (append-only file) logs every write command. appendfsync controls durability:

  • always: fsync after every write, safest and slowest,
  • everysec (recommended default): fsync once per second, losing at most about a second of writes,
  • no: let the OS decide.

The AOF grows, so Redis periodically rewrites it in the background into the minimal command set. Since 7.0 AOF is a multi-part set (a base file plus incremental files and a manifest in appenddirname).

Typical setups: a pure cache can disable persistence entirely; a store of record uses AOF everysec, often with RDB as well for backups. On restart with AOF enabled, Redis loads the AOF because it is more complete.

Watch out for the fork: with a large dataset and heavy writes, copy-on-write can temporarily double memory use, so leave headroom and avoid swap.

Example

# redis.conf (or CONFIG SET at runtime)
save 3600 1 300 100 60 10000     # RDB: snapshot if 1 change/1h, 100/5min, 10000/1min
appendonly yes                   # enable AOF
appendfsync everysec             # lose at most ~1 s of writes
appenddirname "appendonlydir"
auto-aof-rewrite-percentage 100  # rewrite when AOF doubles
auto-aof-rewrite-min-size 64mb

# operations from the shell
redis-cli BGSAVE                 # Background saving started
redis-cli LASTSAVE               # (integer) 1760700000  unix time of last save
redis-cli INFO persistence | grep -E 'rdb_last_bgsave_status|aof_enabled'
# rdb_last_bgsave_status:ok
# aof_enabled:1

Remember

  • RDB: periodic forked snapshots, compact, may lose minutes
  • AOF: logs writes; everysec loses at most about one second
  • Both can be enabled; AOF is used for recovery when present
  • Forking can briefly double memory under heavy writes

Watch out for

  • Treating Redis with default snapshot-only settings as a durable primary database.

Check yourself

  1. With appendonly yes and appendfsync everysec, how much acknowledged data can a power loss destroy?

Sign in to answer, see the explanations, and get this lesson back as a quick review later.

Official docs: redis.io/docs/latest/operate/oss_and_stack/management/persistence/