I still remember the moment I realized Redis wasn’t just a throwaway cache in my architecture. I’d been using it to store session data and a bit of application state, treating it as purely ephemeral — until a routine server restart wiped out active user sessions and I got a flood of “why was I logged out” complaints. That was the day I actually sat down and learned how Redis persistence works, instead of assuming it either “just persists” or “doesn’t persist at all.” The truth is more nuanced, and understanding it properly changed how I configure every Redis instance I deploy.
Why Persistence Matters for an In-Memory Store
Redis stores its primary dataset in RAM, which is what gives it such extraordinary speed. But RAM is volatile — if the Redis process crashes, the server reboots, or the container restarts, everything in memory disappears unless it’s been written somewhere durable. Redis offers two main persistence mechanisms to address this: RDB snapshotting and AOF (Append Only File) logging. You can use either one alone, both together, or neither, depending on your durability needs.
Understanding the tradeoffs between these options is essential, because the “right” choice depends entirely on what your data actually is. Pure cache data that can be regenerated from a source of truth might not need persistence at all. Session data, queue state, or anything acting as a primary data store absolutely does.
RDB: Point-in-Time Snapshots
RDB (Redis Database) persistence works by periodically saving a complete snapshot of the entire in-memory dataset to a single compact binary file on disk, typically named dump.rdb. You configure Redis to trigger a snapshot based on rules like “save if at least 100 keys changed within 300 seconds,” and Redis handles the rest.
Under the hood, Redis uses the operating system’s fork() to create a child process that handles writing the snapshot. Because of how copy-on-write memory works, this lets Redis continue serving reads and writes on the parent process with minimal interruption while the snapshot is being written in the background.
Advantages of RDB
RDB snapshots are compact single files, which makes them extremely convenient for backups — you can copy that one file to S3, another server, or cold storage, and you have a complete point-in-time copy of your dataset. Restarting Redis with an RDB file is also very fast, since it’s essentially just loading a serialized memory image back into RAM, which is much quicker than replaying a long log of individual commands.
RDB is also the lower-overhead option in terms of ongoing performance impact, since it only does work during the snapshot window rather than on every single write.
Disadvantages of RDB
The core downside is data loss risk. Since RDB only saves periodically, any writes that happened after the last snapshot are lost if Redis crashes before the next one completes. If you’re snapshotting every five minutes and Redis crashes four minutes after the last snapshot, you lose four minutes of writes. For a cache, that might be a non-issue. For a queue holding unprocessed jobs, that’s a real problem.
The fork() operation itself can also cause latency spikes on systems with very large datasets, since forking has to duplicate certain memory structures, and on memory-constrained systems it can risk out-of-memory conditions if there isn’t enough headroom for the copy-on-write overhead.
AOF: Append-Only File Logging
AOF persistence takes a fundamentally different approach: instead of snapshotting the whole dataset periodically, Redis logs every write operation to an append-only file as it happens. If Redis restarts, it can reconstruct the entire dataset by replaying that log of commands from the beginning.
You control how often the AOF is actually flushed to disk (as opposed to just written to an OS buffer) using the appendfsync setting, which has three options:
always— fsync after every single write. This is the most durable option but also the slowest, since every write operation now involves a disk sync.everysec— fsync once per second, batching writes. This is Redis’s recommended default and the one I use in almost every production setup, because it limits potential data loss to roughly one second’s worth of writes while keeping performance very close to no-persistence levels.no— let the operating system decide when to flush, which is fast but offers the weakest durability guarantee, since you’re at the mercy of OS-level buffering behavior.
Advantages of AOF
AOF offers much stronger durability guarantees than RDB, especially with appendfsync always or everysec, since you’re at most losing a second (or nothing at all) of writes rather than minutes. AOF files are also more resilient to partial corruption — Redis includes a redis-check-aof tool that can repair an AOF file that was cut off mid-write due to a crash, salvaging everything up to the point of corruption.
Disadvantages of AOF
Historically, AOF files could grow very large over time since every write operation gets appended, including redundant ones (imagine incrementing the same counter a million times — the AOF would log all million operations). Redis addresses this with AOF rewriting, a background process that compacts the log into the minimal set of commands needed to reproduce the current dataset, similar in spirit to how RDB snapshots work but expressed as commands rather than raw data.
AOF files also take longer to load on restart compared to RDB, since Redis has to actually replay commands rather than just loading a memory image, though this gap has narrowed with newer AOF formats.
Using RDB and AOF Together
Since Redis 4.0, you can combine both persistence mechanisms, and this is generally what I recommend for anything beyond pure caching. In this hybrid mode, Redis uses RDB-style snapshotting as the base for AOF rewrites (this is sometimes called the “RDB preamble” in AOF files), giving you fast restarts like RDB along with much stronger durability guarantees from the ongoing AOF log layered on top.
If durability truly matters for your dataset, running both RDB and AOF, with appendfsync everysec, is the configuration I reach for by default. It strikes a strong balance between recovery speed and how much data you could realistically lose in a worst-case crash.
Data Recovery in Practice
Understanding recovery matters as much as understanding the mechanisms themselves. Here’s how recovery actually plays out in each scenario:
RDB-only recovery: On startup, Redis looks for the RDB file at the configured path and loads it directly into memory. This is nearly instantaneous even for large datasets, but again, anything written since the last snapshot is simply gone.
AOF-only recovery: On startup, Redis reads the AOF file from the beginning and replays every logged command in order to rebuild the dataset. If the file was truncated due to a crash mid-write, Redis (depending on configuration) may refuse to start until you run redis-check-aof --fix to repair it, which trims the file back to the last complete, valid command.
Combined recovery: Redis prioritizes AOF over RDB if both are present and AOF is enabled, since AOF generally represents the more complete and recent state of the data.
I always recommend testing your recovery process before you need it in a real incident. I’ve seen teams assume their backups were working, only to discover during an actual outage that the RDB file hadn’t been copied off the server in months, or that permissions on the AOF directory were wrong. A quarterly “let’s actually restore from backup” drill has saved me more than once.
Backups Beyond Local Persistence
RDB and AOF protect you against process crashes and restarts, but they don’t protect you against the server itself dying, disk corruption, or accidental FLUSHALL commands. For genuine disaster recovery, I copy RDB snapshots off to separate durable storage (like S3) on a schedule, separate from the local persistence files Redis itself manages. Some teams also run Redis with replication (one or more replica nodes) combined with persistence on the replicas, so there’s a live, up-to-date copy of the data on a separate machine in addition to the durability guarantees from RDB/AOF.
Practical Configuration Examples
A typical redis.conf snippet I use for a production instance holding meaningful data (not just pure cache):
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
This gives me periodic RDB snapshots as a fast-loading base, layered with an AOF log flushed roughly every second, capped at about one second of potential write loss in a worst-case crash.
For a pure caching layer where losing all data on restart is perfectly acceptable (because it’ll just repopulate from the database on the next request), I often disable persistence entirely:
save ""
appendonly no
This maximizes performance since there’s no snapshotting or logging overhead at all.
Comparing Redis Persistence to Other NoSQL Databases
It’s worth putting this in context against other systems. Cassandra and DynamoDB, by design, write to disk (and replicate across multiple nodes) as part of every write operation, giving them much stronger built-in durability guarantees out of the box, at the cost of higher write latency compared to a pure in-memory Redis write. Redis’s approach is the opposite default — optimized for speed first, with persistence as a configurable, opt-in layer. This is a meaningful architectural distinction to understand when deciding which system should be the authoritative source of truth for a given piece of data, and which should just be a fast, potentially-lossy accelerator in front of it.
Security and Operational Notes
Persistence files themselves need protection too — an RDB or AOF file sitting on disk is a full copy of your dataset, so file system permissions, disk encryption, and secure backup storage all matter just as much as securing the live Redis instance itself. I’ve seen teams carefully lock down network access to Redis while leaving nightly RDB backups sitting in a world-readable S3 bucket, which defeats the purpose entirely.
Best Practices Summary
- Decide whether your Redis data actually needs to survive a restart — pure caches often don’t, and disabling persistence there improves performance.
- For anything resembling primary data (queues, sessions with real consequences, counters that matter), enable both RDB and AOF.
- Use
appendfsync everysecas your default; reservealwaysfor scenarios with extremely low data-loss tolerance andnoonly when performance is paramount and loss is acceptable. - Regularly test your recovery process, not just your backup process.
- Store copies of RDB snapshots in separate, durable, access-controlled storage for real disaster recovery.
- Monitor AOF file size and rewrite behavior so it doesn’t grow unbounded.
Understanding Fork Behavior and Memory Overhead
I mentioned earlier that RDB snapshots (and AOF rewrites) rely on fork() to create a child process without pausing the parent. It’s worth digging into this a bit more, because it explains a category of production issues that otherwise seem mysterious. When Redis forks, the operating system doesn’t immediately duplicate all of the parent’s memory — instead, it uses copy-on-write, meaning the child process initially shares the same physical memory pages as the parent, and pages are only actually duplicated when either process writes to them.
This is efficient, but it means that on a busy Redis instance with a high write rate during a snapshot, memory usage can spike significantly above the size of the dataset itself, since every write the parent process handles during the snapshot window potentially triggers a page duplication. On memory-constrained hosts, especially ones running close to their available RAM, this can occasionally push Redis into out-of-memory territory during a snapshot, which is counterintuitive if you’re only thinking about dataset size rather than the mechanics of how the snapshot is actually taken. I generally provision Redis hosts with meaningful headroom above the raw dataset size specifically to accommodate this fork overhead, rather than sizing memory right up to the dataset’s footprint.
AOF Rewrite in Detail
I described AOF rewriting briefly earlier, but it’s worth walking through what actually happens, since understanding it clarifies why the combined RDB-preamble approach became the default. When Redis rewrites the AOF, it doesn’t try to compact the existing log file in place — instead, it forks a child process (using the same copy-on-write mechanism as RDB snapshotting) that writes a brand new, minimal AOF file representing the current dataset from scratch, while the parent process continues appending new write commands to the old AOF file in parallel. Once the child process finishes writing the new file, Redis atomically switches over to it, and the old file is discarded. This design ensures Redis never loses durability during the rewrite process itself — if the server crashes mid-rewrite, the old AOF file is still complete and valid.
You can trigger this manually with BGREWRITEAOF, or configure Redis to trigger it automatically based on how much the AOF file has grown relative to its size after the last rewrite, using auto-aof-rewrite-percentage and auto-aof-rewrite-min-size.
Choosing Persistence Strategy by Workload Type
I’ve found it useful to think about persistence configuration in terms of a few common workload categories rather than agonizing over every setting from scratch each time.
For pure caching workloads — anything fully regenerable from a primary database — I disable persistence entirely, since the performance gain is real and the downside (losing the cache on restart) is trivial; the cache simply repopulates itself on the next round of requests.
For session storage, I typically enable AOF with everysec fsync, since losing active user sessions on a crash is a real (if not catastrophic) user experience problem, but the overhead of always fsync isn’t justified for data this transient.
For queues and job state, where losing an in-flight job could mean real, silent data loss for whatever business process depends on it, I enable both RDB and AOF together, generally with appendfsync everysec, and I pair this with application-level idempotency where possible, so that even the rare case of losing the last second of writes doesn’t cause a job to be silently dropped rather than potentially just reprocessed.
For anything acting as a genuine system of record — which I try to avoid using Redis for at all, preferring a database designed for that role — I’d want the strongest durability configuration available, likely appendfsync always, combined with replication to additional nodes, and I’d seriously reconsider whether Redis is even the right tool for that particular piece of data in the first place.
Persistence Behavior During Replication
It’s worth clarifying how persistence interacts with Redis replication, since the two are sometimes conflated but serve genuinely different purposes. Replication protects against a single node failing by keeping a live copy of the dataset on one or more replica nodes, while persistence protects against the entire process (or all nodes) restarting or crashing by writing data to disk. A replica can be configured with its own independent persistence settings, separate from the primary — for instance, running the primary with persistence disabled for maximum write performance, while a replica handles RDB or AOF persistence so a durable copy still exists somewhere, without paying the persistence overhead on the primary’s write path at all. This pattern is one I’ve used specifically to get the best of both worlds: fast primary writes and a durable backup, without forcing every write to pay disk I/O costs directly.
Final Thoughts
Redis persistence is often misunderstood as an all-or-nothing feature, but it’s really a spectrum of tradeoffs between performance and durability that you get to tune deliberately. Once I understood RDB and AOF properly — what each protects against, and what each leaves exposed — I stopped treating Redis as a black box and started configuring it intentionally for what each dataset actually needed. That’s the mindset I’d encourage anyone running Redis in production to adopt too.