Redis Persistence Design: From Cache to Reliable Data System

Why Persistence Matters

Redis can be highly available without persisting data, but high availability only protects against node failures, not data loss. Persistence is the engineering solution that ensures data survives crashes, making Redis a reliable data system rather than just an in‑memory cache.

Three Persistence Strategies Compared

RDB (Snapshot) : Low data safety, extremely fast recovery, low performance impact; suited for pure cache or disaster‑recovery snapshots where minute‑level data loss is acceptable.

AOF (Append‑Only File) : High data safety, slower recovery, medium‑to‑high performance impact; ideal for scenarios requiring strong durability.

Hybrid (RDB + AOF) : High safety, fast recovery, moderate performance impact; recommended as the production‑grade default.

RDB – Full‑Snapshot Persistence

Mechanism

BGSAVE → fork child process → COW → serialize memory → dump.rdb

Typical configuration (seconds / keys changed):

save 900 1

save 300 10

save 60 10000

Manual trigger: redis-cli BGSAVE Best suited for:

Pure cache workloads

Periodic full backups

Environments that can tolerate minute‑level data loss

AOF – Command‑Log Persistence

appendonly yes

appendfsync everysec   # recommended

Three fsync policies:

always : No data loss, worst performance.

everysec : ≤1 s data loss, best overall balance.

no : Uncertain loss, best performance.

File‑size growth mitigation: redis-cli BGREWRITEAOF Automatic rewrite control:

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

Hybrid Persistence – Production‑Grade Choice

appendonly yes

appendfsync everysec

aof-use-rdb-preamble yes

save 900 1

save 300 10

save 60 10000

During startup Redis first loads the RDB snapshot (seconds‑level recovery) then replays the AOF tail (ensuring full data consistency).

Production Configuration Templates

1️⃣ Pure Cache

appendonly no

save 900 1

save 300 10

save 60 10000

2️⃣ Financial‑Grade Data

appendonly yes

appendfsync always

save ""

3️⃣ General Production (Strongly Recommended)

appendonly yes

appendfsync everysec

aof-use-rdb-preamble yes

save 900 1

save 300 10

save 60 10000

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

no-appendfsync-on-rewrite yes

Big Keys – The Hidden Killer

Redis single keys should not exceed 1 MB .

Detect large keys: redis-cli --bigkeys Delete safely: UNLINK big:key Split pattern example:

user:1001:profile:1

user:1001:profile:2

Persistence ≠ Backup – Need Off‑site Copies

Standard pipeline:

Redis → local persistence → scheduled copy → remote backup

Example cron for RDB copy:

0 */6 * * * cp /data/dump.rdb /backup/redis/$(date +%F_%H).rdb

Or use rsync:

rsync dump.rdb backup-server:/redis-backup/

Repairing Corrupted AOF/RDB Files

redis-check-aof appendonly.aof

redis-check-aof --fix appendonly.aof

redis-check-rdb dump.rdb

Redis on Kubernetes – Persistence Pitfalls

Wrong: Using emptyDir for data, which is deleted when the pod is removed.

volumes:

- name: redis-data

emptyDir: {}

Correct: Bind a PersistentVolumeClaim.

volumes:

- name: redis-data

persistentVolumeClaim:

claimName: redis-pvc

Master‑Slave Best Practice

Assign roles based on workload:

Master – optimized for write performance.

Slave – runs RDB + AOF and serves as the backup source.

Accidental FlushAll Recovery – Real Case

Steps:

Immediately stop Redis.

Copy the AOF file.

Manually delete everything after the FLUSHALL command in the AOF.

Restart using the latest RDB snapshot together with the cleaned AOF.

This provides Redis’s only “near‑time rollback” capability.

RPO / RTO Metrics

RDB : RPO ≈ minutes, RTO ≈ seconds.

AOF : RPO ≈ seconds, RTO ≈ minutes.

Hybrid : Both RPO and RTO are in the seconds range.

Final Takeaway

Redis persistence is not merely a configuration toggle; it is a core system‑design decision. High availability without persistence only guarantees “service stays up”. Backup‑less persistence is merely “self‑consolation”. The truly reliable data system combines hybrid persistence + off‑site backup + engineering governance .