Redis Backup and Restore: Practical, Version-Safe Procedures and Examples

Intro

This guide shows how to back up and restore Redis safely with concrete, version-aware procedures. You will inventory your environment, choose the smallest safe action, take consistent RDB and/or AOF backups, verify them, and practice restores on an isolated instance before you touch production. Examples include standalone servers, replicas, Redis Cluster, Docker/Kubernetes, and managed services.

Principles used throughout:

• Observe first, change later.
• Limit blast radius: use a replica or a disposable restore node.
• Protect secrets: use placeholders, bind to localhost during tests.
• Verify every step and define the recovery path in advance.

Version and Environment Inventory

Identify exactly what you are backing up before you run any command. Use read-only observations first.

Prerequisites (placeholders are examples):

• Access: redis-cli -h <host> -p <port> -a <password> (or --user <acl_user> --pass <password> if ACLs)
• OS shell access to copy files or snapshot volumes
• Disk space for a full copy of RDB/AOF plus compression

1. Determine version and topology

redis-cli -h <host> -p <port> -a <password> INFO server | head -n 20
redis-cli -h <host> -p <port> -a <password> ROLE

Expected:

• redis_version: note the exact version (e.g., 6.2.14, 7.0.x).
• ROLE: master, slave (replica), or master with cluster lines on Cluster nodes.

1. Identify persistence mode and file locations

redis-cli -h <host> -p <port> -a <password> INFO persistence
redis-cli -h <host> -p <port> -a <password> CONFIG GET dbfilename
redis-cli -h <host> -p <port> -a <password> CONFIG GET appendonly
redis-cli -h <host> -p <port> -a <password> CONFIG GET appendfilename
redis-cli -h <host> -p <port> -a <password> CONFIG GET dir

Record:

• RDB: dbfilename (e.g., dump.rdb)
• AOF: appendonly yes|no, appendfilename (e.g., appendonly.aof)
• Data directory: dir

1. Capacity and safety checks (OS-level)

• Ensure free space >= 2x largest persistence file in <dir>
• Confirm permissions to read from <dir> and write to backup destination
• If Cloud/managed, identify their snapshot feature and retention

Blast radius note: For write-heavy instances, take backups from a replica to avoid latency spikes on the primary.

Safe Configuration Path (Backups)

This section provides smallest-justified backup procedures for RDB and AOF with verification. Use the path that matches your setup.

Option A: RDB snapshot backup (recommended baseline)

When: RDB is enabled or acceptable for periodic full snapshots.

Smallest change: Trigger a background save or reuse the latest completed snapshot, then copy the resulting RDB file.

1. Observe current state

redis-cli -h <host> -p <port> -a <password> INFO persistence | egrep 'rdb_bgsave_in_progress|rdb_last_save_time'
redis-cli -h <host> -p <port> -a <password> LASTSAVE

1. Trigger a non-blocking snapshot (prefer on a replica)

redis-cli -h <host> -p <port> -a <password> BGSAVE

Expected: Background saving started.

1. Wait for completion and verify

watch -n 1 "redis-cli -h <host> -p <port> -a <password> INFO persistence | grep rdb_bgsave_in_progress"

Completion signal: rdb_bgsave_in_progress:0 and a newer rdb_last_save_time.

1. Copy and verify the file

# On the server where Redis stores data
cd <dir>
cp dump.rdb /backups/redis/dump-$(date +%Y%m%dT%H%M%S).rdb
sha256sum /backups/redis/dump-*.rdb | tee -a /backups/redis/manifest.sha256
redis-check-rdb /backups/redis/dump-<timestamp>.rdb

Expected: RDB looks OK.

Option B: AOF backup (for near point-in-time)

When: appendonly yes is enabled and you need tighter recovery points.

Smallest change: Compact AOF, then copy the compacted file.

1. Observe

redis-cli -h <host> -p <port> -a <password> INFO persistence | egrep 'aof_enabled|aof_rewrite_in_progress|aof_last_rewrite_time_sec'

1. Request a background rewrite

redis-cli -h <host> -p <port> -a <password> BGREWRITEAOF

1. Wait for completion, then copy and verify

cd <dir>
cp appendonly.aof /backups/redis/appendonly-$(date +%Y%m%dT%H%M%S).aof
sha256sum /backups/redis/appendonly-*.aof | tee -a /backups/redis/manifest.sha256
redis-check-aof /backups/redis/appendonly-<timestamp>.aof

Tip: Many teams keep both periodic RDB plus continuous AOF to balance full snapshots and shorter RPO.

Option C: Streaming RDB without file access

When: You cannot read the server filesystem (e.g., managed Redis).

redis-cli -h <host> -p <port> -a <password> --rdb /backups/redis/streamed-$(date +%Y%m%dT%H%M%S).rdb
redis-check-rdb /backups/redis/streamed-<timestamp>.rdb

Note: This uses the replication protocol to stream a full snapshot; it may be heavy on the source. Prefer running against a replica.

Docker and Kubernetes notes

• Docker standalone:
• Data usually in /data inside the container. Verify with CONFIG GET dir.
• Copy with: docker cp <container_id>:/data/dump.rdb /backups/...
• Prefer BGSAVE/BGREWRITEAOF before docker cp.

• Kubernetes:
• Use kubectl exec to run redis-cli checks.
• If using a PersistentVolumeClaim (PVC), prefer a storage-level volume snapshot for atomicity.
• Otherwise, run BGSAVE, wait to complete, then copy from the pod's data path.

