How to Prevent Redis Data Loss: In‑Depth RDB and AOF Backup Strategies

Problem background and failure scenarios

Redis stores all data in memory, so power loss, process crashes, accidental FLUSHALL / DEL, or master‑slave failover can cause data loss. Typical use cases such as user sessions, verification codes, distributed locks, and order state rely on Redis persistence to avoid service disruption.

Why persistence matters

Without any persistence, any of the above events results in total data loss. Choosing the right persistence mechanism balances performance against reliability.

RDB snapshot mechanism

How RDB works

When a snapshot is triggered, Redis forks a child process. The child reads the in‑memory dataset and writes a compact binary file ( dump.rdb) while the parent continues serving requests. The fork uses copy‑on‑write, so the pause is usually a few hundred milliseconds.

RDB advantages and disadvantages

Advantages : Small binary file, fast bulk restore, low runtime overhead, ideal for daily full backups.

Disadvantages : Data written after the last snapshot is lost on crash; large datasets can cause noticeable fork latency; format changes between major versions may affect compatibility.

Key RDB configuration

# RDB file name
 dbfilename dump.rdb
# Directory for RDB files
 dir /var/lib/redis
# Automatic snapshot triggers (default)
 save 900 1   # 15 min if at least 1 write
 save 300 100 # 5 min if at least 100 writes
 save 60 10000 # 1 min if at least 10 000 writes
# Stop writes if BGSAVE fails
 stop-writes-on-bgsave-error yes
# Enable LZF compression (CPU cost, smaller file)
 rdbcompression yes
# Add CRC64 checksum for integrity
 rdbchecksum yes

RDB trigger methods

Automatic : The save rules are OR‑combined; satisfying any rule starts a background BGSAVE.

Manual : redis-cli BGSAVE (asynchronous) or redis-cli SAVE (synchronous, blocks all clients).

RDB recovery flow

Redis reads dir and dbfilename from the configuration.

It loads the file /var/lib/redis/dump.rdb (or the path built from the two parameters).

If the file is complete, the server starts with the restored dataset.

AOF append‑only file mechanism

How AOF works

Every write command (e.g., SET key value) is appended to appendonly.aof. On restart, Redis replays the file to rebuild the dataset.

fsync strategies

always : fsync after each write – safest but slowest (≈10 k writes/s).

everysec (default): fsync once per second – balances safety (≤1 s loss) and performance.

no : OS decides – fastest but no durability guarantee.

AOF rewrite

Because the file grows with every command, Redis can rewrite it to contain only the minimal set of commands needed to reach the current state.

# Assume the following operations were executed
SET name "Alice"
SET name "Bob"
SET name "Charlie"
HSET user:1 name "Alice" age 30
HSET user:1 name "Bob"

After rewrite the file contains only the final state:

SET name "Charlie"
HSET user:1 name "Bob" age 30

AOF advantages and disadvantages

Advantages : Near‑zero data loss with everysec, human‑readable, can be truncated safely.

Disadvantages : Larger than RDB, slower restore (command replay), possible CPU bottleneck on high write loads, file can be corrupted on abrupt power loss.

Key AOF configuration

# Enable AOF
 appendonly yes
appendfilename "appendonly.aof"
# Sync strategy (recommended)
 appendfsync everysec
# Auto‑rewrite when file doubles in size
 auto-aof-rewrite-percentage 100
 auto-aof-rewrite-min-size 64mb
# Load truncated files to recover as much as possible
 aof-load-truncated yes
# Use hybrid persistence (Redis 4.0+)
 aof-use-rdb-preamble yes

Hybrid persistence (Redis 4.0+)

During an AOF rewrite, Redis writes an RDB‑format header followed by incremental commands. This gives fast RDB‑style restores while keeping AOF’s durability.

Enabling hybrid persistence

aof-use-rdb-preamble yes

Data‑loss scenario analysis

The article classifies loss situations (process crash, power loss, accidental flush, master‑slave failover) and estimates maximum data loss for each persistence combination. For example, with only everysec AOF the loss window is ≤1 second, while RDB‑only with a 15‑minute snapshot can lose up to 15 minutes of writes.

Loss estimates for common configurations

