Command Palette

Search for a command to run...

Hectal
Phase 9Intermediate10 of 17 in Redis

Persistence & Durability

RDB snapshots, the append-only file, fsync policies, fork and copy-on-write, recovery, backups, and exactly how much data a restart can lose.

Redis is in-memory, but it can persist: periodic snapshots (RDB), a log of every write (AOF), both, or neither. Each option trades write overhead, restart time and disk use against the size of the data-loss window.

By the end you'll be able to answer the interview favourite, "Redis restarts: how much data can be lost?", precisely for any configuration.

0/3 · 0%
3 topics ~26 min 6 code blocks & diagrams
Start with the first topic
1
9.1

RDB Snapshots: Fork, Copy-on-Write, Recovery

An RDB file is a compact point-in-time snapshot of the whole dataset, written by a forked child process (BGSAVE). It's great for backups, fast restarts and replica full syncs, but anything written after the last snapshot is lost on a crash.

8 min 1 diagram 1 code practice

2
9.2

AOF: The Append-Only File and fsync

The AOF logs every write command; on restart Redis replays it. appendfsync decides how often it's flushed to disk (always, every second, or left to the OS), which sets the data-loss window. Rewrites compact the log in the background; Redis 7 stores it as multi-part files with a manifest.

8 min 2 code practice

3
9.3

Choosing Durability: RDB, AOF, Both, or None

Pick persistence per workload: none for pure caches, RDB for fast restarts with minutes of acceptable loss, AOF everysec (usually with an RDB preamble) for about a second of loss, plus replicas and off-host backups. For data that must never lose an acknowledged write, Redis alone isn't enough.

10 min 2 code practice