Redis Cluster and Sentinel

• Sentinel: Back up each primary instance like standalone. Replicas are ideal backup sources.
• Cluster: Back up every master node individually. A full restore requires restoring all masters' data sets that collectively cover all hash slots. Do not copy nodes.conf between environments; let Redis regenerate it.

Verification and Diagnostics (Restore Drills)

Practice restores on an isolated host or container before an incident. Bind to localhost and use a nonstandard port.

RDB restore drill

1. Create a clean directory and copy a chosen RDB

mkdir -p /restore-test/redis
cp /backups/redis/dump-<timestamp>.rdb /restore-test/redis/dump.rdb

1. Start a disposable Redis using that directory

redis-server --port 6380 --bind 127.0.0.1 \
  --dir /restore-test/redis --dbfilename dump.rdb \
  --appendonly no

1. Verify contents

redis-cli -p 6380 INFO server | grep redis_version
redis-cli -p 6380 DBSIZE
redis-cli -p 6380 INFO keyspace
# Sample keys without blocking production-like patterns
redis-cli -p 6380 --scan | head -n 20
# Check TTLs on sample keys
redis-cli -p 6380 TTL <sample_key>

Expected: DBSIZE and INFO keyspace roughly match expectations from the source at backup time.

AOF restore drill

1. Prepare directory and copy the AOF

mkdir -p /restore-test/redis
cp /backups/redis/appendonly-<timestamp>.aof /restore-test/redis/appendonly.aof

1. Start Redis in AOF mode

redis-server --port 6381 --bind 127.0.0.1 \
  --dir /restore-test/redis --appendonly yes --appendfilename appendonly.aof

1. Verify as above with DBSIZE, SCAN, and sample TTL checks.

Diagnostics signals to track

• Logs: background save/rewrite completion lines, errors such as permission denied or OOM.
• INFO persistence: rdb_bgsave_in_progress, aof_rewrite_in_progress, last durations and errors.
• File checksums: compare across backup copies to ensure integrity.

Failure Modes and Recovery

• BGSAVE fails with memory or signal errors
• Signal 9 (OOM killer) or Cannot allocate memory: use a replica for backups, free memory, or reduce maxmemory during the window. Ensure disk space for temp files.
• Recovery: clear space, stop heavy background tasks, retry BGSAVE on a replica.

• AOF rewrite never finishes
• Cause: high write load, small auto-aof-rewrite-percentage threshold repeatedly triggering rewrites.
• Recovery: temporarily suspend BGREWRITEAOF attempts, retry during lower traffic, or back up current AOF as-is and verify with redis-check-aof.

• Corrupted files or partial copies
• Symptom: redis-check-rdb/aof errors.
• Recovery: recopy after confirming the background operation completed; for AOF, redis-check-aof --fix can truncate invalid tail (accept potential loss of last commands).

• Version incompatibility on restore
• Newer RDB may not load on much older Redis.
• Recovery: restore onto equal or newer Redis, or upgrade the target.

• Cluster restore pitfalls
• Restoring only some masters yields an incomplete dataset.
• Recovery: restore snapshots/AOF for all masters from a consistent point in time. Recreate clusters with fresh nodes.conf files. Validate slot coverage after restore.

• Security regressions on test restores
• Symptom: restored instance accessible without auth.
• Recovery: bind to 127.0.0.1, set requirepass or ACLs on the test instance, and avoid exposing nonproduction ports.

Operations Checklist

Preflight (read-only):

• Record: redis_version, topology (ROLE), persistence mode (RDB/AOF), dir, filenames.
• Confirm disk space and permissions at source and backup destination.
• Choose backup node (prefer a replica) and quiet window if needed.

RDB backup steps:

• BGSAVE on chosen node.
• Wait for rdb_bgsave_in_progress:0 and updated LASTSAVE.
• Copy <dir>/<dbfilename> to /<backup_root>/redis/dump-<timestamp>.rdb.
• sha256sum and redis-check-rdb.
• Record metadata: timestamp, source host, Redis version, file size, checksum.

AOF backup steps:

• BGREWRITEAOF on chosen node.
• Wait for aof_rewrite_in_progress:0.
• Copy <dir>/<appendfilename> to /<backup_root>/redis/appendonly-<timestamp>.aof.
• sha256sum and redis-check-aof.

Restore drill (nonprod):

• Start isolated Redis on port 6380/6381 loading the copied file.
• Verify with DBSIZE, INFO keyspace, sample SCAN, and TTL checks.
• Document how to promote this instance if ever needed (stop writes to source, swap endpoints, or use replication to catch up).

Rotation and retention:

• Keep multiple generations (e.g., 7 daily, 4 weekly, 3 monthly).
• Encrypt at rest and in transit; restrict access to backup stores.
• Periodically test a full restore from the oldest kept backup.

Automation tips:

• Wrap BGSAVE/BGREWRITEAOF, file copy, checksum, and verification into a single script with clear exit codes.
• Ship logs and manifest files to your monitoring system.

Conclusion

Reliable Redis backups come from version-aware observations, the smallest safe backup action, and verified restores. Start by inventorying your version, topology, and persistence mode. Take an RDB snapshot and, if needed, a compacted AOF from a replica. Verify files with checksums and redis-check-*, then practice restores on an isolated port before changing production. With a short, repeatable checklist and periodic restore drills, your team will have clear recovery options when an incident occurs.