How would you take a backup of a Redis dataset that you can actually restore from, and what does the restore procedure look like?

## Choose the artifact: RDB For backups, use the RDB snapshot. It is a single file, self-contained, compact, checksummed with CRC64, and it represents one instant. Loading it is fast because it is a binary image rather than a command replay. The AOF is a poor backup artifact even though it is the better durability mechanism. On Redis 7.x it is a directory of base and incremental files governed by a manifest; a copy is only meaningful if the parts and the manifest are consistent with each other, and a rewrite completing mid-copy breaks that. On 6.x the single file is simply large and slow to load. Use AOF for the loss window, RDB for the backups; they answer different questions. ## Taking the snapshot `BGSAVE` forks a child that writes the dataset to a temporary file and then `rename()`s it over `dbfilename`. Two useful consequences: - An existing `dump.rdb` is always a complete, consistent file. You can copy it at any time without coordination, and you will never capture a half-written snapshot. - The fork has the usual cost, stalling the server proportionally to mapped memory and consuming copy-on-write memory. Which is why: **Take backups on a replica.** The replica holds the same data and its fork stalls nobody who is serving traffic. Note the replica lags by the replication delay, so the snapshot is that much older; for backups measured in hours of retention this is irrelevant. `SAVE` (no `BG`) performs the same work in the main process and blocks the server for the entire duration. It exists for scripted shutdown paths and small instances; it is not a backup strategy. `LASTSAVE` returns the unix time of the last successful save, which is how a script confirms a `BGSAVE` finished before it starts copying. ## Making it a real backup - **Off-host.** A copy on the same volume does not survive the disk failure or the instance termination it is supposed to protect against. Ship to object storage or a separate backup host. - **Timestamped names and retention.** `dump-<host>-<utc-timestamp>.rdb`, with a policy such as hourly for a day, daily for a month. Overwriting a single file means a corrupt or empty snapshot can silently replace your last good one. - **Immutability or versioning** where the threat model includes an operator or an attacker running `FLUSHALL`; replication and even a naive backup rotation will faithfully propagate that. - **Verification.** `redis-check-rdb dump-....rdb` catches structural damage and checksum failure. It does not prove the contents are what you expect. - **Restore rehearsal.** Periodically load the backup into a scratch instance and assert on `DBSIZE` and a few known keys. This is the only step that turns "we have backups" into a fact. ## Restoring The order matters because of Redis's load rule: with `appendonly yes`, the AOF is authoritative and `dump.rdb` is ignored entirely. So a restore that just drops the file in place and restarts an AOF-enabled server restores nothing. 1. Stop the server (`SHUTDOWN NOSAVE` if you must be certain it does not overwrite files on the way out; be equally certain that is what you want). 2. Confirm the target paths: `CONFIG GET dir` and `CONFIG GET dbfilename`. 3. Place the backup file there, with the correct owner and mode for the redis user. Wrong ownership is the most common reason a restore "does nothing". 4. Ensure AOF is not enabled for this start, either by starting with `appendonly no` or by moving the existing `appendonlydir` aside. 5. Start the server and check the log line `DB loaded from disk`, then `DBSIZE` and a few known keys. 6. Re-enable durability on the running server: `CONFIG SET appendonly yes` (which rewrites the AOF from memory) and `CONFIG REWRITE` to persist the setting. For a replicated deployment, restore one node and let replication reseed the others rather than restoring each independently; otherwise you can end up with nodes disagreeing about which snapshot is current. ## Things people get wrong - **"Replicas are our backup."** They are not. A replica applies `DEL`, `FLUSHALL` and an accidental mass expiry within milliseconds. Replication protects against node loss, not against a bad write. Backups protect against a bad write, not against staleness. You need both. - **Backing up the AOF directory file-by-file** without the manifest, or while a rewrite is running. - **Assuming the RDB is encrypted or access-controlled.** It is a plain data file containing everything, including anything sensitive stored in Redis; treat it with the same controls as a database dump, encrypted at rest and in transit. - **Forgetting the cluster case.** In Redis Cluster each master owns a slice of the keyspace, so a backup is a set of per-node snapshots taken close together, and a restore must line up with the slot assignment. Snapshots are per-node and not globally atomic. ## Also worth knowing `DUMP` and `RESTORE` serialize individual keys, and `MIGRATE` moves them between instances. Those are key-level tools for repair and rebalancing, not a backup strategy for a whole dataset, but naming them shows you know where the boundary is.