Redis Persistence Options Explained: RDB, AOF, and Hybrid Mode – Principles and Production Configurations

Why Persistence Matters

Redis delivers millisecond‑level read/write latency by keeping data in memory, but memory is volatile; a restart, crash, or power loss would erase all data. Persistence writes data to disk either synchronously or asynchronously, ensuring fast recovery and stable production operation.

Redis Persistence Options

Redis officially supports three mechanisms: RDB (snapshot), AOF (append‑only log), and the hybrid mode (RDB + AOF) introduced in Redis 4.0. Each differs in design philosophy, implementation, performance, and suitable scenarios.

1. RDB Persistence – Snapshot‑Based Full Backups

1.1 Core Principle

At configured intervals Redis forks a child process that writes the entire in‑memory dataset to a binary snapshot file (default dump.rdb). On restart the snapshot is loaded directly, providing very fast recovery without replaying commands.

1.2 Trigger Mechanisms

Manual : SAVE blocks all clients while writing; BGSAVE forks a child and blocks only briefly (e.g., 10‑50 ms for 10 GB memory).

Automatic : Configured via save directives in redis.conf (e.g., save 800 2 – snapshot if 2 keys change within 800 s).

# Example automatic snapshot configuration
save 800 2    # ≥2 key changes within 800 s
save 280 8    # ≥8 key changes within 280 s
save 50 8000  # ≥8000 key changes within 50 s
save ""      # disable automatic snapshots
rdbcompression yes
dbfilename dump.rdb
dir ./data

1.3 Pros and Cons

Performance : Minimal write I/O; recovery of 10 GB takes 3‑5 s. Fork overhead grows with dataset size (e.g., 100‑200 ms for 20 GB).

Data Safety : Safe on graceful shutdown; risk of data loss between snapshots (e.g., up to 13 min if save 800 2).

Disk Usage : Compressed binary; 10 GB dataset yields ~1.5‑2 GB file.

Operations : Single file is easy to backup, but only the latest snapshot can be restored.

1.4 Production Case & Go Example

Cache cluster for an e‑commerce site (Redis 6.2.6, ~8 GB data) uses the following config:

save 720 3
save 240 10
rdbcompression yes
dbfilename product_cache.rdb
dir /data/redis/rdb

During a typical day ~120 snapshots are created; each fork blocks < 50 ms, the snapshot file is ~1.2 GB, and at most 12 minutes of cache is lost on crash. The Go snippet triggers a manual BGSAVE and verifies completion:

