Redis Persistence Explained: RDB vs AOF
Redis persistence is the set of mechanisms that write an in-memory dataset to disk so it survives a restart or a crash. Redis and Valkey keep the working dataset in RAM, which is where their speed comes from, but both ship two independent persistence engines: RDB, which takes point-in-time snapshots of the whole dataset, and AOF, which logs every write command so the dataset can be rebuilt by replaying it. You can run either, both, or neither.
So is Redis persistent? Yes, optionally. Persistence is a configuration choice rather than a fixed property of the server. An instance used purely as a cache is often run with it switched off, because the data can be rebuilt from the system of record. An instance holding sessions, queues, or counters usually cannot afford that.
RDB Snapshots
RDB writes a compact binary image of the entire dataset as it existed at one instant. Snapshots fire on the schedule set by the save directives, or on demand via BGSAVE.
save 3600 1 # snapshot if at least 1 key changed in 3600 seconds
save 300 100 # ...or 100 keys changed in 300 seconds
save 60 10000 # ...or 10000 keys changed in 60 seconds
dbfilename dump.rdb
dir /var/lib/redisBGSAVE forks a child process: the child writes the snapshot while the parent keeps serving traffic. Because the fork relies on copy-on-write, it starts cheap but consumes more memory as the parent modifies pages during the save, so a write-heavy instance needs real headroom — budget for the dataset plus a meaningful fraction again. SAVE performs the same work in the main process and blocks every client for its duration, which makes it a maintenance tool rather than a production one.
The cost of RDB is the interval between snapshots. Restores are fast and the resulting file is a single compact artifact that is easy to copy offsite, but every write since the last snapshot is lost if the process dies. Those are the shipped defaults above, and they are more relaxed than people assume: a low-traffic instance that changes a handful of keys an hour is only snapshotted once an hour, so it can lose an hour of writes.
One default catches teams out. With snapshotting enabled, stop-writes-on-bgsave-error is on, which means that if a background save fails — a full disk is the usual cause — the server stops accepting writes entirely until a save succeeds again. It is deliberate, on the grounds that silently failing to persist is worse than failing loudly, but an application that suddenly cannot write is rarely traced back to a disk that filled up hours earlier.
AOF (Append-Only File)
AOF takes the opposite approach: it appends every write command to a log in the Redis protocol format and replays that log at startup to reconstruct the dataset. It is disabled by default. Commands are appended after they execute rather than before, so the log only ever contains operations the server actually accepted.
How much you can lose is governed entirely by appendfsync:
appendonly yes
appendfsync everysec # always | everysec | no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb- always — fsync before replying to the client. The safest setting and by a wide margin the slowest, since every write waits on the disk.
- everysec — fsync once per second. The default, and the right answer for almost everyone: roughly one second of writes is at risk.
- no — leave flushing to the operating system. Fastest, with an exposure window you do not control.
An append-only log grows without bound, so it is periodically compacted by a rewrite — triggered manually with BGREWRITEAOF, or automatically once the file exceeds the thresholds above. Since Redis 7.0 the AOF is multi-part: a base file, one or more incremental files, and a manifest that ties them together, swapped in atomically when a rewrite finishes. With aof-use-rdb-preamble enabled, which is the default, that base file is written in RDB format, so a restart loads the bulk of the data at snapshot speed and replays only the tail.
RDB vs AOF
| RDB | AOF | |
|---|---|---|
| What is stored | A binary image of the dataset | A log of every write command |
| Worst-case data loss | Everything since the last snapshot | Up to about a second at everysec |
| Restart speed | Fast | Slower — the tail must be replayed |
| File size | Compact | Larger, until a rewrite compacts it |
| Runtime cost | Periodic fork and memory spike | Continuous writes plus fsync |
| Enabled by default | Yes | No |
| Best at | Backups and disaster recovery | Minimising data loss |
In practice this is rarely an either/or decision. The two engines have always been able to run at the same time, and when both are enabled the server loads the AOF at startup because it is the more complete record, falling back to the RDB file only if no AOF exists. What changed over time is how well they combine: Redis 4.0 introduced the RDB preamble, and 7.0 the multi-part layout, so a modern AOF already carries a snapshot as its base rather than replaying history from nothing. The common production configuration uses AOF at everysec for the durability guarantee and keeps RDB snapshots as the backup artifact, since one file is far easier to ship offsite and restore than a directory of log segments. Turning persistence off entirely is a legitimate choice too — for a pure cache it removes the fork pauses and the disk I/O, and nothing of value is lost on restart.
What Persistence Means for Java Applications
Persistence and replication are often conflated, and they solve different problems. Persistence protects a single node against process restart; replication protects you against losing that node altogether. An instance running appendfsync always still loses everything if its disk fails, and a replica set with persistence disabled loses everything if every node restarts at once. Production systems that care about the data run both, usually with Sentinel or Cluster handling failover.
The distinction shows up at write time. Replication is asynchronous by default, so a write your client has already been told succeeded may not have reached a replica yet — the WAIT command exists to block until a given number of replicas confirm it. Redisson, the Valkey and Redis Java client, leans on that same guarantee where correctness depends on it: an RLock is not treated as held until the write has reached a replica, a check enabled by default, which closes the window in which a lock is granted, the primary dies before replicating, and a promoted replica hands the same lock to a second caller.
The Redisson objects most exposed to server-side persistence are the ones whose entire value is a delivery guarantee. RReliableQueue and RReliableTopic promise at-least-once delivery, and RStream retains entries so consumer groups can replay them. All of them assume the data is still there after a restart, so pointing them at an instance with persistence disabled quietly downgrades the guarantee to something weaker than the API implies. See All About Reliable Queue for Valkey and Redis for how those guarantees are constructed.
Two smaller consequences are worth knowing. RBatch sends many commands in a single round trip, which is good for throughput but widens the set of writes in flight when a node dies mid-batch. And cached data recovers on different terms from stored data: RMapCache entries carry their own TTL and expire regardless of what survived, while RLocalCachedMap can be set to ReconnectionStrategy.LOAD so a near cache is repaired after a disconnect instead of being flushed wholesale.
Redis Persistence: Frequently Asked Questions
Is Redis Persistent?
It can be. Redis and Valkey hold data in memory but offer two ways to write it to disk: RDB point-in-time snapshots, which are on by default, and the AOF command log, which is not. Persistence is configured per instance, so whether a given deployment survives a restart depends on how it was set up rather than on Redis itself.
Should I Use RDB or AOF?
Most production deployments use both. AOF at the everysec setting caps data loss at roughly a second, while RDB snapshots give you a single compact file that is easy to copy offsite and restore. Use RDB alone when the data can be rebuilt from another source and losing whatever fell between snapshots is acceptable, and disable persistence entirely for a pure cache.
How Much Data Can I Lose With AOF?
That depends on the appendfsync setting. With always, a write is flushed to disk before the client is told it succeeded, so almost nothing is lost. With everysec, the default, roughly one second of writes is at risk. With no, the operating system decides when to flush and the window is out of your control.
Does Persistence Slow Redis Down?
Both engines have a cost. RDB forks a child process, which is briefly expensive in memory on a write-heavy instance and can cause a latency spike on large datasets. AOF adds a continuous stream of disk writes, and the appendfsync setting determines how much of that lands on the critical path. The everysec default keeps the effect small for most workloads.
Does Persistence Replace Backups or Replication?
No. Persistence protects a single node against a restart, replication protects against losing that node, and a backup protects against a bad deploy or an accidental flush that persistence would faithfully write to disk. They cover different failures and a serious deployment uses all three.