Redis persistence: state the recoverable write window before choosing AOF or snapshots

Last updated: 2 Oct 20267 min read

tutorial

Redis persistence is an optional path from in-memory state to disk. RDB snapshots capture a point in time; writes after that snapshot are absent from that file. The append-only file, or AOF, records writes for replay and has a configurable synchronization policy. With periodic synchronization, a process or host failure may lose the most recent acknowledged writes. Running both mechanisms does not remove the need for a restore test: the chosen files must be copied consistently, kept off the failed host, and tested with the intended software version. A cache that can be rebuilt and an authoritative ledger need different recovery contracts.

Operational decision

A pricing cache can accept a rebuild after restart, so its owner documents the source database and maximum refill rate. A reservation token store cannot casually regenerate lost tokens; the team either chooses a stricter persistence and replication design or moves the authoritative state to a transactional database. During a disposable drill, write 147 numbered keys, capture the last client acknowledgment, force a process and then host failure under the selected settings, and count which IDs restore. Repeat during AOF rewrite or RDB snapshotting. Inspect persistence status and error metrics before declaring the node healthy. Keep an off-host copy and a verified restore command in the runbook.

Synthetic write range: reservation:1 through reservation:147
Client receipt: last acknowledged ID and UTC time
Restore evidence: highest contiguous ID recovered
RDB boundary: latest completed snapshot
AOF boundary: configured fsync behavior and last valid log
Decision: compare observed loss with service recovery budget

Cost and verification

AOF adds disk writes and rewrite work; snapshotting consumes fork, copy-on-write memory, and storage bandwidth. A write-heavy instance can need material headroom while a background child runs. Stricter synchronization increases latency and does not make a replica failover transactionally consistent. Disk-full and failed rewrite conditions deserve alerts because an old snapshot can look normal while recent data is at risk. Measure recovery time as well as lost-write count: a large AOF can take longer to load than the service's restoration target allows.

Common Mistakes

Do not equate command acknowledgment with an off-host durable backup.
Do not describe periodic AOF synchronization as zero-loss persistence.
Do not enable a snapshot schedule without measuring fork and disk headroom.

Connected lessons

Practice and check

devops

redis

data-operations