# How Does Redis Persist Data? A Deep Dive into AOF, RDB, and Trade-offs > Discover how Redis persists data using AOF, RDB, and mixed strategies. Understand the trade-offs in durability, recovery speed, and write latency to optimize your Redis setup. - Repository: [ByteByteGoHq/system-design-101](https://github.com/ByteByteGoHq/system-design-101) - Tags: deep-dive - Published: 2026-02-28 --- **Redis persists data using three primary strategies—AOF (Append-Only File), RDB (Redis Database Snapshots), and a mixed approach—each balancing durability, recovery speed, and write latency differently.** Redis stores all data in memory for sub-millisecond latency, but it also provides on-disk persistence to survive process restarts or crashes. According to the ByteByteGoHq/system-design-101 repository, understanding these persistence mechanisms is critical for production deployments where data durability and availability requirements vary. This guide examines how Redis implements persistence according to the source analysis in [`data/guides/how-does-redis-persist-data.md`](https://github.com/ByteByteGoHq/system-design-101/blob/main/data/guides/how-does-redis-persist-data.md), detailing the architectural trade-offs between consistency and performance. ## Redis Persistence Strategies Redis offers three distinct persistence modes, each optimized for different operational requirements regarding durability, recovery time, and latency impact. ### AOF (Append-Only File): Maximum Durability The **Append-Only File** logs every write command after it has been applied to the in-memory dataset. Unlike traditional write-ahead logging, Redis uses a write-after approach where commands are first executed in RAM, then recorded to the AOF log. - **Write latency**: Non-blocking. The main thread does not wait for disk I/O, though the `fsync` policy (`appendfsync`) determines durability guarantees. - **Recovery**: Replays the entire log sequentially, which can be slow for large datasets but provides the most recent state. - **Best for**: Financial transactions or scenarios requiring maximum durability where longer restart times are acceptable. ### RDB (Redis Database Snapshots): Fast Recovery **RDB snapshots** capture point-in-time copies of the entire dataset. The main process forks a child process (`bgsave`) that writes the snapshot while the parent continues processing writes, utilizing copy-on-write memory sharing. - **Write latency**: Minimal impact. Snapshots run in the background via forked processes. - **Recovery**: Very fast. The binary snapshot loads directly into memory without replaying individual commands. - **Best for**: Large caches where startup time is critical and occasional data loss of recent writes (between snapshots) is acceptable. ### Mixed Mode: The Production Standard Most production deployments enable **both AOF and RDB** simultaneously. On restart, Redis first loads the latest RDB snapshot for quick initialization, then replays the AOF log to bring the dataset up-to-date. - **Write latency**: Combines background snapshots with asynchronous AOF writes. - **Recovery**: Two-step process offering the fastest balance between speed and data freshness. - **Best for**: General production systems requiring both quick restarts and minimal data loss. ## Key Architectural Insights The persistence implementation in Redis reflects several critical design decisions that balance speed with durability. ### In-Memory Primary Store All reads and writes operate exclusively in RAM. Persistence remains a secondary concern handled by background processes, preserving Redis's hallmark sub-millisecond latency. ### Background Processing with Copy-on-Write Both AOF rewriting (`BGREWRITEAOF`) and RDB snapshotting (`BGSAVE`) execute in forked child processes. This leverages the **copy-on-write** mechanism to avoid blocking the main thread while ensuring point-in-time consistency. ### Write-After Logging Architecture AOF logs commands **after** they modify the in-memory state, ensuring the critical path never stalls waiting for disk I/O. The log stores Redis commands rather than raw data pages, simplifying recovery logic but increasing replay time for large operation histories. ### Configurable Durability Levels The `appendfsync` setting controls fsync frequency: - **`always`**: Fsync on every write (maximum durability, higher latency) - **`everysec`**: Fsync once per second (common compromise) - **`no`**: Let the OS handle syncing (fastest, least durable) ## Configuration and Code Examples Enable and manage persistence using these configuration snippets and CLI commands from the ByteByteGoHq/system-design-101 guides. Enable AOF persistence in [`redis.conf`](https://github.com/ByteByteGoHq/system-design-101/blob/main/redis.conf): ```bash appendonly yes appendfsync everysec ``` Trigger RDB snapshots manually: ```bash # Synchronous save (blocks main thread) redis-cli SAVE # Asynchronous snapshot (forks child process) redis-cli BGSAVE ``` Compact AOF files to prevent unbounded growth: ```bash redis-cli BGREWRITEAOF ``` Verify runtime persistence configuration: ```bash redis-cli CONFIG GET appendonly redis-cli CONFIG GET save ``` Example mixed persistence configuration: ```bash # redis.conf save 900 1 # Snapshot every 15 minutes if ≥1 key changed save 300 10 # Snapshot every 5 minutes if ≥10 keys changed appendonly yes appendfsync everysec ``` ## Operational Trade-offs Choosing between persistence strategies requires balancing competing system requirements. ### Latency versus Durability Enabling AOF with `appendfsync always` adds hundreds of microseconds per write, potentially impacting high-QPS workloads. The `everysec` policy offers a practical compromise for most use cases. ### Recovery Time versus Data Loss RDB snapshots load instantly but may lose data since the last snapshot interval (configurable via `save` directives). AOF preserves nearly all data but requires sequential log replay, extending restart times for high-volume instances. ### Storage Overhead AOF files grow continuously because they store every command. Periodic `BGREWRITEAOF` operations compact the log but temporarily double disk usage during the rewrite process. RDB files remain compact binary snapshots. ### Operational Complexity Managing both mechanisms requires tuning snapshot intervals, scheduling AOF rewrites, and monitoring forked processes for memory bloat. The mixed approach, while robust, increases the surface area for configuration errors. ## Summary - Redis offers three persistence modes: **AOF** for durability, **RDB** for speed, and **mixed** for production balance. - AOF uses write-after logging where commands are stored after in-memory execution, ensuring non-blocking writes. - RDB utilizes **copy-on-write** forking via `BGSAVE` to create point-in-time snapshots without stopping the main thread. - The `appendfsync` configuration directly controls the latency-durability trade-off. - Production deployments typically use mixed persistence, loading RDB snapshots first then replaying AOF logs for optimal recovery speed and data freshness. - Background processes like `BGREWRITEAOF` prevent AOF files from growing indefinitely but require monitoring for temporary disk space usage. ## Frequently Asked Questions ### What is the difference between AOF and RDB in Redis? **AOF (Append-Only File)** logs every write command sequentially, providing maximum durability but slower recovery times due to log replay. **RDB (Redis Database Snapshots)** creates compact binary point-in-time snapshots using forked processes, enabling fast restarts but potentially losing data since the last snapshot. According to the source analysis in [`data/guides/how-does-redis-persist-data.md`](https://github.com/ByteByteGoHq/system-design-101/blob/main/data/guides/how-does-redis-persist-data.md), AOF is preferred for durability-critical applications while RDB suits large caches where fast startup matters more than recent data loss. ### How does Redis handle persistence without blocking the main thread? Redis leverages **copy-on-write** forking to execute persistence tasks in background child processes. When running `BGSAVE` for RDB snapshots or `BGREWRITEAOF` for log compaction, the main process forks a child that shares memory pages with the parent. The child writes the snapshot or rewrites the AOF file while the parent continues processing client requests, ensuring sub-millisecond latency remains unaffected during persistence operations. ### Which Redis persistence mode should I use for production? Most production systems should use **mixed persistence**, enabling both AOF and RDB simultaneously as detailed in the ByteByteGoHq/system-design-101 guides. This configuration loads the RDB snapshot first for rapid initialization, then replays the AOF log to recover the most recent writes. The combination balances fast restart times with minimal data loss, though it requires monitoring disk usage and tuning `save` intervals alongside `appendfsync` policies. ### How often should I run BGREWRITEAOF? Run `BGREWRITEAOF` when AOF files grow significantly larger than their corresponding RDB snapshots or when disk space concerns arise. Redis can trigger this automatically based on the `auto-aof-rewrite-percentage` and `auto-aof-rewrite-min-size` configuration parameters. Manual execution via `redis-cli BGREWRITEAOF` is useful before maintenance windows or when you observe AOF files consuming excessive storage, though note the process temporarily doubles disk usage during the rewrite.