Choose backup, snapshots, logs, replication, and immutable copies based on outage, corruption, deletion, ransomware, retention, RTO, and RPO requirements.
Replication keeps another copy of current state available. Backup preserves recoverable state from an earlier point. Both copy data, but the time relationship and failure isolation are different.
That distinction matters because many incidents damage current state rather than destroy one storage device. Accidental deletion, application bugs, malicious encryption, credential compromise, and silent corruption may be copied perfectly to every live replica.
| Mechanism | Main purpose | Strength | Limitation |
|---|---|---|---|
| Synchronous replication | Keep replicas at the same committed state within the protected scope | tight RPO; rapid local failover | latency and quorum trade-offs; logical errors propagate |
| Asynchronous replication | Maintain a geographically or operationally separate recent copy | lower write latency; broader distance | replication lag and possible data loss on promotion |
| Snapshot | Capture storage state at a point in time | fast creation and useful rollback point | application consistency and storage dependency must be verified |
| Full backup | Preserve a complete recoverable data set | simple recovery base | longer copy and restore time |
| Incremental or differential backup | Capture changes relative to another backup | lower transfer and storage cost | restore chain and catalog integrity become dependencies |
| Transaction or write-ahead log archive | Preserve changes between base recovery points | finer point-in-time recovery | requires a valid base copy and correct replay |
| Versioning or history | Retain prior object or record states | useful for deletion and overwrite | retention, lifecycle, and administrative protection still matter |
Replication supports availability. Backup supports historical recovery. A resilient data design usually needs both.
| Failure | Replication helps? | Backup or history helps? | Important caveat |
|---|---|---|---|
| Disk or node loss | Yes | Yes | Replica failover is usually faster |
| Zone or site loss | Yes, if outside the failed scope | Yes, if accessible elsewhere | Network and control dependencies must also survive |
| Accidental deletion | Often propagates the deletion | Yes | Recovery point must predate the deletion |
| Application corruption | Often propagates bad state | Yes | Detection delay determines required retention |
| Ransomware | May replicate encrypted data | Yes, if copies resist the compromised credentials | Restore into a clean environment |
| Long-term retention | Not usually the right control | Yes | Legal holds and deletion policy may apply |
| Very low interruption target | Yes | Usually too slow alone | Promotion and traffic movement still affect RTO |
A copy is more useful when it is independent across several dimensions:
“Stored in another region” addresses only one dimension. A cross-region copy controlled by the same compromised account may not provide cyber recovery.
Immutable or write-once retention prevents protected copies from being changed or deleted during a defined period. It is valuable against destructive mistakes and malicious actions, but it is not magic:
Air-gapped is often used loosely. Be precise about whether the copy is physically offline, logically isolated, administratively separate, or merely in another account or project.
A storage snapshot may capture blocks as if power were removed suddenly. A database or distributed application may require coordinated flushing, transaction logs, quiescing, or service-native backup APIs to produce an application-consistent recovery point.
Before relying on a snapshot, ask:
A successful snapshot operation proves that blocks were copied, not that the business service can recover correctly.
Point-in-time recovery might require:
Missing one log segment, catalog entry, key, artifact, or credential can break the chain. Recovery tests should validate the complete sequence, not merely list stored objects.
| Decision | Question |
|---|---|
| Scope | Which data, configuration, identities, keys, artifacts, and infrastructure definitions are required? |
| Frequency | Can the produced recovery points meet each flow’s RPO? |
| Retention | How long might corruption remain undetected, and what obligations apply? |
| Isolation | Which failures and credentials can affect both production and copies? |
| Integrity | How are incomplete, empty, corrupted, or malicious copies detected? |
| Restore | Where will recovery run, and is sufficient capacity available? |
| Validation | What evidence proves application and business correctness? |
| Disposal | How are expired copies deleted safely and verifiably? |
| Error | Better rule |
|---|---|
| “Three replicas means three backups.” | Replicas usually preserve current service state; backups preserve independent historical states. |
| “The backup job is green, so recovery is ready.” | Validate restoration, keys, dependencies, timing, and data correctness. |
| “Cross-region means ransomware-safe.” | Administrative and credential isolation matter as much as geography. |
| “Snapshots are always application-consistent.” | Verify the application’s consistency and log-replay requirements. |
| “More frequent backups guarantee a tighter RPO.” | Completion, transfer, integrity, catalog, and restore capability determine the effective RPO. |
Continue with Failure Domains and Blast Radius to evaluate whether copies and live replicas actually fail independently.
Further reading: Google SRE data integrity and NIST contingency planning guidance.