Gyaan

Redis Persistence

intermediate redis persistence rdb aof durability

Here’s a question that comes up in almost every interview about Redis: “If Redis stores everything in memory, what happens when the server crashes? Is all the data gone?”

The answer is no — Redis CAN persist data to disk. It gives us three approaches: RDB snapshots, AOF (Append-Only File), and hybrid persistence. Each has different trade-offs between performance, durability, and disk usage.

RDB — Point-in-Time Snapshots

RDB is the simplest approach. At configured intervals, Redis takes a snapshot of all the data in memory and writes it to a binary file on disk (usually dump.rdb).

How It Works

  1. Redis forks the main process (creates a child process)
  2. The child process writes all the data to a temporary file
  3. Once done, it replaces the old RDB file with the new one
  4. The parent process keeps serving requests the whole time

The fork uses copy-on-write — the child shares memory with the parent. Only pages that get modified after the fork need to be copied. So the memory overhead is usually small.

# Manual snapshot (blocks the server — don't use in production)
SAVE

# Background snapshot (non-blocking — use this one)
BGSAVE

# Check when last save happened
LASTSAVE

Configuration

# In redis.conf — save after N changes in M seconds
save 900 1        # snapshot if at least 1 key changed in 900 seconds
save 300 10       # snapshot if at least 10 keys changed in 300 seconds
save 60 10000     # snapshot if at least 10000 keys changed in 60 seconds

# RDB filename and directory
dbfilename dump.rdb
dir /var/lib/redis

Pros and Cons of RDB

  • Compact file — single binary file, easy to back up and transfer
  • Fast restarts — loading an RDB file is much faster than replaying logs
  • Low runtime overhead — snapshots happen in a background fork
  • Data loss between snapshots — if Redis crashes 5 minutes after the last snapshot, those 5 minutes of writes are gone
  • Fork can be slow — on large datasets, the fork itself takes time and can cause a brief pause

AOF — Append-Only File

AOF takes a completely different approach. Instead of periodic snapshots, it logs every single write operation to a file as it happens. To recover, Redis replays the entire log from start to finish.

fsync Policies

The big question with AOF is: how often do we flush the log to disk?

# In redis.conf
appendonly yes
appendfilename "appendonly.aof"

# fsync policy — this is the critical setting
appendfsync always      # fsync after every write — safest, slowest
appendfsync everysec    # fsync once per second — good compromise (default)
appendfsync no          # let the OS decide — fastest, least safe
  • always — we lose zero writes on crash, but every write pays the disk I/O cost. Very slow.
  • everysec — we lose at most 1 second of writes. This is what most people use.
  • no — the OS flushes whenever it wants (usually every 30 seconds). Fast but risky.

AOF Rewrite

The AOF file keeps growing with every write. If we SET the same key a million times, the file has a million entries for it — but only the last one matters.

AOF rewrite compacts the file by replacing all those operations with the minimal set of commands needed to recreate the current state.

# Trigger a manual rewrite
BGREWRITEAOF

# Auto-rewrite when AOF file grows by this percentage
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Pros and Cons of AOF

  • Minimal data loss — at most 1 second with everysec
  • Human-readable — it’s just a log of Redis commands, we can inspect it
  • Append-only — no seek operations, good for spinning disks
  • Larger files — AOF files are much bigger than RDB snapshots
  • Slower restarts — replaying thousands of commands takes longer than loading a binary

Hybrid Persistence (Redis 4.0+)

Why choose when we can have both? Hybrid persistence combines the best of RDB and AOF:

  1. During an AOF rewrite, Redis writes an RDB snapshot as the base of the new AOF file
  2. Then appends only the new AOF entries that happened during the rewrite

On restart, Redis loads the RDB portion first (fast), then replays the small AOF tail (catches up the rest).

# Enable hybrid persistence
aof-use-rdb-preamble yes   # enabled by default since Redis 5.0

This gives us fast restarts (RDB) AND minimal data loss (AOF). It’s the recommended approach for most production setups.

RDB vs AOF vs Hybrid

Feature RDB AOF Hybrid
Data loss risk Minutes ~1 second ~1 second
File size Small Large Medium
Restart speed Fast Slow Fast
Write overhead Low Medium Medium
Recommended? Backups only Legacy setups Yes

What About No Persistence?

We can disable both RDB and AOF entirely. This makes Redis a pure in-memory cache — if it crashes, everything is gone.

# Disable RDB
save ""

# Disable AOF
appendonly no

This is perfectly fine if we’re using Redis purely as a cache and the source of truth lives in a database. We can always rebuild the cache from the DB.

Interview Tip

When someone asks “Is Redis durable?”, the answer is: it depends on our configuration. With appendfsync always, we get durability comparable to a traditional database (at the cost of performance). With appendfsync everysec (the default), we trade up to 1 second of data loss for much better throughput. And with RDB-only, we accept larger windows of potential data loss for minimal overhead.

The right choice depends on what we’re storing. Session tokens? AOF everysec is fine. Financial transactions? We probably shouldn’t be using Redis as the primary store anyway.

References