Redis Persistence

Redis stores data in RAM, which means a server restart wipes everything unless Redis has saved a copy to disk first. Redis offers two approaches to persistence: periodic snapshots (RDB) and a continuous log of commands (AOF). You can use one or both, depending on how much data loss your app can tolerate.

The Whiteboard and Notebook Analogy

Imagine you run a busy reception desk. You take notes on a whiteboard because it is fast. But if the power goes out, the whiteboard clears. To protect yourself:

Option A – Photograph the Whiteboard Every Hour (RDB)
  ┌─────────────┐       every 60 min        ┌──────────────┐
  │  Whiteboard │ ──── take a photo ──────▶ │  Photo Album │
  │  (RAM)      │                           │  (Disk)      │
  └─────────────┘                           └──────────────┘
  Fast. But you lose up to 60 minutes of changes if power cuts.

Option B – Write Every Note in a Notebook Too (AOF)
  ┌─────────────┐  every command  ┌──────────────┐
  │  Whiteboard │ ──── write ───▶ │  Notebook    │
  │  (RAM)      │                 │  (Disk)      │
  └─────────────┘                 └──────────────┘
  Slower. But if power cuts, you replay the notebook to rebuild.

RDB – Redis Database Snapshots

RDB persistence takes a complete snapshot of all data at set intervals and writes it to a single file called dump.rdb. On restart, Redis loads this file and resumes from the last snapshot.

Default Snapshot Triggers (in redis.conf)

save 3600 1      ← snapshot if at least 1 key changed in 3600 seconds
save 300  100    ← snapshot if at least 100 keys changed in 5 minutes
save 60   10000  ← snapshot if at least 10000 keys changed in 1 minute

Triggering a Manual Snapshot

BGSAVE   ← saves in the background (non-blocking, app keeps running)
SAVE     ← saves immediately (blocks all other commands until done)

Check when the last save finished:
LASTSAVE → 1711900800  (Unix timestamp of last successful save)

RDB Trade-offs

┌────────────────────────────────────┬────────────────────────────┐
│  Advantage                         │  Disadvantage              │
├────────────────────────────────────┼────────────────────────────┤
│  Single compact file               │  Data since last snapshot  │
│  Fast restart (load one file)      │  is lost on crash          │
│  Low disk I/O under normal load    │  BGSAVE uses extra memory  │
└────────────────────────────────────┴────────────────────────────┘

AOF – Append Only File

AOF records every write command Redis executes. On restart, Redis replays every command from the file to rebuild the dataset. The file grows over time and is compacted (rewritten) through a process called AOF rewriting.

Enabling AOF in redis.conf

appendonly yes
appendfilename "appendonly.aof"

AOF Sync Policies (How Often to Flush to Disk)

appendfsync always   ← sync after every command (safest, slowest)
appendfsync everysec ← sync every second (good balance — default)
appendfsync no       ← let the OS decide (fastest, least safe)

appendfsync everysec means you lose at most 1 second of data on crash.

How AOF Stores Commands

Every time you run a write command, AOF appends it:

SET user:1 "Alice"
→ AOF file:  *3\r\n$3\r\nSET\r\n$6\r\nuser:1\r\n$5\r\nAlice\r\n

INCR visits
→ AOF file appends the INCR command

On restart:
  Redis reads appendonly.aof line by line
  and replays each command to rebuild the dataset.

AOF Rewriting – Compacting the File

Over time, AOF files grow large. If a key was SET and then DEL, the AOF still has both commands. AOF rewriting scans the current dataset and writes only the minimum commands needed to recreate it.

Before rewrite:
  SET score 0
  INCR score       ← score = 1
  INCR score       ← score = 2
  INCR score       ← score = 3
  (5 lines)

After rewrite:
  SET score 3
  (1 line — same result, far smaller file)

Trigger manually:
  BGREWRITEAOF

Comparing RDB and AOF

┌─────────────────────┬───────────────────┬──────────────────────┐
│  Feature            │       RDB         │        AOF           │
├─────────────────────┼───────────────────┼──────────────────────┤
│  Data format        │  Binary snapshot  │  Text command log    │
│  File size          │  Compact          │  Larger (grows)      │
│  Restart speed      │  Very fast        │  Slower (replay)     │
│  Data loss risk     │  Up to minutes    │  Up to 1 second      │
│  Best for           │  Backups, speed   │  Durability          │
└─────────────────────┴───────────────────┴──────────────────────┘

Using Both RDB and AOF Together

Redis lets you run both at the same time. On restart, Redis prefers the AOF file because it is more up-to-date. The RDB file serves as a fast backup and is useful for transferring data to another server.

redis.conf:
  save 300 100
  appendonly yes
  appendfsync everysec

Restart behavior:
  If AOF exists → load AOF (most complete data)
  If only RDB   → load RDB (faster but older)
  If neither    → start empty

Key Points

  • By default, Redis is in-memory only. Without persistence configured, a restart erases all data.
  • RDB takes periodic snapshots (dump.rdb). Fast to reload, but you lose data since the last snapshot.
  • AOF logs every write command. You lose at most one second of data (with everysec mode).
  • Use BGSAVE or BGREWRITEAOF to trigger persistence manually without blocking the server.
  • Running both RDB and AOF is the safest production configuration.
Previous lessons
Back to courses
Next lessons

Leave a Comment