The Difference Between Durability and Backup
MemoryDB's transaction log provides durability — protection against node and AZ failures with RPO=0. But durability is not the same as backup. If someone runs FLUSHALL (deletes all data), or if a bug writes corrupt data, or if the cluster itself is accidentally deleted, the transaction log faithfully recorded those operations. You cannot "undo" them from the log.
This is why MemoryDB also supports snapshots.
Snapshots
A snapshot is a point-in-time copy of your entire cluster's dataset, stored in Amazon S3. MemoryDB can take snapshots:
- Automatically: On a daily schedule (configurable retention up to 35 days).
- Manually: On demand, before a risky migration or deployment.
Snapshots capture the state of all shards simultaneously. Because MemoryDB's storage layer is separate from the compute layer, snapshots do not impact cluster performance — there is no "fork and copy" operation that would slow down a Redis node.
Restore Scenarios
| Failure Type | Recovery Mechanism | RPO |
|---|---|---|
| Node failure | Automatic failover from Replica | ~0 (transaction log) |
| AZ failure | Automatic failover from Replica in another AZ | ~0 (transaction log) |
Accidental FLUSHALL |
Restore from snapshot | Time since last snapshot |
| Cluster deletion | Restore from snapshot | Time since last snapshot |
| Data corruption | Restore from snapshot before corruption | Time since last clean snapshot |
Restoring From a Snapshot
Restoring creates a new cluster from the snapshot. You cannot restore in-place to an existing cluster. The workflow is:
- Identify the snapshot (automatic or manual) from before the data loss event.
- Create a new MemoryDB cluster from that snapshot.
- Update your application's connection string to point to the new cluster endpoint.
- Replay any writes that occurred between the snapshot time and the failure (from your application's event log, if available).
This is why critical MemoryDB workloads should also write to an event stream (like Kinesis or Kafka) as a secondary record — not for normal operation, but as a replay source for disaster recovery scenarios that exceed what the transaction log covers.