Understanding Redis Persistence: AOF vs RDB Mechanisms

When asked about Redis usage scenarios, many mention caching, but a critical issue is data loss if the server crashes because data resides only in memory.

Redis provides two persistence mechanisms: Append Only File (AOF) logs and Redis DataBase (RDB) snapshots. AOF records every command after it has been executed, while RDB creates point‑in‑time snapshots of the dataset.

AOF works as a write‑behind log. Unlike traditional write‑ahead logs such as Write Ahead Log, WAL , AOF logs commands only after they succeed, avoiding syntax checks and preventing erroneous commands from being recorded. This reduces blocking of write operations, but introduces two risks: (1) a command executed but not yet logged can be lost on crash, and (2) the log‑write to disk may become a bottleneck, potentially blocking subsequent operations.

Redis offers three appendfsync write‑back strategies: Always (synchronous write after each command), Everysec (buffered write every second), and No (OS decides when to flush). Choosing a strategy balances performance against data‑loss tolerance.

AOF also supports a rewrite mechanism to prevent the log file from growing indefinitely. The background process bgrewriteaof forks a child process that creates a new compacted AOF file while the main thread continues handling new commands, ensuring no data loss during rewrite.

RDB creates snapshots using the save or bgsave commands. save blocks the main thread, whereas bgsave forks a child process, leveraging copy‑on‑write ( Copy-On-Write, COW ) to write the snapshot without blocking ongoing writes.

Because frequent full snapshots can cause heavy disk I/O and fork‑induced blocking, Redis 4.0 introduced a hybrid approach: periodic RDB snapshots combined with AOF logging of commands between snapshots. This reduces snapshot frequency, limits AOF size, and mitigates performance impact.

In summary, choose the persistence strategy based on your requirements: use a mixed AOF + RDB approach when data loss is unacceptable; rely solely on RDB if occasional minute‑level data loss is tolerable; and if using only AOF, prefer the Everysec setting for a balanced trade‑off between reliability and performance.