Redis backup and restore: RDB vs AOF and off-site snapshots

Redis can rebuild its in-memory dataset from RDB snapshots, an append-only file, or both. RDB records a point-in-time image at intervals. AOF records write operations and can usually reduce the amount of recent data lost, depending on the fsync policy.

Both normally live beside the Redis process. They help after a restart, but not when the host, volume, credentials, or whole environment is lost. Disaster recovery needs a separate copy with its own access boundary and retention history.

RDB is compact, quick to move, and usually faster to restart from. Its tradeoff is clear: writes after the latest snapshot can be lost. AOF offers better durability but uses more disk and must be rewritten as it grows. Since Redis 7, AOF is a directory of base and incremental files tracked by a manifest, so copying one apparent AOF file is not a sound backup procedure.

When both persistence modes are enabled, Redis uses AOF on restart because it is expected to be the more complete record. Redis recommends both when the data needs stronger safety; RDB alone can be reasonable when several minutes of loss are acceptable. A cache whose contents can be rebuilt may need neither, but that should be a conscious decision.

redis-cli --rdb asks the server for a replication-style transfer and writes a complete RDB file on the client machine. That avoids copying Redis's live data directory. Check the exit status and the resulting file; Redis documents a non-zero exit when the transfer fails.

For automation, the job also has to protect authentication, reject overlap, clean up partial transfers, and keep a failed run from replacing the previous usable artifact. Those controls belong in the backup system, not in a one-line shell alias.

Back up the completed file only after redis-cli exits successfully. Restic encrypts and snapshots it, giving you previous versions when a bad write or accidental FLUSH is discovered after the next run.

For Redis Cluster, one endpoint is not the whole dataset. Back up every primary shard and record the topology needed for recovery. Modules can also affect portability: a target server must have the modules required to load module-owned value types.

Restore the file into an isolated Redis environment with persistence writes disabled for the test. Match the production Redis major version and install any required modules. Keep the recovered artifact read-only during the rehearsal.

DBSIZE is only a first check. Query known keys, inspect types and TTLs, and run a small application smoke test. An RDB can load successfully while still being the wrong snapshot or missing a shard.

Rested automates snapshot capture, protected storage, retention, run history, and failure visibility for a reachable Redis endpoint. Cluster-wide coordination and AOF-directory recovery are different recovery designs and should be planned separately.

Rested intentionally returns the recovery artifact without silently importing it into a running Redis server. The operator controls the destructive cutover after validating version, modules, configuration, shard mapping, and known keys.

The final cutover can replace the entire in-memory dataset after a restart, so the product does not trigger it automatically. Your runbook still needs the target Redis version, modules, configuration, shard mapping, validation queries, and the exact point at which clients may reconnect.