Choose Durability Settings from RPO, Latency, Memory, Fork Behavior, and Storage Characteristics

Learning outcomes

The final design question is not “RDB or AOF?” in isolation. AtlasMart must choose a persistence envelope that meets business recovery objectives on its actual storage and memory limits, while preserving enough headroom for fork/rewrite and separating node durability from service availability and backup.

1. Start with RPO and RTO, not a config snippet

Recovery point objective (RPO) is the maximum acceptable data-loss interval. Recovery time objective (RTO) is the target time to restore acceptable service. RDB save cadence, AOF fsync policy, backup frequency, startup replay time, and replication topology all contribute differently. None should be selected solely because it is a Redis default.

2. Compare the persistence modes honestly

3. Memory budget includes COW headroom

maxmemory, when configured, is not total process RSS and does not reserve space for forked-child COW pages. Persistence jobs can increase RSS while the parent mutates memory. Capacity planning therefore includes dataset/overhead, client/output buffers, replication/AOF buffers, integrated indexes, allocator fragmentation, and expected COW peak under write load.

INFO memoryINFO persistenceINFO statsLATENCY LATESTSLOWLOG GET 20# Capture current_cow_peak, rdb_last_cow_size, aof_last_cow_size, latest_fork_usec, memory RSS/fragmentation, and tail latency.

4. Disk budget includes transient rewrite and backup state

Measure active MP-AOF bytes, RDB size, rewrite growth while the child runs, backup artifacts awaiting seal/retention cleanup, filesystem free space, and storage throttling/burst limits. A dataset that “fits on disk” can still fail a rewrite because the transient peak does not.

5. Benchmark persistence with realistic writes

Run the same bounded AtlasMart workload across candidate modes using disposable keys under atlasmart:ch17:l5:bench:. Hold payloads, key distribution, pipeline depth, concurrency, client connection model, and dataset size constant. Record throughput plus p50/p95/p99 command latency, fork duration, COW peak, fsync/rewrite metrics, storage utilization, and restart/replay time. An average-only benchmark hides the pauses persistence planning is supposed to expose.

result = {  "mode": "aof-everysec",  "requests": measured_requests,  "p50_ms": percentile(latencies, 50),  "p95_ms": percentile(latencies, 95),  "p99_ms": percentile(latencies, 99),  "fork_usec": observed_fork_usec,  "cow_peak_bytes": observed_cow_peak,  "restart_seconds": observed_restart_seconds,}print(result)# Fill only from an executed test. Do not copy example numbers from another machine.

6. Crash recovery and backup restore are separate acceptance tests

7. Replication can improve availability but does not erase persistence questions

Redis replication is asynchronous. Sentinel or Cluster can promote a replica, but the promoted replica may not contain every acknowledged primary write. Persistence determines what a node can reconstruct after restart; replication determines another copy/topology; backup protects against broader failure and historical recovery. State the guarantee of each layer independently.

8. Security and platform constraints belong in durability design

Protect persistence and backup artifacts because they contain application data. Restrict file/volume access, encrypt storage/transport where appropriate, rotate credentials independently, and include ACL/TLS/config dependencies in restore drills. Managed Redis products may expose different persistence options and responsibilities; verify service-specific RPO, restore, backup ownership, and cost rather than mapping self-managed knobs one-to-one.

9. Decision worksheet

10. Production judgment and chapter synthesis

Choose the simplest persistence mode that meets measured RPO/RTO without violating latency, memory, disk, and operational constraints. Document what is guaranteed, what is merely likely, and what is outside Redis. Re-test after Redis upgrades, storage-class changes, dataset growth, major schema/index changes, or topology migrations because the previous headroom/latency evidence may no longer hold.

11. Summary and bridge

Chapter 17 converted persistence from a slogan into measured recovery engineering: RDB snapshots define point-in-time recovery, AOF narrows the normal loss window according to fsync policy, rewrite needs COW/disk headroom, combined startup prefers AOF, and backup requires restore proof. Chapter 18 now examines memory management, eviction, fragmentation, and out-of-memory prevention—the headroom constraints that persistence forks already exposed.

Authoritative references

• Redis persistence
• INFO
• BGSAVE
• LASTSAVE
• SAVE
• BGREWRITEAOF
• CONFIG GET
• CONFIG SET
• Redis 8.10 release notes
• Redis 8.10 whats new
• BACKUP
• Redis replication
• Redis Sentinel
• Redis Cluster specification
• Redis ACLs
• Redis latency diagnosis
• Redis memory optimization
• Redis security
• Redis licenses
• Docker Official Redis image