Redis keeps data in memory, but it can persist it to disk so data survives restarts. There are two mechanisms — RDB and AOF — and choosing between them (or neither) depends on whether Redis is a cache or a primary data store for you.

RDB: point-in-time snapshots

Redis periodically writes the whole dataset to a compact binary file (dump.rdb).

save 3600 1      # after 3600 s if at least 1 key changed
save 300 100     # after 300 s if at least 100 keys changed
save 60 10000    # after 60 s if at least 10000 keys changed
dbfilename dump.rdb
dir /var/lib/redis

Pros: compact files, fast restarts, perfect for backups (copy one file). Cons: you can lose everything written since the last snapshot (minutes of data).

Trigger manually:

redis-cli BGSAVE
redis-cli LASTSAVE

AOF: append-only file

Redis logs every write operation to a file and replays it on startup.

appendonly yes
appendfsync everysec      # always | everysec | no
appendfsync Durability Performance
always No data loss (each write fsynced) Slowest
everysec Lose at most ~1 second Good — the usual choice
no OS decides when to flush (~30 s) Fastest

The AOF grows over time; Redis rewrites it in the background to the minimal set of commands (auto-aof-rewrite-percentage, auto-aof-rewrite-min-size). Since Redis 7, AOF is stored as a base file plus incremental files in an appendonlydir directory.

Pros: much better durability. Cons: larger files, slightly slower restarts.

With both enabled, Redis uses the AOF on startup (more complete) and you still get RDB snapshots for backups. AOF files can also include an RDB preamble (aof-use-rdb-preamble yes, default) for faster loading.

appendonly yes
appendfsync everysec
save 3600 1 300 100 60 10000

Cache only: disable persistence

If Redis holds only cache data that can be rebuilt (page cache, object cache, sessions you can afford to lose):

save ""
appendonly no

No disk I/O, no fork overhead, fastest restarts (empty). Combine with an eviction policy — see Redis maxmemory and eviction.

Common choices:

Use Persistence
WordPress/Laravel object or page cache None
Sessions RDB (or AOF everysec if logouts are unacceptable)
Queues (Sidekiq, BullMQ, Celery broker) AOF everysec
Primary data store (leaderboards, counters, app state) AOF + RDB, plus replicas and backups

Memory during saves: the fork

BGSAVE and AOF rewrites fork the Redis process. Thanks to copy-on-write, the child shares memory with the parent, but pages modified during the save are duplicated. On a write-heavy instance, memory use can temporarily approach 2×. Plan RAM accordingly, and set:

echo 'vm.overcommit_memory = 1' | sudo tee /etc/sysctl.d/90-redis.conf
sudo sysctl --system

Without it, forks can fail on low-memory servers (“Can’t save in background: fork: Cannot allocate memory”), and Redis may then stop accepting writes (stop-writes-on-bgsave-error yes).

Backups

Copy the RDB file regularly — it’s consistent once written:

redis-cli BGSAVE
sleep 5
cp /var/lib/redis/dump.rdb /var/backups/redis-$(date +%F).rdb

Check LASTSAVE changed before copying. Store copies off the server.

Restore

  1. Stop Redis.
  2. Place the RDB file in dir with the configured dbfilename.
  3. If AOF is enabled, Redis loads the AOF instead — temporarily set appendonly no, start Redis to load the RDB, then run CONFIG SET appendonly yes (Redis creates a fresh AOF from memory) and update the config file.
  4. Start Redis and check DBSIZE.

Check status

redis-cli INFO persistence

Look at rdb_last_bgsave_status, aof_enabled, aof_last_write_status, rdb_last_save_time.

Related: installing Redis, Redis vs Memcached and Redis Sentinel for automatic failover.

  • Redis
  • Persistence
  • Databases