Redis persistence.

RDB (snapshots)

save 900 1            # if >=1 changes in 900s
save 300 10
save 60 10000

dbfilename dump.rdb
dir /var/lib/redis

Periodic full snapshots. Fast to load. Some data loss possible.

AOF (append-only file)

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec    # always | everysec | no
  • always: fsync each write (durable, slow).
  • everysec: fsync every second (default; lose ≤1s).
  • no: OS decides (fastest, riskiest).

AOF rewrite

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Periodically rewrites to smaller file.

Hybrid (RDB inside AOF)

aof-use-rdb-preamble yes

Best of both: fast load (RDB) + recent durability (AOF).

Commands

BGSAVE              # async RDB
BGREWRITEAOF        # async AOF rewrite
LASTSAVE

Recovery order

If AOF + RDB both exist:

  • Redis loads AOF (more recent).

If AOF off, loads RDB.

Backups

# Copy dump.rdb regularly
cp /var/lib/redis/dump.rdb /backup/dump-$(date +%F).rdb

# Compress
zstd -19 dump.rdb

For AOF: copy after rewrite (consistent state) or rsync continuously.

Replication ≠ backup

Replicas mirror primary, including DELETEs. Bug deletes data → all replicas lose it. Always have backups.

Diskless replication

repl-diskless-sync yes
repl-diskless-sync-delay 5

Stream RDB directly to replica without writing to disk.

Disable persistence (cache-only)

save ""
appendonly no

For pure cache where data loss OK.

Common mistakes

  • Disabling persistence then using as primary store.
  • AOF appendfsync always on busy server → slow.
  • No backups, relying on replica.
  • Disk full → fork() fails on save.
  • Long fork on huge dataset → latency spike.

Read this next

If you want my Redis persistence setup, it’s at rajpoot.dev .

Building something AI-, backend-, or data-heavy and want a second pair of eyes? I do consulting and freelance work — see my projects and ways to reach me at rajpoot.dev .