Redis persistence has two options: RDB (point-in-time snapshots, default) and AOF (append-only file, every write logged). RDB is fast for backups and restarts but can lose the last few minutes of writes. AOF is more durable (every write) but slower. Per Redis docs, the default redis.conf uses RDB. The team that needs durability uses both RDB (snapshots) and AOF (every-second fsync).
Table of contents
- RDB (Redis Database)
- AOF (Append Only File)
- Choosing RDB vs AOF
- Configuration example
- Redis 7.0+ improvements
- Backup strategy
- When persistence doesn’t matter
- FAQ
RDB (Redis Database)
Point-in-time snapshots. Default redis.conf:
save 3600 1 # 1+ keys changed in 1 hour
save 300 100 # 100+ keys changed in 5 min
save 60 10000 # 10000+ keys changed in 1 minCreates dump.rdb file. On restart, Redis loads this file.
The team that uses RDB has fast recovery and small backup files. The team that has write-heavy workloads can lose up to 1 hour of data.
AOF (Append Only File)
Logs every write operation:
appendonly yes
appendfsync everysec # default - fsync every second
appendfsync always # fsync every write (slowest, most durable)
appendfsync no # let OS decide (fastest, least durable)File grows continuously; Redis rewrites it in the background (BGREWRITEAOF).
The team that uses AOF has durable writes (down to 1 second loss). The team that uses always fsync has the most durability but the worst performance.
Choosing RDB vs AOF
Per the Redis docs:
- RDB: backup-friendly, fast restarts, can lose last few minutes. Good for caches where some loss is acceptable.
- AOF: more durable, append-only is conceptually simple, can replay writes on recovery. Good for data that must survive.
- Both: max durability (AOF every-second) + fast restarts (RDB snapshot). Production recommendation.
Configuration example
# /etc/redis/redis.conf
# RDB (snapshots)
save 3600 1
save 300 100
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis
# AOF (durability)
appendonly yes
appendfsync everysec
no-appendfsync-on-rewrite yes # avoid fsync during rewrite
aof-use-rdb-preamble yes # hybrid: RDB snapshot + AOF tailThe team that uses this config has both fast snapshots and durable writes.
Redis 7.0+ improvements
Redis 7.0+ has multi-part AOF (cleaner crash recovery, faster restarts). The team that uses Redis 7+ has faster AOF restarts.
Backup strategy
Copy dump.rdb (or AOF file) to S3/GCS for offsite backups:
# Daily cron
cp /var/lib/redis/dump.rdb /backups/redis-$(date +%Y%m%d).rdb
aws s3 cp /backups/redis-$(date +%Y%m%d).rdb s3://my-backups/redis/The team that has offsite backups has disaster recovery. The team that only has local backups loses data if the disk fails.
When persistence doesn’t matter
For pure caches (session, rate-limit, transient data), disable persistence:
save ""
appendonly noFaster, no disk I/O. The team that uses Redis as a cache has no need to persist.
FAQ
Should I enable persistence for a Redis cache?
No - caches should lose data on restart. Disable persistence for performance. The team that uses Redis as cache has save "" and appendonly no.
What’s the durability of AOF with everysec?
Up to 1 second of writes can be lost. The team that needs zero-loss uses appendfsync always (slowest).
Can I have both RDB and AOF enabled?
Yes - Redis loads RDB first (fast snapshot restore), then replays AOF on top (durable writes). The team that uses both has best of both.
How do I manually trigger a snapshot?
BGSAVE (background) or SAVE (blocks). The team that triggers before a risky operation has a recovery point.
What is the difference between AOF and WAL?
AOF logs every write command, replayed on restart. WAL (write-ahead log, like Postgres) is similar concept but typically binary format. Redis’s AOF is text-based by default, binary with aof-use-rdb-preamble yes.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: