Redis Persistence: RDB vs AOF and How Not to Lose Data

The short answer: RDB, AOF and which to pick

Redis keeps data in memory and saves it to disk in one of two ways:

• RDB — a periodic snapshot of the whole dataset in a compact binary file.
• AOF (Append Only File) — a log of every write operation, replayed on restart.

Short version: for a cache you can often turn persistence off; for sessions, queues and any data you cannot rebuild, enable AOF and keep RDB for backups.

How RDB works

Based on the save rules, Redis calls fork(): a child process writes the snapshot to disk while the main process keeps serving clients.

# snapshot if at least 1 change in 3600 s,
# 100 changes in 300 s, or 10000 changes in 60 s
save 3600 1 300 100 60 10000
dbfilename dump.rdb

What to keep in mind:

• Anything written after the last snapshot is lost on a crash.
• fork() relies on copy-on-write: while the snapshot runs, modified memory pages are duplicated. Under heavy writes the server needs spare RAM.
• On Linux, the Redis documentation recommends vm.overcommit_memory = 1, otherwise background saves can fail.

How AOF works and fsync policies

Every write command is appended to the log. How often the log is actually flushed to disk is set by appendfsync:

everysec is the default and a sensible trade-off for most workloads.

The log keeps growing, so Redis periodically rewrites it into a compact form (BGREWRITEAOF), also via fork(). Frequency is controlled by auto-aof-rewrite-percentage and auto-aof-rewrite-min-size.

Hybrid mode

With aof-use-rdb-preamble yes, a rewritten AOF starts with an RDB-format snapshot followed only by newer commands. You get RDB-like fast restarts with AOF-level durability. When AOF is enabled, Redis restores data from it on startup.

Memory limits and eviction

maxmemory caps the dataset size, and maxmemory-policy decides what happens when the limit is reached:

• noeviction — new writes return an error, nothing is removed;
• allkeys-lru / allkeys-lfu — least recently or least frequently used keys are removed from all keys;
• volatile-lru / volatile-lfu / volatile-ttl — only keys with a TTL are removed;
• allkeys-random / volatile-random — random keys.

The key point: eviction is also data loss. If Redis holds queues and the policy is allkeys-lru, jobs can vanish with no errors and no crash.

Checklist: Redis as a cache

maxmemory 2gb
maxmemory-policy allkeys-lru
save ""
appendonly no

• The application must cope with an empty cache and refill it from the main database.
• Set TTLs on keys.
• If a cold start after a restart is too heavy for the database, keep infrequent RDB snapshots.

Checklist: Redis as the primary store for sessions or queues

appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
save 3600 1 300 100 60 10000
maxmemory 2gb
maxmemory-policy noeviction

• noeviction is a must for queues; for sessions volatile-lru is acceptable if users logging in again is a fair price.
• Monitor memory usage and write errors so the limit is never a surprise.
• Keep spare RAM for fork().
• Copy RDB files to another server or object storage. Replication is not a backup: a deleted key disappears from the replica instantly.
• Regularly test restoring from a backup on a staging server.
• For critical data, add a replica and automatic failover.