Persistence

Introduction

Redis is an in-memory store, but that does not mean your data disappears when the server restarts. Redis offers two persistence strategies—RDB point-in-time snapshots and AOF append-only logs—plus a hybrid mode that blends both. This chapter explains how each works, how to configure them, and how to choose the right balance between durability and performance for your application.

Prerequisites

A running Redis server and access to its configuration file
Understanding of the Redis event loop and single-threaded model
Comfort with redis-cli and INFO commands

RDB Persistence

RDB (Redis Database) creates a compact binary snapshot of your entire dataset at a specific moment in time. The snapshot is written to a .rdb file on disk, which can be copied to remote servers or used to restore the dataset after a restart.

How RDB Works

When Redis saves an RDB file, it forks a child process. The child writes the snapshot while the parent continues to handle client requests. Under the hood, Linux uses copy-on-write, so memory is shared until either process modifies a page.

plaintext

Main process ──fork──→ Child process
   (serves clients)      (writes RDB to disk)

Triggering a Save

bash

# Synchronous save: blocks all clients until complete
SAVE
 
# Background save: forks a child process
BGSAVE
 
# Check if a background save is in progress
redis-cli INFO persistence
# rdb_bgsave_in_progress:1 means yes

SAVE is rarely used in production because it freezes the server. BGSAVE is the standard approach.

Automatic Snapshots in redis.conf

conf

# Save if at least 1 key changed in 900 seconds (15 minutes)
save 900 1
 
# Save if at least 10 keys changed in 300 seconds (5 minutes)
save 300 10
 
# Save if at least 10000 keys changed in 60 seconds
save 60 10000
 
# Disable automatic RDB saves entirely
save ""

Each save line is independent. If any condition is met, Redis triggers BGSAVE. More frequent snapshots improve data safety but increase disk I/O and CPU usage from forking.

RDB File Location and Compression

conf

# Filename and directory
dbfilename dump.rdb
dir /var/lib/redis
 
# Compress the snapshot with LZF (default: yes)
rdbcompression yes
 
# Add a checksum to detect corruption (default: yes)
rdbchecksum yes

Tip

Backup Strategy

Because RDB files are immutable once written, you can safely copy them while Redis runs. A common cron job copies dump.rdb to S3 or another server every hour. If the live server fails, you restore from the latest copy.

RDB Advantages and Trade-Offs

Advantage	Trade-Off
Compact file, great for backups	Data loss window: everything since the last snapshot
Fast restarts (load the whole dataset at once)	Forking can momentarily double memory usage
Minimal runtime overhead between saves	Frequent saves increase I/O and CPU

If Redis crashes one minute before the next scheduled snapshot, you lose that minute of writes.

AOF Persistence

AOF (Append-Only File) logs every write command Redis receives. On restart, Redis replays the log to reconstruct the dataset. This is closer to a traditional database transaction log.

Enabling AOF

conf

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

Or at runtime (requires a restart to take full effect):

bash

redis-cli CONFIG SET appendonly yes

Sync Policies

The appendfsync setting controls how often the operating system flushes the AOF buffer to disk.

Policy	Behavior	Safety	Speed
`always`	fsync after every write	Maximum	Slowest
`everysec`	fsync once per second	Very high	Fast
`no`	Let the OS decide	Lowest	Fastest

conf

appendfsync everysec

Tip

Recommended Default

everysec is the best compromise for most production workloads. You lose at most one second of writes in a crash, and throughput remains excellent. Use always only when losing a single write is unacceptable (for example, financial ledgers).

AOF Rewrite

Over time, the AOF file grows. If you increment a counter a million times, the log contains a million INCR commands. Redis can rewrite the AOF into a minimal set of commands that produce the same final dataset.

bash

# Trigger a rewrite manually
BGREWRITEAOF

Redis also auto-rewrites based on growth percentage:

conf

# Rewrite if the AOF is at least 64 MB and 100% larger than the last rewrite
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage 100

Like BGSAVE, BGREWRITEAOF forks a child process. The child writes the new file while the parent appends incoming commands to both the old AOF and an in-memory buffer. When the child finishes, the parent flushes the buffer and swaps the files atomically.

AOF Advantages and Trade-Offs

Advantage	Trade-Off
Much smaller data loss window (down to 1 second)	Larger file size than RDB
Human-readable log format (mostly)	Slower restarts (replay every command)
Can be rewritten to minimal form	Higher sustained disk I/O

Hybrid Persistence (Redis 4.0+)

Since Redis 4.0, you can enable both RDB and AOF simultaneously. When AOF is rewritten, Redis writes an RDB preamble followed by the incremental AOF commands. On restart, it loads the fast binary snapshot and replays only the tail of commands written after the rewrite.

conf

# Enable hybrid AOF
aof-use-rdb-preamble yes

This gives you the fast restart of RDB and the durability granularity of AOF.

plaintext

appendonly.aof
├─ RDB preamble (fast binary load)
└─ Incremental AOF commands (replay)

Choosing Between RDB, AOF, and Both

Scenario	Recommendation
Pure cache, data regenerates easily	RDB only or no persistence
Session store, some data loss acceptable	RDB with frequent snapshots
Primary data store, durability critical	AOF with `everysec`, plus RDB for backups
Fast recovery with minimal loss	Both enabled, hybrid AOF (`aof-use-rdb-preamble yes`)

Warning

Do Not Disable Both on Production Data Stores

Running with neither RDB nor AOF means a restart wipes everything. That is fine for ephemeral caches, but catastrophic if Redis holds irreplaceable data.

A Complete Production Configuration

conf

Recovering from Persistence Files

When Redis starts, it looks for data to load in this order:

If AOF is enabled and the AOF file exists, load from AOF (it is assumed more complete).
If no AOF, load from RDB.
If neither, start empty.

To force a restore from a specific RDB file, stop Redis, place the backup file in the configured dir with the correct dbfilename, disable AOF temporarily if necessary, and restart.

bash

# Stop Redis
redis-cli SHUTDOWN
 
# Replace the RDB file
sudo cp /backups/dump-2026-01-01.rdb /var/lib/redis/dump.rdb
 
# Start Redis
redis-server /etc/redis/redis.conf

FAQ

Does persistence make Redis as slow as a disk database?

No. All reads and writes still happen in memory. Persistence is an asynchronous background process (for RDB and AOF rewrites) or a periodic fsync (for AOF). The latency your application sees is unchanged.

Why does BGSAVE or BGREWRITEAOF cause memory to spike?

The forked child process shares memory pages with the parent via copy-on-write. If the parent modifies many keys during the save, the OS copies those pages for both processes. On write-heavy systems, plan for a temporary memory increase of 50% or more during snapshots.

Can I use RDB and AOF on Redis Cluster?

Yes. Persistence settings apply per node. Each master and replica maintains its own RDB and/or AOF files. Backup strategies should account for all nodes, not just one.

What happens if the AOF file is corrupted?

Redis can refuse to start with a truncated AOF. Use redis-check-aof --fix appendonly.aof to chop the file at the last valid command. You will lose the corrupted tail, but the rest of the dataset loads normally.

How do I migrate data from one Redis instance to another?

The simplest way is to copy the RDB file. Alternatively, use redis-cli --rdb backup.rdb to pull a snapshot from a running server, or set up replication and let the replica sync everything before promoting it.

Should I turn off RDB if I use AOF?

Not necessarily. RDB files are compact and useful for backups, disaster recovery, and fast restarts when you disable AOF temporarily. Many teams keep both enabled and rely on hybrid AOF for day-to-day durability.