The Redis Backup and Disaster Recovery Guide

An RDB snapshot is a point-in-time fork of the dataset written as a compact file: fast to load, cheap to ship off-host, and it loses everything written since the last one. AOF appends each write to a log and, on the default per-second fsync, loses at most about a second, but it replays on start and takes longer to load on a large dataset.

Most production estates run both: AOF for the recovery point, periodic RDB for the portable artefact that goes off-host. Running neither, which is the default on some builds, means a restart is a full data loss event.

The question that settles the configuration is how much data the business can lose, expressed in seconds or minutes. Nobody asks it, so the answer is inherited from whichever config file was copied first, and it is usually discovered to be wrong during the first real incident.

Get a number from the application owner, then pick the mechanism that meets it: seconds means AOF with an appropriate fsync policy, minutes means RDB on a matching interval, and zero means Redis is not the system of record for that data.

A replica applies whatever the primary sends it, within milliseconds. That covers hardware failure and nothing else: a mistaken FLUSHALL, an application bug writing garbage, or a key deleted by an operator is replicated faithfully to every replica before anyone notices.

Backups have to be separate copies, held off the primary's host and outside its blast radius, with enough retained versions to reach back past the moment the damage started.

An RDB file sitting on the same volume as the dataset survives a process crash and nothing larger. The backup only starts existing when it is somewhere else: object storage, another region, or a separate account.

Set a schedule that matches the RPO from step two, retain enough generations to recover from damage discovered days later, and encrypt at rest, because a Redis dump contains every value in plaintext.

Cross-region options run from asynchronous replication to a warm standby to restore-from-backup, and they differ by an order of magnitude in both RPO and cost. Active-active is available in some commercial builds and brings conflict resolution rules the application has to be written for.

Pick the mode against the RPO and RTO you wrote down, and make failover an explicit decision with a named owner rather than something automation attempts during a partition.

Backup jobs report success reliably. Restores fail on the things nobody checked: a dump from a different Redis version, a memory ceiling on the target smaller than the dataset, a cluster restore into a different slot layout, or an AOF that was never rewritten and takes hours to replay.

Restore into a scratch environment on a schedule, time it, and record the number. That timing is your real RTO; everything else is an estimate.

ElastiCache, Azure Cache, Memorystore and Redis Cloud each take snapshots and each have their own retention ceiling, cross-region behaviour and export rules. What none of them do is decide your RPO, retain past their maximum window, or test that a restore meets your RTO.

Read the specific limits for the tier you are on rather than the marketing page, and keep an independent export if retention needs to exceed the platform's ceiling.

Valkey forked from Redis 7.2 and inherits RDB, AOF and replication unchanged, so everything above applies. What changes is who fixes it when a restore fails on a fork your platform provider does not formally support.

If a migration is in progress, keep backups on both sides through the cutover and confirm dump compatibility in the direction you might have to roll back.

A tested backup with nobody rostered to use it is a document, not a recovery plan. The restore usually happens out of hours, under pressure, on the day the person who configured persistence is unavailable.

Write the runbook, name the owner, and confirm the escalation path. Where there is no in-house Redis on-call, that is the gap a support contract covers.