Redis Persistence Is a Recovery Policy, Not a Checkbox

Redis persistence options make different tradeoffs between runtime cost, recovery time and the amount of recent data that may be lost. A snapshot captures state at a point in time; an append-only file records operations with a chosen synchronization policy. Neither option eliminates the need to rehearse recovery.

First decide whether Redis is a disposable cache or an authoritative store. The acceptable recovery design is very different for those two roles.

The concrete problem

Use a non-production Redis instance and inspect the actual configuration rather than assuming provider defaults. Managed services may restrict commands or implement persistence outside the visible configuration. The commands below are observations, not instructions to alter a live service.

Figure: Live writes → Snapshot or append-only persistence → Recovered state and loss window.

A worked example

CONFIG GET save
CONFIG GET appendonly
CONFIG GET appendfsync
INFO persistence
LASTSAVE
# Inspect, among other fields, background-save/rewrite status
# and last-operation success. Field availability is version-dependent.

Why the behavior matters

RDB snapshots are compact recovery artifacts, but changes after the latest successful snapshot may be absent after recovery. AOF reduces a different part of the loss window depending on its fsync policy and runtime conditions. Rewrites change how the operation history is represented and consume resources; monitor completion and failures.

A configured interval is not an absolute business RPO guarantee. Storage failures, failed saves, host loss and operational mistakes can all change what is recoverable. Replication adds availability options but does not replace independent backups: deletion and other unwanted commands can propagate.

Failure modes and design tradeoffs

For a cache, rebuilding from the source can be the recovery plan, but the source needs enough capacity to absorb the cold start. For data that exists only in Redis, losing recent writes may be a correctness failure rather than a temporary slowdown. Document that distinction for every key family.

Keep persistence files and backups access-controlled. They can contain authentication tokens, identifiers or private payloads even when the application's normal Redis interface looks harmless. Do not place real snapshots in a tutorial repository or CI artifact store.

What to verify before adoption

Write uniquely identified records before and after a controlled persistence boundary, recover a separate instance and compare the recovered set. Record startup duration, missing writes and dependent-service behavior. Repeat with cold-cache load if Redis is disposable. Verify that the runbook identifies the exact persistence files, configuration and encryption/access prerequisites required to restore.

Primary reference

• Redis documentation. Verify the exact deployed version and driver behavior before using the example in a production runbook.