Redundancy gives a system another component or path to use when one fails. In a cloud environment, data loss or a hardware failure that causes a major disruption may indicate a single point of failure, tight coupling, or insufficient redundancy. Virtual servers do not make hardware failures impossible. section 8.3.1
The right level of redundancy depends on downtime tolerance. A zero-downtime goal may be possible, but it can be extremely expensive and complex—particularly when parts of an enterprise cannot run as multiple instances. Before committing to it, establish whether clients can tolerate an interruption measured in minutes, hours, or days. section 8.4.1
For a disaster-recovery design spanning two geographic zones, examine two practical requirements:
- Keep data synchronized. Network travel time limits how quickly changes can reach the other zone, even when database synchronization features are available. section 8.4.1
- Switch user traffic to the new active zone. A duplicate system is useful only if users can reach it when needed. section 8.4.1
When a duplicate database is not straightforward
An organization may want a second zone ready to take over, yet find that its database design makes real-time redundancy difficult. Database-generated, autoincremented primary keys are one cited complication; network latency between zones adds another. A promise of zero downtime should account for both constraints, not merely the presence of duplicate servers. section 8.4.1
Ask what happens when a server fails, whether data or service is lost, and how users would reach an alternative. Then weigh the cost and complexity of closing those gaps against the interruption the business can tolerate. Duplicate servers waiting for a disaster are not, by themselves, a complete disaster-recovery strategy. section 8.3.1 section 8.4.1
