← Blogs

Redis Persistence: AOF and RDB

References: Xiaolin Coding video and Redis persistence documentation.

Append-Only File (AOF)

AOF records write operations after Redis applies them in memory. Redis can replay the log at startup to reconstruct the dataset. The log uses the Redis protocol format, so it is generally larger than an RDB snapshot.

Why Log After Executing a Command?

Redis records a write only after it has accepted and executed it. Appending and syncing the log still have a cost; the chosen appendfsync policy determines the durability and performance tradeoff.

Configuration

1
2
3

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

The location and layout of AOF files depend on the Redis version. Redis 7 and later use a multipart AOF with a manifest, a base file, and incremental files.

AOF writeback

Sync Policies

  • appendfsync always: Sync each write to disk before acknowledging it. This offers stronger durability at a higher I/O cost.
  • appendfsync everysec: Sync about once a second. A crash can lose roughly the latest second of writes.
  • appendfsync no: Leave syncing to the operating system. The potential loss window is larger and depends on OS writeback behavior.

AOF Rewrite

As commands accumulate, the AOF can become much larger than the current dataset. A rewrite creates a compact representation of the current state rather than keeping the entire command history.

  1. Redis starts a background child process using BGREWRITEAOF.
  2. The child writes a new base representation of the dataset while the parent continues serving writes.
  3. On Redis 7+, new writes go to a new incremental AOF file. When the rewrite finishes, Redis updates the manifest to switch to the new base and incremental files.

Older Redis versions used a rewrite buffer and appended writes made during the rewrite to the new AOF before replacing the old one. A separate output file protects the existing AOF if the rewrite fails.

Forking and copy-on-write allow the child to see a consistent snapshot without stopping all client traffic. Forking, memory pressure from copy-on-write, and the final switch can still cause latency spikes.

RDB Snapshots

RDB stores a point-in-time snapshot in a compact binary file. With BGSAVE, Redis forks a child to write a temporary RDB file while the parent continues to serve requests. Copy-on-write gives the child a stable view: memory pages are shared until the parent changes them. Once the snapshot is complete, Redis atomically replaces the previous snapshot file.

RDB files are compact and quick to load. The tradeoff is that writes since the most recent snapshot can be lost after a crash.

RDB snapshot

Save Rule

1

save 300 10

This schedules a snapshot when at least 10 changes have occurred within 300 seconds. Frequent full snapshots increase disk and fork overhead.

RDB and AOF Together

Redis can use an RDB preamble for a rewritten AOF: the base contains a compact snapshot, followed by incremental AOF commands. This combines faster startup with a more complete record of recent writes. If both RDB and AOF persistence are enabled, Redis uses AOF on restart because it is usually the more complete record.

1

aof-use-rdb-preamble yes