Redis Persistence Strategies: RDB Snapshots, AOF Logs & Hybrid Backup Approaches

Introduction

Redis is often categorized as an in-memory data store, but dismissing its persistence capabilities would be a mistake. With 74,000+ GitHub stars and continuous active development (last updated June 2026), Redis supports multiple robust persistence mechanisms that make it suitable for use cases far beyond simple caching — from session stores to primary databases. This guide compares the three main Redis persistence strategies: RDB point-in-time snapshots, AOF (Append-Only File) command logging, and the hybrid approach that combines both. We also explore backup tooling for production-grade data protection.

Understanding Redis Persistence

Redis persistence is not an all-or-nothing choice. The three mechanisms can be used individually or in combination, each offering different trade-offs between durability, performance, and recovery speed.

Comparison Table

Strategy 1: RDB (Redis Database) Snapshots

RDB persistence creates point-in-time snapshots of your dataset at specified intervals. Redis forks a child process that writes the entire in-memory dataset to a compact binary file (dump.rdb). The parent process continues serving requests without interruption.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# redis.conf — RDB configuration
save 900 1       # Save if at least 1 key changed in 15 minutes
save 300 10      # Save if at least 10 keys changed in 5 minutes
save 60 10000    # Save if at least 10000 keys changed in 1 minute

# RDB file location
dir /var/lib/redis/
dbfilename dump.rdb

# Compression (trade CPU for disk space)
rdbcompression yes

# CRC64 checksum for corruption detection
rdbchecksum yes

Manual snapshot triggering:

1
2
3
4
5
6
7
8

# Synchronous — blocks until complete
redis-cli SAVE

# Asynchronous — forks child process (preferred for production)
redis-cli BGSAVE

# Schedule BGSAVE via cron
0 */6 * * * redis-cli BGSAVE

Verifying RDB integrity:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Check RDB file for corruption
redis-check-rdb /var/lib/redis/dump.rdb

# Output example:
# [offset 0] Checking RDB file dump.rdb
# [offset 26] AUX FIELD redis-ver = '7.2.4'
# [offset 40] AUX FIELD redis-bits = '64'
# ...
# [offset 524288] Checksum OK
# RDB file is valid

Docker Compose with RDB persistence:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

version: "3.8"
services:
  redis:
    image: redis:7-alpine
    container_name: redis-rdb
    command: redis-server --save 60 1000 --appendonly no
    volumes:
      - redis-rdb-data:/data
    ports:
      - "6379:6379"
    restart: always

volumes:
  redis-rdb-data:

Key advantage: RDB files are compact, portable, and perfect for disaster recovery. You can copy a single file to any Redis instance and restore within seconds. They’re also ideal for promoting a replica to primary during failover.

Key limitation: If Redis crashes between snapshots, you lose all writes since the last save. The more frequently you save, the more CPU and I/O you consume on forking — for large datasets (10GB+), fork time can spike to seconds.

Strategy 2: AOF (Append-Only File) Logging

AOF logs every write operation received by the server to a persistent file. On restart, Redis replays the log to reconstruct the dataset. This provides much stronger durability guarantees than RDB at the cost of larger files and slightly slower recovery.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# redis.conf — AOF configuration
appendonly yes
appendfilename "appendonly.aof"

# Fsync policy — the critical durability/performance trade-off
appendfsync everysec    # Fsync once per second (recommended)
# appendfsync always    # Fsync every write (slowest, most durable)
# appendfsync no         # Let OS handle fsync (fastest, least durable)

# Automatic AOF rewrite (compacts the log)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

The three fsync policies explained:

AOF rewrite — keeping the log manageable:

Over time, the AOF file grows with every write command. BGREWRITEAOF creates a compact version containing only the minimal set of commands to reconstruct the current dataset:

1
2
3
4
5
6
7
8

# Manual rewrite (non-blocking)
redis-cli BGREWRITEAOF

# Check AOF status
redis-cli INFO persistence
# aof_current_size:157286400
# aof_base_size:104857600
# aof_rewrite_in_progress:0

Multi-part AOF (Redis 7.0+):

Redis 7.0 introduced multi-part AOF, storing the base file and incremental changes separately:

1
2
3
4
5

appenddirname "appendonlydir"
# Creates:
# appendonlydir/appendonly.aof.1.base.rdb   # Base RDB-style snapshot
# appendonlydir/appendonly.aof.1.incr.aof   # Incremental AOF changes
# appendonlydir/appendonly.aof.manifest     # Manifest file

This hybrid approach combines RDB’s fast loading with AOF’s durability — the base file loads quickly as an RDB, and only the small incremental AOF needs replaying.

Verifying AOF integrity:

1
2
3

redis-check-aof /var/lib/redis/appendonly.aof
# Output: AOF analyzed: size=52428800, ok_up_to=52428800, diff=0
# AOF is valid

Strategy 3: Backup Tools for Production

Beyond Redis’s built-in persistence, third-party tools add automation, compression, and cloud storage integration.

redis-dump — Export to JSON for portability:

1
2
3
4
5
6
7
8

# Install
gem install redis-dump

# Export all keys to JSON
redis-dump -u redis://localhost:6379 > redis-backup.json

# Import from JSON
cat redis-backup.json | redis-load -u redis://localhost:6380

Automated backup script with S3 upload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#!/bin/bash
# /usr/local/bin/redis-backup.sh
BACKUP_DIR="/backups/redis"
RETENTION_DAYS=7

