Redis Backup and Migration Plan Prompt

You are a senior SRE who has run Redis backups, cross-instance migrations, and version upgrades without data loss.

I will provide:
- Source and target (versions, standalone/replica/Cluster, managed?)
- Dataset size and acceptable downtime/RPO
- Persistence config (RDB, AOF, both)

Your job:

1. **Choose a backup method**: `BGSAVE` forks a child to write an RDB snapshot without blocking (watch fork memory/latency); `SAVE` blocks and is for maintenance only. AOF gives lower RPO. `LASTSAVE` confirms completion. Copy the RDB/AOF file from `dir`+`dbfilename` off-box.
2. **Verify backups**: check RDB integrity with `redis-check-rdb` (and `redis-check-aof --fix` for AOF) and periodically restore into a scratch instance — an untested backup is not a backup.
3. **Restore**: place the RDB in `dir`, name it per `dbfilename`, start Redis; or with AOF enabled use the AOF. Never overwrite a running instance's file.
4. **Migrate individual keys**: `DUMP <key>` serializes a key; `RESTORE <key> <ttl> <serialized>` recreates it (use REPLACE to overwrite). Serialization is version-checked — a much newer source may not RESTORE into an older target.
5. **Migrate atomically between instances**: `MIGRATE host port key destdb timeout [COPY] [REPLACE] [KEYS k1 k2 ...]` moves keys directly; it blocks both instances for those keys during transfer — batch and size timeouts carefully.
6. **Migrate live with replication**: for minimal-downtime moves, replicate target-from-source (REPLICAOF), let it sync, then fail over — often safer than dump/restore for whole datasets.
7. **Cluster resharding**: use `redis-cli --cluster reshard`/`rebalance` which moves hash slots via MIGRATE under the hood.
8. **Upgrade sequencing**: back up first, upgrade replicas before master, verify RDB/AOF forward-compatibility, and have a rollback (the pre-upgrade RDB).

Mark DESTRUCTIVE: RESTORE/MIGRATE without REPLACE onto existing keys (errors) or WITH REPLACE (overwrites), FLUSHALL, overwriting a live RDB/AOF file, downgrades that cannot read a newer RDB.

---

Source/target: [DESCRIBE]
Size / downtime / RPO: [DESCRIBE]
Persistence config: [DESCRIBE]

Why this prompt works

Backups and migrations are where Redis data actually gets lost — untested snapshots, fork-induced memory spikes, blocking MIGRATE stalls, and version-incompatible RDBs. This prompt forces a method choice matched to your RPO and downtime budget, insists on backup verification, and sequences upgrades with a real rollback path.

How to use it

1. State source and target versions and topology — compatibility matters.
2. Give dataset size and your downtime/RPO budget.
3. Describe persistence (RDB, AOF, or both) to pick the method.
4. Ask for a verification and rollback step, not just the happy path.

Useful commands

# Snapshot without blocking, then confirm and copy off-box
redis-cli BGSAVE
redis-cli LASTSAVE                      # timestamp advances when done
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename         # copy <dir>/<dbfilename> elsewhere

# Verify backups
redis-check-rdb /var/lib/redis/dump.rdb
redis-check-aof --fix /var/lib/redis/appendonly.aof

# Migrate a single key between instances (atomic, blocks those keys)
redis-cli DUMP user:42                  # serialize
redis-cli -h target MIGRATE target-host 6379 user:42 0 5000 COPY REPLACE

# Move many keys in one call
redis-cli MIGRATE target-host 6379 "" 0 5000 KEYS user:42 user:43 user:44

Example config

# redis.conf persistence for a low-RPO backup posture
dir /var/lib/redis
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000                      # RDB snapshot triggers
appendonly yes                     # AOF for lower RPO
appendfsync everysec

# Live migration via replication (minimal downtime), then failover:
#   On TARGET:  redis-cli REPLICAOF source-host 6379
#   Wait:       redis-cli INFO replication  (master_link_status:up, sync done)
#   Cutover:    redis-cli -h target REPLICAOF NO ONE   # promote target
#   Repoint application clients to target

# Cluster reshard (moves slots via MIGRATE internally)
#   redis-cli --cluster reshard <host>:<port>

Common findings this catches

• Untested backup → unrestorable RDB discovered too late.
• Fork memory spike → BGSAVE OOM/latency on large data.
• Blocking MIGRATE → big-key/batch stalls both instances.
• Version mismatch → RDB/DUMP fails to RESTORE on downgrade.
• Live file overwrite → corrupted running instance.
• Accidental REPLACE → clobbered target keys.
• No rollback → upgrade with no pre-upgrade snapshot.

When to escalate

• Large-dataset or Cluster migrations — staged plan with the data team.
• Cross-version upgrades with incompatibility risk — test in staging, get sign-off.
• Tight RPO/zero-downtime requirements — replication-based cutover with SRE.