Redis / Advanced: persistence, distribution and operations / Lesson 13

RDB, AOF and durability budgets

Choose persistence from the acceptable loss and restart contract. Distinguish snapshots, append-only history and independent backup without treating an acknowledged write as a universal durability guarantee.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain RDB and AOF recovery boundaries and resource costs.
Connect persistence policy to restore evidence and business authority.

Decide which data may be lost or rebuilt

A disposable cache and an authoritative work stream have different persistence requirements. RDB creates point-in-time snapshots, while AOF records a replayable write history under its configured synchronization policy. Neither a file’s presence nor an OK reply establishes independent disaster recovery. Define acceptable recent-data loss, restart duration and the role of an authoritative source before selecting a policy. A cache that can be rebuilt may still cause a source overload during restart, so rebuild capacity is part of the availability plan rather than a reason to ignore recovery.

Record persistence intent without changing configuration

The JSON is a fictional decision record, not valid redis.conf or an administration command. It distinguishes snapshot recovery from the required service validation and protected-copy process. Actual fsync, file layout, storage behavior and managed-service options require the exact product documentation. A requirement such as acceptable loss must be tested against real failure modes rather than inferred from a label. The course does not write configuration, trigger snapshots, rewrite logs or start Redis. Use this record to make the questions reviewable before an authorized environment-specific implementation.

json Nonexecuting persistence decision record

{
  "dataset": "synthetic-work-history",
  "authority": "requires-reviewed-recovery",
  "persistenceDecision": "compare-RDB-and-AOF-against-loss-budget",
  "restoreChecks": ["known-events", "consumer-state", "application-version"],
  "protectedCopy": "separate-failure-domain",
  "evidenceState": "rehearsal-required"
}

The record states questions and checks only. It neither enables persistence nor proves any specific loss window.

Compare recovery points, replay and synchronization

A snapshot can omit changes after its capture point. AOF synchronization options trade acknowledgment timing and storage work against crash-loss exposure; common every-second synchronization is not a universal contractual guarantee under every storage or operating-system failure. Rewrites and snapshots consume CPU, I/O and additional memory through mechanisms such as copy-on-write. Redis 7 introduced a multipart AOF layout, so recovery and backup procedures must understand the actual manifest/files rather than assume one old-style appendonly file. Do not manually edit recovery artifacts as a generic tutorial repair. Preserve an untouched copy and use reviewed procedures.

Calculate a declared recovery gap separately from a guarantee

The offline model compares a synthetic last-protected event position with the latest accepted event position. It shows three later events outside the selected recovery point, not a measured duration or an assurance that a specific persistence mode behaves that way. Real evidence needs artifact identity, history boundary, file completeness, storage and server versions and a tested restore. A numerical gap can be useful only if the positions represent the same ordered history and the application knows which business events they cover. Do not turn a toy sequence into a data-loss SLA.

python Offline recovery-boundary arithmetic

last_protected_event = 17
last_accepted_event = 20
assert last_accepted_event >= last_protected_event
unprotected_events = last_accepted_event - last_protected_event
assert unprotected_events == 3

Three synthetic event positions lie after the chosen protected point. No persistence mechanism or real failure was exercised.

Verify usable restoration and historical independence

A restore rehearsal should check known keys, value types, critical event or consumer state, expiry interpretation, client compatibility and service behavior. Expiration metadata can affect what is visible after time has advanced, so an old snapshot is not simply a frozen forever-live keyspace. Keep artifacts outside the source failure domain with recoverable secrets and access. Replication can reproduce a mistaken delete and does not replace retained historical copies. A service that starts successfully has passed only one check; measure complete recovery and source rebuild impact before claiming the business objective is met.

Common errors and fixes

An AOF file is treated as a complete independent backup

Why it happens: Local persistence was confused with protected historical recovery.
How to fix it: Define and rehearse protected artifact copies and restoration.
Prevent it next time: Test source-host loss and logical deletion scenarios separately.

Recovery assumes the legacy single-file AOF layout

Why it happens: Version-specific multipart files and manifest handling were omitted.
How to fix it: Use the exact supported recovery procedure on an untouched copy.
Prevent it next time: Record server/tool versions and artifact completeness.

Persistence jobs cause unexpected resource pressure

Why it happens: Fork, rewrite and copy-on-write costs were excluded from capacity planning.
How to fix it: Investigate measured resource usage and review the persistence schedule/policy.
Prevent it next time: Include persistence peaks in memory, storage and latency budgets.

Check your understanding

1. Can a cache with no persistence be called harmless to lose simply because the source still exists?

Show worked solution

Not automatically. A cold rebuild can overload the authoritative service, delay users or expose missing fallback assumptions. Define whether the data is reconstructible, the rebuild rate, admission policy and acceptable interruption. Persistence may not be required for the data itself, but availability and recovery still need evidence.

2. Why must a restore test include expiry behavior?