Persistence — RDB and AOF

What you'll walk away with

Explain the core ideas behind Persistence — RDB and AOF
Run the sample Redis command or code and verify its output
Apply the technique correctly to the Tutorial Platform and production scenarios

Build the mental model

RDB creates compact point-in-time snapshots with fast restore but can lose writes between snapshots. AOF logs writes and can reduce the loss window according to fsync policy, at storage and rewrite cost. Replication is not a backup because deletion or corruption can propagate to replicas.

Connect it to a real scenario

Define separate RPO and RTO targets for cache-only data and durable streams. Choose an RDB and AOF policy, copy backups off-host with encryption and retention, and run scheduled restore drills in isolation. Monitor memory and latency during forks and rewrites.

Let RPO and RTO choose the policy
Replication is not backup
A backup is unproven until restored

Try the working example

shell

CONFIG GET save
CONFIG GET appendonly
CONFIG GET appendfsync
BGSAVE
BGREWRITEAOF
LASTSAVE
INFO persistence

You should see

You can inspect snapshot and AOF state, last save time, and background operations.

5-minute try-it

Design persistence and backup for a job stream with one-minute RPO and 15-minute RTO.

One important caution

Do not copy live data files arbitrarily; follow documented snapshot or AOF backup procedures and verify integrity.

Redis — Persistence — Redis

Easy traps

Do not copy live data files arbitrarily; follow documented snapshot or AOF backup procedures and verify integrity.
Validate sample commands on a local or test instance with recoverable data before applying them to production Redis.

Exercise

Design persistence and backup for a job stream with one-minute RPO and 15-minute RTO.

You'll know it worked when: You can inspect snapshot and AOF state, last save time, and background operations.