Configuring Redis Persistence: RDB and AOF for Fault Tolerance

By default, Redis is an in-memory database. On restart, all data is lost. For most scenarios, that's fine if Redis is used only as a cache. But if Redis stores task queues, sessions, counters, or other data that cannot be lost—you need persistence. We've encountered this on nearly every second project: without RDB or AOF, clients lost operational data and had to manually restore from backups. For example, on a project with task queues, we lost up to 5 minutes of data between RDB snapshots, leading to duplicate orders. After implementing AOF with everysec, losses dropped to 1 second. Configuring Redis Persistence is a basic task for any production service with data durability requirements. Let's examine both mechanisms and their combined use.

There are two mechanisms: RDB (snapshots) and AOF (append-only file). They can be used individually or together. Proper configuration is the foundation of reliable recovery with at most one second of data loss.

How RDB works

RDB saves a full snapshot of the data into a binary file dump.rdb. Configuration via the save directive:

save 900 1 save 300 10 save 60 10000 

This means: save if at least 1 key changed in 900 seconds, or 10 keys in 300 seconds, or 10000 keys in 60 seconds. On restart, Redis loads the latest dump.rdb.

The main drawback of RDB is data loss between snapshots. If Redis crashes 5 minutes before the next snapshot, you lose 5 minutes of changes. This is critical on high-load projects.

According to the official Redis documentation, a snapshot is performed via fork()—a child process writes data to disk while the parent continues handling requests. During fork(), Redis may experience slight latency spikes—on a large dataset (10+ GB) this can be several seconds. Critical for low-latency applications.

Manual snapshot without blocking: BGSAVE. With blocking (for backup): SAVE.

What is AOF?

AOF writes every write command to a log file. On restart, Redis replays the entire AOF to recover data.

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

appendfsync is the key parameter:

• always – fsync after every command. Maximum reliability, minimum speed.
• everysec – fsync every second. Maximum of 1 second data loss on failure. Balance of reliability and performance.
• no – fsync determined by OS. Fast, but data loss is unpredictable.

everysec is the right choice for most cases.

AOF grows over time. auto-aof-rewrite-percentage 100 means: when the file doubles relative to its size after the last rewrite, trigger BGREWRITEAOF, which creates a compact AOF only with the current commands (without intermediate SET/DEL of the same key).

Why use both mechanisms together?

When both mechanisms are enabled, on restart Redis uses AOF (more precise). RDB remains as a fast snapshot for backups.

save 900 1 appendonly yes appendfsync everysec 

This is the recommended configuration for production where data durability matters. We use this on 80% of our projects, including high-load services.

How to choose between RDB and AOF?

Compare key parameters:

Tailored to specific scenarios:

For pure cache scenario

If Redis is a pure cache and data can be warmed up on restart:

save "" appendonly no 

Disable all persistence mechanisms. Redis will be faster (no disk I/O), and fork() for snapshots won't cause latency spikes. Savings in CPU and RAM – up to 30% depending on load.

How we configure Redis Persistence end-to-end

The process takes 2 to 3 days depending on data volume and fault tolerance requirements:

1. Load analysis and scenario mapping – determine if persistence is needed, select mechanisms.
2. Configuration – set save intervals, AOF parameters, rewrite, fsync.
3. Recovery testing – simulate failure, verify data recovers within expected time.
4. Monitoring – add metrics (RDB duration, AOF rewrite, fork latency) to Prometheus/Grafana.
5. Documentation and training – document runbook for on-call team.

What's included in the work

• Configuring RDB and AOF via Ansible (Terraform).
• Performance and recovery tests (results in report).
• Monitoring: Grafana dashboards, alerts for fork latency.
• Runbook documentation: how to check, restart, troubleshoot.
• Team training: 1 hour online session with demonstration.

Common configuration mistakes

• Using appendfsync always unnecessarily – causes 10x drop in IOPS.
• Too frequent save (every 60 seconds with 10k changes) – disk overload.
• Forgetting about AOF rewrite – file grows to tens of gigabytes.
• Setting stop-writes-on-bgsave-error no – risk of data loss on snapshot failure.

Guarantees and experience

The cost of configuration is calculated individually based on architecture complexity. We guarantee data recovery within the specified RTO/RPO provided logs are intact. With over 5 years of Redis experience and 50+ successful production projects, we deliver reliable persistence. To evaluate your project, contact us – we'll select the optimal configuration and test it on your staging environment. Get a consultation today.

Order Redis Persistence configuration from experienced engineers – ensure your service's fault tolerance.