# Trigger BGSAVE
redis-cli BGSAVE

# Wait for save to complete
while [ "$(redis-cli INFO persistence | grep rdb_bgsave_in_progress | cut -d: -f2)" = "1" ]; do
    sleep 1
done

# Copy with timestamp
TIMESTAMP=$(date +%%Y%%m%%d-%%H%%M%%S)
cp /var/lib/redis/dump.rdb "$BACKUP_DIR/redis-$TIMESTAMP.rdb"

# Compress
gzip "$BACKUP_DIR/redis-$TIMESTAMP.rdb"

# Upload to S3 (using awscli or rclone)
aws s3 cp "$BACKUP_DIR/redis-$TIMESTAMP.rdb.gz" "s3://my-backups/redis/"

# Clean old backups
find "$BACKUP_DIR" -name "*.rdb.gz" -mtime +$RETENTION_DAYS -delete

Docker Compose with automated backup sidecar:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

version: "3.8"
services:
  redis:
    image: redis:7-alpine
    container_name: redis-prod
    command: redis-server --save 60 1000 --appendonly yes
    volumes:
      - redis-data:/data
    restart: always

  redis-backup:
    image: alpine:latest
    container_name: redis-backup
    depends_on:
      - redis
    volumes:
      - redis-data:/redis-data:ro
      - redis-backups:/backups
    entrypoint: |
      sh -c '
        apk add --no-cache redis
        while true; do
          redis-cli -h redis BGSAVE
          sleep 5
          cp /redis-data/dump.rdb "/backups/redis-$$(date +%%Y%%m%%d-%%H%%M%%S).rdb"
          find /backups -name "*.rdb" -mtime +7 -delete
          sleep 3600
        done
      '
    restart: always

volumes:
  redis-data:
  redis-backups:

Why Self-Host Redis with Custom Persistence

Managed Redis services (ElastiCache, Memorystore, Upstash) abstract away persistence configuration — but they also abstract away your control. Cloud providers typically set conservative RDB save intervals (often 15 minutes minimum) and may not expose AOF configuration at all. For applications where data consistency matters — user sessions, cart data, rate limit counters — losing up to 15 minutes of writes during a failure is unacceptable.

Self-hosting Redis gives you full control over the persistence strategy. You can tune appendfsync always for financial transaction data while using RDB snapshots for less critical cache content — all on the same instance. Combined with Redis high availability configurations, a self-hosted setup can achieve durability guarantees that rival traditional SQL databases.

For monitoring your persistence health, integrating with Redis management UIs provides visibility into BGSAVE duration, AOF rewrite status, and replication lag. When persistence operations start taking longer than expected, these dashboards alert you before a production incident occurs.

The choice between RDB and AOF is not mutually exclusive — combining both gives you fast disaster recovery via RDB snapshots AND minimal data loss via AOF logging. This is the configuration Redis itself recommends for production deployments, and it’s what we run for our own infrastructure. For advanced analytics on top of Redis data, tools like RedisSearch and RedisTimeSeries extend persistence into the analytics domain.

FAQ

Which persistence method should I use for Redis as a cache?

If data loss is acceptable (as with most caching use cases), disable both RDB and AOF entirely or use RDB with infrequent saves (save 3600 1). This maximizes performance since Redis never forks for snapshots or writes to the AOF. If you need cache warm-up after restart, RDB snapshots every few hours provide a reasonable starting dataset without significant performance impact.

Can I switch from RDB to AOF on a running instance?

Yes, without downtime:

1
2

redis-cli CONFIG SET appendonly yes
redis-cli CONFIG REWRITE  # Persist the change

Redis will generate the initial AOF file in the background. The RDB file remains until you explicitly remove it. Note that this temporarily doubles disk usage until the AOF rewrite completes.

What happens if the AOF file gets corrupted?

Redis includes the redis-check-aof utility to repair truncated AOF files. If the last command was incompletely written (e.g., during a power failure), the tool can trim the file to the last valid command:

1

redis-check-aof --fix appendonly.aof

For severely corrupted files, restore from the most recent RDB snapshot and replay the AOF from that point.

How much memory overhead does BGSAVE add?

BGSAVE uses Linux’s copy-on-write fork mechanism. The memory overhead depends on write activity during the save — every modified page requires a copy. Under heavy write loads during a BGSAVE, memory usage can temporarily double. The rule of thumb: ensure at least 50% free memory for the fork overhead on write-heavy instances (>10K ops/sec).

Can I use both RDB and AOF simultaneously?

Yes, and this is the recommended production configuration. When both are enabled, Redis uses the AOF on restart (since it’s more durable) but also maintains RDB snapshots for disaster recovery and replica synchronization. With Redis 7.0’s multi-part AOF, the AOF base file is already in RDB format, making this combination even more efficient.

How do I backup a very large Redis instance (100GB+)?

For large instances, BGSAVE can take minutes and consume significant memory for the fork. Strategies:

1. Use a replica: Run BGSAVE on a read-replica to avoid impacting the primary
2. AOF-based backup: Copy the AOF file while Redis is running (safe with appendfsync everysec)
3. Incremental replication: Use Redis replication to maintain a hot standby, then backup from the standby
4. Shard your data: Split across multiple Redis instances (Redis Cluster) to keep individual BGSAVE operations manageable (under 30 seconds each)

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到加密货币监管，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测科技事件的走向已经赚了不少。用我的邀请链接注册：Polymarket.com