Redis Persistence: RDB Snapshots vs AOF

Redis keeps data in memory. Whether anything survives a restart depends on its persistence settings, and the right choice depends on how you use Redis.

RDB: point-in-time snapshots

# redis.conf
save 3600 1      # snapshot if at least 1 change in an hour
save 300 100     # ...or 100 changes in 5 minutes
save 60 10000    # ...or 10,000 changes in a minute

• Compact single file, fast restarts, easy to back up.
• You lose everything written since the last snapshot if Redis crashes.
• Snapshots fork the process; on large datasets this needs spare memory.

AOF: log every write

appendonly yes
appendfsync everysec    # fsync once per second (the usual choice)
# appendfsync always    # fsync every write: safest, slowest
# appendfsync no        # let the OS decide: fastest, least safe

• With everysec, at most about one second of writes is lost on a crash.
• The log is rewritten (compacted) in the background as it grows.
• Larger on disk and slightly slower restarts than RDB.

Both together

Enabling RDB and AOF is a common production setup: AOF for durability, RDB files for easy backups and fast copying to other servers.

Choosing by use case

• Pure cache (data can be rebuilt from the database): persistence can be off entirely. Restarts start cold, which is acceptable.
• Sessions, rate limits, queues: AOF with everysec, so a restart doesn't log everyone out or lose jobs.
• Primary data store: AOF plus RDB backups copied off the server, plus replication, and a clear understanding that one second of loss is possible.

Persistence is not high availability

Disk persistence protects against restarts. To survive a server failure, add replicas with automatic failover (Sentinel, Redis Cluster or a managed service). And keep backups: replication happily copies a mistaken FLUSHALL to every replica.