Redis and Valkeyintermediate

Redis Persistence

RDB snapshots, the append-only file, and what each combination actually guarantees after a crash.

3 min readIntermediateUpdated 31 Jul 2026Edit this page

Redis offers two persistence mechanisms which can be used together. Neither makes Redis a system of record, but the difference between them is the difference between losing minutes and losing a second.

RDB

A point-in-time binary snapshot of the whole dataset.

save 900 1        # snapshot if ≥1 key changed in 900s
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis
rdbcompression yes
rdbchecksum yes

Snapshots are written by a forked child process, so the main thread keeps serving. The properties that matter:

Compact and fast to load. Restarting from RDB is much faster than replaying an AOF.
Loses everything since the last snapshot. With the defaults above that can be minutes.
Forking copies page tables. On a large instance the fork itself causes a latency spike, and copy-on-write means memory usage can grow substantially during the snapshot if writes are heavy.

AOF

An append-only log of every write command, replayed at startup.

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec      # always | everysec | no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble yes

appendfsync is the durability choice:

Setting	Loss window	Cost
`always`	Effectively none	An fsync per write; substantially slower
`everysec`	Up to ~1 second	The usual choice
`no`	Up to the OS flush interval	Fastest, least durable

The AOF grows continuously, so Redis rewrites it in the background into a compact form. With aof-use-rdb-preamble yes, the rewritten file starts with an RDB snapshot and appends commands after it — fast to load and still fine-grained.

Choosing a combination

Configuration	Use when
Neither	Pure cache, fully rebuildable, restart means a cold start
RDB only	Rebuildable data where a fast restart matters more than the last few minutes
AOF only	Data where a second of loss is the maximum acceptable
Both	The usual production choice: AOF for durability, RDB for fast restore and backup

Operational commands

BGSAVE                    # background snapshot; check rdb_bgsave_in_progress first
BGREWRITEAOF              # background AOF rewrite
INFO persistence          # status of both mechanisms
LASTSAVE                  # unix time of the last successful save

INFO persistence fields worth alerting on: rdb_last_bgsave_status, aof_last_write_status, aof_last_bgrewrite_status and rdb_changes_since_last_save. A failing background save can continue unnoticed for days.