Master DevOps Tools & Best Practices - DevOps Knowledge Hub Master DevOps Tools & Best Practices - DevOps Knowledge Hub

Redis Persistence Options: RDB vs. AOF Explained

Master the critical choice between Redis RDB (snapshotting) and AOF (append-only file) persistence. This guide details how each method captures and recovers data, compares their performance and durability trade-offs, and explains why enabling both strategies is often the best practice for production environments.

Redis Persistence Options: RDB vs. AOF Explained

Redis persistence decides how much data your Redis server can recover after a restart or crash. The two main options are RDB snapshots and AOF logs, and the right choice depends on how much recent data your application can afford to lose.

Redis keeps data in memory for speed. Persistence writes enough state to disk so Redis can rebuild that data later. You can use RDB, AOF, both, or neither, but production systems should make that choice deliberately.

Understanding Redis Persistence

Persistence in Redis refers to the process of writing the current state of the in-memory dataset to disk. This allows Redis to reload the data when the server restarts. Without persistence enabled, all data is lost upon shutdown.

Redis supports both RDB and AOF simultaneously, offering a hybrid approach that combines the best features of both.

RDB Snapshots

RDB creates point-in-time snapshots of your dataset and writes them to a compact binary file, commonly named dump.rdb.

How RDB Works

RDB normally works by forking the Redis process. The child process writes the dataset to disk while the parent keeps serving clients. Because RDB is a snapshot, it captures data as it existed at one moment.

Configuration and Snapshotting

RDB configuration is managed with save directives in redis.conf. These directives define when Redis should create an automatic snapshot:

# Save the DB if 1000 keys changed in 1 minute
save 600 1000
# Save the DB if 10 keys changed in 10 minutes
save 300 10
# Save the DB if 10000 keys changed in 1 second
save 1 10000

To disable automatic RDB snapshots, remove the save directives or set:

save ""

You can still trigger a manual background snapshot with BGSAVE when you need one.

Advantages of RDB

  • Compact files: RDB files are efficient for backups, copies, and disaster recovery archives.
  • Fast recovery: Loading one snapshot is usually faster than replaying a long command log.
  • Lower steady write overhead: Redis does not write every command to the persistence file.

Disadvantages of RDB

  • Data loss risk: If Redis crashes between snapshots, writes after the last successful snapshot are lost.
  • Forking overhead: Large datasets can make fork() expensive and may cause latency spikes.
  • Not a full audit log: RDB stores final state, not every write that led to it.

AOF Logs

AOF (Append-Only File) offers a higher level of data durability. Instead of snapshots, AOF logs every write operation received by the server in an append-only format.

How AOF Works

When AOF is enabled, Redis records write commands such as SET, HSET, and LPUSH to an append-only file. On restart, Redis replays that file to rebuild the dataset.

AOF Configuration

AOF persistence is disabled by default and must be explicitly enabled in redis.conf:

appendonly yes

Crucially, AOF allows configuration of the fsync policy, determining how frequently writes are forced to disk:

fsync Policy Description Durability vs. Performance
no OS handles synchronization (least frequent). Fastest, highest risk of loss.
everysec Synchronize about once per second. Good balance. Usually limits loss to about one second during a server crash.
always Synchronize after every command. Highest durability, potentially significant performance hit.

Advantages of AOF

  • Higher durability: appendfsync everysec is a common production balance; always is stricter but slower.
  • Readable intent: AOF stores write commands, so it can be easier to inspect than an RDB binary file.
  • Automatic compaction: AOF rewrite can shrink a large log into the minimal commands needed to rebuild current state.

Disadvantages of AOF

  • Larger files: AOF files are often larger than RDB snapshots because they store commands.
  • Slower restart: Replaying a long AOF can take longer than loading an RDB snapshot.
  • More write overhead: Redis has to append write commands and sync them according to your appendfsync setting.

AOF Rewriting

To combat file size growth, Redis implements AOF rewriting. This process asynchronously creates a new, optimized AOF file containing only the commands necessary to reach the current state, effectively discarding redundant or obsolete commands (like multiple updates to the same key).

RDB vs. AOF: Direct Comparison

Choosing between RDB, AOF, or both depends entirely on your application's requirements for recovery time and data loss tolerance.

Feature RDB (Snapshotting) AOF (Append-Only File)
Durability/Data Loss Higher potential data loss (since last save). Minimal data loss (down to 1 second, or zero with fsync=always).
File Size Very compact and optimized. Larger due to command logging.
Restart Time Very fast loading of the snapshot. Slower, requires command replay.
Complexity Simple, configured by time intervals. Requires careful configuration of fsync policy.
Use Case Backups, disaster recovery where recent data loss is tolerable. Primary persistence mechanism requiring high durability.

Best Practice: Combining RDB and AOF

For many production deployments, enabling both RDB and AOF gives you a useful safety net.

When both are enabled:

  1. AOF provides the primary, high-durability log.
  2. RDB provides a fast, compact backup snapshot.

When both are enabled, Redis loads the AOF on restart because it is usually more complete than the last RDB snapshot. RDB still gives you compact backup files that are easy to copy, test, and archive.

How to Enable Both

Ensure both configurations are set in redis.conf:

# Enable AOF
appendonly yes

# Keep RDB configuration (e.g., autosave every hour)
save 3600 1

# Recommended fsync policy for AOF
appendfsync everysec

Tip on AOF Rewriting: You can manually trigger an AOF rewrite at any time using the command BGREWRITEAOF. This is especially useful after large bulk data loads or significant purging operations to immediately shrink the AOF file size.

Takeaway

Use RDB when you want compact backups and can tolerate losing recent writes since the last snapshot. Use AOF when Redis holds data that should survive crashes with minimal loss. For important production data, enable AOF with appendfsync everysec, keep RDB snapshots for backup, and test restore time before an outage forces the question.