// Create client
rdb := redis.NewClient(&redis.Options{Addr: "192.168.1.100:6379", DB: 0})
ctx := context.Background()
// Trigger BGSAVE
if err := rdb.Bgsave(ctx).Err(); err != nil { fmt.Printf("BGSAVE failed: %v
", err); return }
fmt.Println("BGSAVE triggered, waiting for snapshot")
// Poll persistence info until done
for {
    info, err := rdb.Info(ctx, "persistence").Result()
    if err != nil { time.Sleep(100 * time.Millisecond); continue }
    if strings.Contains(info, "rdb_bgsave_in_progress:0") { fmt.Println("RDB snapshot completed"); break }
    time.Sleep(100 * time.Millisecond)
}
// Verify file existence
if _, err := os.Stat("/data/redis/rdb/product_cache.rdb"); err != nil { fmt.Printf("RDB file missing: %v
", err) } else { fmt.Println("RDB file exists") }
rdb.Close()

2. AOF Persistence – Append‑Only Log for Data Safety

2.1 Core Principle

AOF records every write command (e.g., SET, DEL) in a text file ( appendonly.aof). On restart Redis replays the log to rebuild the dataset.

2.2 Key Configuration (appendfsync)

# Enable AOF
appendonly yes
appendfilename appendonly.aof
dir ./data/aof
# Sync policy (choose one)
# appendfsync always   # every write fsync – zero loss, lowest throughput (~300‑500 QPS)
appendfsync everysec   # fsync once per second – ~1 s loss, high throughput (~10 000+ QPS) – recommended
# appendfsync no        # OS decides – highest throughput, risk of many seconds loss

# AOF rewrite settings
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes

2.3 AOF Rewrite Mechanism

Because the log grows indefinitely, Redis periodically rewrites it: a child process creates a compact file containing a minimal set of commands (one SET per key). The parent continues to append new writes to a buffer; after the child finishes, the buffer is merged and the new file atomically replaces the old one.

2.4 Pros and Cons

Data Safety : everysec loses at most 1 s of data; always loses none.

Performance : everysec matches RDB throughput; always reduces write QPS dramatically.

Recovery Speed : Replaying 10 GB can take 10‑20 minutes.

Disk Usage : Before rewrite, AOF may be 2‑3× the dataset size (e.g., 20‑30 GB for 10 GB data).

Operations : Plain‑text log can be edited; redis-check-aof repairs corruption.

2.5 Production Case & Go Example

Transaction cache for a payment platform (Redis 7.0.11, ~5 GB) uses:

appendonly yes
appendfilename transaction.aof
dir /data/redis/aof
appendfsync everysec
auto-aof-rewrite-percentage 120
auto-aof-rewrite-min-size 128mb
aof-load-truncated yes

During operation AOF is rewritten 3‑4 times daily, ending at ~1.8 GB; write latency stays 1‑5 ms and at most 1 second of data is lost on crash. The Go snippet checks AOF status and runs redis-check-aof if needed:

// Create client
rdb := redis.NewClient(&redis.Options{Addr: "192.168.1.101:6379", DB: 0})
ctx := context.Background()
// Get persistence info
info, err := rdb.Info(ctx, "persistence").Result()
if err != nil { fmt.Printf("Failed to get AOF info: %v
", err); return }
fmt.Printf("AOF info: %s
", info)
// Simulate corruption repair
cmd := exec.Command("redis-check-aof", "--fix", "/data/redis/aof/transaction.aof")
output, err := cmd.CombinedOutput()
if err != nil { fmt.Printf("AOF repair failed: %v, output: %s
", err, output); return }
fmt.Printf("AOF repair succeeded, output: %s
", output)
// Verify Redis after restart
if err := rdb.Ping(ctx).Err(); err != nil { fmt.Printf("Redis reconnect failed: %v
", err); return }
fmt.Println("Redis restarted, AOF data restored")
rdb.Close()

3. Hybrid Persistence – Combining RDB and AOF

3.1 Core Principle

Since Redis 4.0, the hybrid mode writes an RDB‑style snapshot at the beginning of the AOF file followed by incremental AOF commands. On restart Redis loads the snapshot for fast full‑data recovery, then replays the tail for the latest changes, achieving both speed and safety.

3.2 Configuration

# Enable AOF (required)
appendonly yes
# Enable hybrid mode (Redis 4.0+; default on 7.0+)
aof-use-rdb-preamble yes
# Common AOF settings
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
dir /data/redis/mixed

3.3 Pros and Cons

Advantages : Recovery time close to RDB (seconds); data loss limited to the sync interval (≈1 s); file size smaller than pure AOF.

Disadvantages : Mixed binary/text format is not human‑readable; still incurs fork‑related blocking during rewrite; older Redis versions (< 4.0) cannot load hybrid files.

3.4 Production Case

Shopping‑cart cluster for an e‑commerce platform (Redis 7.0.8, ~12 GB) uses:

appendonly yes
aof-use-rdb-preamble yes
appendfsync everysec
auto-aof-rewrite-percentage 110
auto-aof-rewrite-min-size 128mb
dbfilename cart_rdb.aof
dir /data/redis/mixed/cart

The hybrid file stays around 2.5 GB; after a restart 12 GB is restored in 6‑8 seconds (vs. 15‑20 seconds for pure AOF). At most 1 second of cart data is lost, and write QPS remains > 9000.

4. Production Selection Guide

Choose based on three axes: required data safety, performance needs, and operational cost.

Only RDB – suitable for non‑critical, high‑throughput cache (e.g., product list), tolerating occasional data loss.

Only AOF – for core business data where loss must be ≤ 1 s or zero; accept slower writes and recovery.

Hybrid – recommended for most core services (e.g., shopping cart, order cache) needing fast recovery and high safety.

Disable persistence – pure cache scenarios where data can be fully rebuilt.

5. Summary

Redis persistence balances performance, data safety, and operational cost. RDB offers the best write performance and fastest recovery but risks data loss between snapshots. AOF guarantees near‑zero loss at the cost of slower recovery and larger files. The hybrid mode merges the strengths of both and is the optimal choice for most production workloads. Proper configuration of snapshot intervals, AOF rewrite thresholds, and awareness of fork‑related latency are essential for a reliable Redis deployment.