Core Concepts of Redis Persistence

Redis operates primarily in volatile memory to achieve low-latency data access. To prevent data loss during unexpected terminations or system failures, the in-memory state must be peirodically transferred to non-volatile storage. This synchronization process is known as persistence. Redis provides two distinct strategies for this purpose: the Redis Database (RDB) snapshot and the Append-Only File (AOF) log. These mechanisms can operate independently or be combined to balance throughput and durability.

The Snapshot Approach (RDB)

RDB captures the entire dataset at a specific point in time and serializes it into a compact binary file. When a Redis instance restarts, it parses this snapshot to reconstruct the in-memory state.

Execution Triggers

Snapshot generation occurs under four primary conditions:

• Manual invocation via the SAVE command (synchronous, blocks the main process)
• Manual invocation via the BGSAVE command (asynchronous, non-blocking)
• Graceful shutdown of the Redis service
• Automatic execution based on predefined time and modification thresholds

Internal Workflow & Memory Optimization

When an asynchronous snapshot is requested, the main process spawns a child process using the operating system's fork mechanism. The parent continues handling client requests, while the child handles the persistence workload. The child writes the dataset to a temporary file and atomically replaces the previous snapshot upon completion.

This design leverages the Copy-On-Write (CoW) memory management technique to minimize performance overhead:

• Shared Read Access: Initially, the parent and child processes reference the same physical memory pages.
• Isolated Write Access: When the parent modifies a memory page, the OS creates a private copy for the parent. The child retains the original page, ensuring a consistent view of the dataset during the dump.

Performance Characteristics

• High efficiency: The parent process avoids disk I/O during the dump, maximizing client throughput.
• Compact storage: RDB files are significantly smaller than AOF logs, making them ideal for backups and disaster recovery.
• Faster restoration: Loading a single binary file is much quicker than replaying a sequential command log.
• Data loss window: Since snapshots occur at intervals, any writes performed after the last dump will be lost during a crash.

The Append-Only File Approach (AOF)

Instead of capturing periodic snapshots, AOF records every write command received by the server. Read operations are ignored. The system appends these instructions to a log file, which Redis replays during startup to reconstruct the dataset.

Operational Workflow

1. Incoming write requests are queued in an AOF buffer.
2. The buffer flushes to disk based on the configured fsync policy (always, everysec, or no).
3. When the log exceeds size thresholds or is manually triggered, a background rewrite compacts the file.
4. During recovery, Redis executes the logged commands sequentially to restore the original state.

Background Rewrite Mechanism

Because AOF logs accumulate every write operation, the file size can grow substantially. For example, executing SET counter 10, then SET counter 20, and finally SET counter 30 results in three log entries, even though only the final value matters.

To address this, Redis employs a background rewrite process. Instead of parsing the existing log, the background process scans the current in-memory dataset and generates a minimal set of commands to recreate the exact state. The previous example would be compressed into a single operation: MSET counter 30. The new compacted log is written to a temporary file and atomically renamed once complete.

Automatic Rewrite Triggers

The rewrite process activates automatically when two configuration conditions are met simultaneously:

auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage 100

This configuration ensures that rewriting only occurs when the file reaches a minimum baseline (e.g., 64 megabytes) and has grown by a specified margin (e.g., 100%) since the last compaction. This prevents excessive I/O overhead on small or frequently updated datasets.

Performance Characteristics

• Enhanced durability: Depending on the fsync policy, data loss is limited to approximately one second or zero operations.
• Auditability: The log file is plain text and follows the Redis protocol, making it easy to inspect or parse manually.
• Higher overhead: Continuous logging and disk synchronization consume more CPU and I/O resources compared to RDB.
• Larger footprint: AOF files are typically larger than RDB snapshots, even after compaction, and require periodic background maintenance.

Comparative Analysis & Implementation Strategy

Selecting the appropriate persistence strategy depends on the application’s recovery point objective (RPO) and recovery time objective (RTO).

• Prioritize RDB: Choose this if disk space is constrained, faster crash recovery is critical, and occasional data loss within a few minutes is acceptable.
• Prioritize AOF: Choose this if data integrity is paramount and losing even a few seconds of transactions is unacceptable.
• Hybrid Deployment: Modern Redis configurations often enable both mechanisms. AOF handles daily durability and fault tolerance, while RDB serves as a lightweight backup for cross-region replication or cold storage. The official guidelines generally recommend activating both to leverage the strengths of each approach.