RDB Snapshots
RDB persistence writes a compact binary point-in-time snapshot (dump.rdb) — fast restarts and efficient backups at the cost of losing writes since last snapshot.
Introduction
RDB persistence writes a compact binary point-in-time snapshot (dump.rdb) — fast restarts and efficient backups at the cost of losing writes since last snapshot. BGSAVE forks a child process to write disk while master serves commands.
save directives in redis.conf trigger snapshots after N changes in M seconds. fork() on large memory instances causes latency spikes via copy-on-write pressure — schedule BGSAVE off-peak.
Combine RDB for backup cadence with AOF for finer recovery point objective.
Understanding the topic
Key concepts
- SAVE — blocking snapshot; avoid production.
- BGSAVE — background fork child writes RDB.
- dump.rdb — single file restore point.
- save 900 1 style rules in config.
- LASTSAVE — Unix time of last success.
- Partial sync possible after restart with replication.
flowchart LRWrites --> MemoryMemory -->|fork| RDBMemory -->|append| AOF
Step-by-step explanation
- Trigger via save rule, BGSAVE command, or shutdown.
- fork() creates child with shared memory pages.
- Child iterates keyspace writing compressed RDB.
- COW — parent writes duplicate pages on mutation.
- Complete RDB atomically renamed into place.
Syntax reference
Common commands
- BGSAVE not SAVE in prod.
- Monitor latest_fork_usec in INFO.
- Copy RDB to S3 after BGSAVE for DR.
BGSAVELASTSAVECONFIG GET save# redis.conf: save 900 1 save 300 10 save 60 10000
Informative example
Manual backup before migration — verify RDB file:
redis-cli BGSAVE# wait for OKredis-cli LASTSAVEls -lh /var/lib/redis/dump.rdbaws s3 cp dump.rdb s3://backups/redis/$(date +%F).rdb
Stop writes or use REPLICAOF snapshot on replica for cold backup without master fork load.
Real-world use
Real-world use cases
- Nightly backup to object storage.
- Fast cold start after planned restart.
- Disaster recovery baseline.
- Clone staging from prod RDB (scrub PII).
- Compliance point-in-time archive.
Best practices
- Run BGSAVE on replica when possible.
- Leave RAM headroom for COW during fork.
- Automate S3 upload with encryption.
- Test restore quarterly — redis-check-rdb.
- Pair with AOF for tighter RPO.
- Alert on failed BGSAVE in logs.
Common mistakes
- SAVE on production master.
- No off-site copy — datacenter loss = data loss.
- Assuming RDB captures last second of writes.
- Fork failure from overcommit disabled.
Advanced interview questions
Q1BeginnerRDB vs AOF?
Q2BeginnerBGSAVE vs SAVE?
Q3IntermediateWhy latency spike during BGSAVE?
Q4IntermediateRestore from RDB?
Q5AdvancedBackup strategy for 50GB Redis?
Summary
RDB = point-in-time binary snapshot.