Redis Persistence: RDB vs AOF, Configuration and Failure Modes

Redis persistence is how Redis writes its in-memory dataset to disk so it survives a restart. It has two mechanisms: RDB snapshots, which save the whole dataset at intervals, and the append-only file (AOF), which logs every write. You can run either, both, or neither. RDB loses the writes made since the last snapshot. AOF with the default fsync once per second loses about a second. Redis recommends running both if you want data safety comparable to PostgreSQL.

Below: how each mechanism works, the settings that matter, recovery, and the failures we see in production. For where persistence sits in the overall design, see Redis architecture; for use cases, what Redis is used for.

To take a snapshot, Redis forks. The child process writes the dataset to a temporary file and renames it over the old dump.rdb when it finishes, while the parent keeps serving clients. Copy-on-write means the two processes share memory pages until the parent modifies one.

Snapshots run on save points: save if at least M keys changed in N seconds. The current redis.conf documents these defaults, which you can set explicitly:

save 3600 1 300 100 60 10000
dbfilename dump.rdb
stop-writes-on-bgsave-error yes

That is one hour after one change, five minutes after 100, or one minute after 10,000. BGSAVE forces a background snapshot; SAVE blocks every client. save "" disables snapshots.

RDB files are compact, safe to copy while Redis runs, and load faster than an AOF on big datasets. The cost is the loss window: Redis's documentation says to be prepared to lose the latest minutes of data.

With appendonly yes, every command that changes the dataset is appended to the AOF in the Redis protocol format, and Redis replays the file at startup. How often the file is fsynced decides what a crash can lose:

The log grows with every write, so Redis rewrites it in the background: a forked child writes the smallest set of operations that rebuilds the current data. BGREWRITEAOF triggers a rewrite by hand, and the two auto-aof-rewrite settings trigger it when the file has doubled since the last rewrite and is at least 64 MB.

Multi-part AOF (Redis 7.0 and later). The AOF is now a directory, set by appenddirname, holding one base file, one or more incremental files and a manifest that tracks them. During a rewrite the parent just opens a new incremental file; before 7.0 it buffered writes in memory and wrote them twice, which could stall Redis at the end of the rewrite.

appendonly yes
appenddirname "appendonlydir"
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble yes

aof-use-rdb-preamble yes, the default, makes the AOF base file an RDB snapshot; only the writes since the last rewrite are stored as commands. You get RDB's fast loading and AOF's one-second loss window from the same files, and the startup log reports Reading RDB preamble from AOF file.

Keep RDB snapshots on as well: the snapshot is the file you ship off-host for backups. Redis never runs a snapshot and an AOF rewrite at once, and with both enabled it rebuilds from the AOF, the most complete copy.

To turn on AOF on a live server that uses RDB, run CONFIG SET appendonly yes, wait for the rewrite to finish (aof_rewrite_in_progress back to 0 in INFO persistence), then persist it with CONFIG REWRITE. Redis's documentation warns that editing redis.conf and restarting instead can lose data, because Redis would start from the new, empty AOF instead of the snapshot.

At startup Redis loads the AOF if it is enabled, otherwise dump.rdb. Two cases need attention:

• Truncated AOF. A crash or full disk can leave a half-written last command. With aof-load-truncated yes, the default, Redis drops it and starts.
• Corrupted AOF. Invalid bytes in the middle make Redis refuse to start. Back up the files, run redis-check-aof without --fix to find the offset, and only then decide on --fix, which discards everything from the bad point to the end of the file.

A replica restarted from RDB can usually resume with a partial resync; one restarted from AOF cannot, and needs a full sync. And persistence files on the same host are not a backup: our Redis backup and disaster recovery guide covers getting them off the host and testing the restore.

• Fork latency and memory. The fork copies the page tables, about 48 MB for a 24 GB instance, while the main thread waits. A write-heavy instance can use up to twice its normal memory during a save. Redis recommends disabling transparent huge pages and setting vm.overcommit_memory = 1; our Redis memory guide covers sizing.
• Disk full or failing. When a background save fails and stop-writes-on-bgsave-error is yes, Redis rejects writes with a MISCONF error until a save succeeds; failed AOF writes also return MISCONF.
• fsync stalls. With everysec, an fsync slower than about two seconds makes the main thread block on the write. Slow or shared disks are the usual cause.
• Replica full syncs. A full sync forks the primary to produce an RDB even with persistence off. The 1 MB default backlog turns short disconnects into full syncs, and a replica whose buffer passes client-output-buffer-limit replica 256mb 64mb 60 is dropped mid-sync and starts again, in a loop.
• An empty primary wiping its replicas. A primary with persistence off that restarts automatically comes back empty, and its replicas copy it. Disable auto-restart in that setup.

The Redis troubleshooting guide covers diagnosing these from logs and INFO.

Valkey, the Linux Foundation fork of Redis 7.2.4, keeps the same RDB and AOF mechanisms, configuration names and defaults. It reads and writes files compatible with Redis OSS 7.2 and earlier; files written by Redis 7.4 and later are not compatible, so from those versions plan a data migration rather than copying dump.rdb. Our Valkey vs Redis comparison covers the other differences.

Persistence settings are usually chosen once and never revisited, until a fork pushes a node into swap or a failover loses more data than expected. AceMQ's Redis support engineers review persistence against the loss each workload can tolerate and take the call when it goes wrong; Valkey support covers the fork, and Redis managed services covers running it for you.

• Redis: Redis persistence
• Redis: redis.conf for Redis 8.2 (defaults)
• Redis: Redis 7.0 release notes (multi-part AOF, diskless sync default)
• Redis: Diagnosing latency issues (fork, THP, AOF)
• Redis: Redis administration (overcommit, memory during saves)
• Redis: Redis replication
• Redis: WAITAOF
• Valkey: Persistence
• Valkey: Migration from Redis to Valkey (file compatibility)