Configuration                     Failure window   Max data loss
---------------------------------------------------------------
No persistence                     All               All data
RDB (15 min snapshot)              0‑15 min          ≤15 min
RDB (5 min snapshot)               0‑5 min           ≤5 min
AOF (everysec)                     0‑1 s            ≤1 s
AOF (always)                        0                Near‑zero
RDB + AOF (everysec)               0‑1 s            Usually <1 s

Practical backup and recovery

RDB backup script example

#!/bin/bash
BACKUP_DIR="/data/redis_backup"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/dump_$DATE.rdb"
redis-cli BGSAVE
while [ $(redis-cli LASTSAVE) -ne $(date +%s) ]; do sleep 1; done
cp /var/lib/redis/dump.rdb $BACKUP_FILE
if [ -s $BACKUP_FILE ]; then
  echo "Backup successful: $BACKUP_FILE"
else
  echo "Backup failed"
  exit 1
fi

AOF backup script example

#!/bin/bash
BACKUP_DIR="/data/redis_backup"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/appendonly_$DATE.aof"
cp /var/lib/redis/appendonly.aof $BACKUP_FILE
if [ -s $BACKUP_FILE ]; then
  echo "AOF backup successful: $BACKUP_FILE"
else
  echo "AOF backup failed"
  exit 1
fi

Combined backup script (RDB + AOF + metadata)

#!/bin/bash
set -e
REDIS_DATA_DIR="/var/lib/redis"
BACKUP_ROOT="/data/redis_backup"
DATE=$(date +%Y%m%d)
TARGET="$BACKUP_ROOT/$DATE"
mkdir -p $TARGET
# Trigger snapshot and wait
redis-cli BGSAVE
while [ $(redis-cli LASTSAVE) -lt $(date +%s) ]; do sleep 1; done
cp $REDIS_DATA_DIR/dump.rdb $TARGET/dump_$DATE.rdb
if [ -f $REDIS_DATA_DIR/appendonly.aof ]; then
  cp $REDIS_DATA_DIR/appendonly.aof $TARGET/appendonly_$DATE.aof
fi
# Record server info for later verification
redis-cli INFO server > $TARGET/redis_info.txt

Recovery steps

Stop the Redis service ( systemctl stop redis or redis-cli SHUTDOWN NOSAVE).

Backup the current data files ( mv dump.rdb dump.rdb.bak, mv appendonly.aof appendonly.aof.bak).

Copy the desired backup files into the data directory.

Ensure correct ownership ( chown redis:redis dump.rdb appendonly.aof).

Start Redis and verify with redis-cli PING, redis-cli DBSIZE, and sample KEYS * commands.

Repairing a corrupted AOF

If Redis refuses to start because the AOF is truncated, use the built‑in tool:

# Backup corrupted file first
cp appendonly.aof appendonly.aof.bak
# Fix the file
redis-check-aof --fix appendonly.aof

Configuration templates for different requirements

High‑reliability (zero data loss)

bind 0.0.0.0
port 6379
protected-mode yes
requirepass <code>YOUR_PASSWORD</code>

dir /var/lib/redis
dbfilename dump.rdb
appendonly yes
appendfilename "appendonly.aof"
appendfsync always
aof-use-rdb-preamble yes

save 900 1
save 300 100
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

maxmemory 10gb
maxmemory-policy allkeys-lru

rename-command FLUSHALL ""
rename-command FLUSHDB ""

Balanced performance & reliability

appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
save 300 100
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
maxmemory 20gb
maxmemory-policy allkeys-lru

Pure cache (no persistence)

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

Monitoring and best practices

Run redis-cli INFO persistence regularly; watch rdb_last_save_time, aof_current_size, and aof_last_write_status.

Schedule periodic full backups (daily RDB copy, hourly AOF copy) and test restores in a staging environment.

Never rely on master‑slave replication as a backup; treat it as high‑availability only.

Secure the instance with requirepass, protected-mode, and rename dangerous commands.

Decision guide

Select the persistence strategy based on the tolerated data‑loss window:

If loss of a few seconds is acceptable → enable appendonly yes with appendfsync everysec.

If loss of minutes is acceptable → combine RDB snapshots (e.g., every 5 min) with appendfsync everysec.

If any loss is unacceptable → use appendfsync always plus master‑slave replication, external backups, and optionally hybrid persistence.

Regular backup drills, monitoring of persistence metrics, and secure configuration are essential to keep Redis data safe in production.