Redis Persistence: RDB, AOF, and the Durability You Actually Get

Redis persistence is two mechanisms, not one. You can run with both — and usually should.

RDB: point-in-time snapshots

A child process serializes the keyspace to a compact binary file. Triggers are time-based (save 3600 1 = at least one change in the last hour) or manual (BGSAVE). Properties:

• Tiny on disk — great for backups and replica bootstrap.
• Recovery is fast (a single sequential read).
• On crash, you lose everything since the last snapshot.

AOF: append-only log

Every write is appended to a text log. The appendfsync policy decides how often that log is flushed to disk:

• always — fsync per command. Strong durability, big latency cost.
• everysec — fsync once per second (default). You can lose up to ~1s on crash.
• no — let the OS decide. Fast, weakest guarantee.

AOF grows without bound, so Redis periodically rewrites it with a background fork that produces a compacted version.

The combined setup

Run both. On restart, Redis loads AOF first (it has the most recent state). Use RDB for off-box backups because the file is small enough to ship.

save 3600 1
save 300 100
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes  # hybrid: RDB prefix + AOF tail

Durability in a cluster

Replicas are asynchronous by default. WAIT numreplicas timeout blocks until that many replicas acknowledge — use it for writes that must not vanish in a failover:

SET session:abc token
WAIT 2 500

Note: WAIT is best-effort. It reduces the window of data loss but does not make Redis a consensus system. If you need that, you're looking for a different database.