A disaster recovery site can satisfy every residency requirement on paper and still go down in the same hour as production. Distance and jurisdiction are the properties written into the design document, and neither says anything about whether the two sites depend on the same power transmission region, the same carrier, the same directory service or the same software release. Correlation, not geography, turns a second site into a second copy of the same outage.
The obvious answer is to put a number on separation. Pick a minimum distance, keep both sites inside the required borders, and treat the requirement as met. That test catches the failures distance was invented for, meaning floods, storms and regional physical events. It says nothing about dependencies that are logical rather than physical, and those have grown fastest as infrastructure has consolidated.
The sovereignty framing makes this harder. Staying inside one country narrows the choice of data centers, carriers, cloud regions and service providers, so two sites chosen under that constraint are more likely to share suppliers than two chosen freely. A sovereign design that ignores correlation can end up less resilient than a cross-border one.
Why distance is the wrong single test
Physical separation addresses a specific class of event. A fire, a flood, a building power failure or a construction accident that severs a duct is contained by geography, and the only question is whether the second site sits outside the affected radius. That radius is worth choosing deliberately rather than inheriting from a template.
Most modern outages do not have a radius. A bad configuration push, an expired certificate, a failed identity provider or a defect that triggers on a particular date affects every instance at once, regardless of where those instances sit. Two sites running the same release, managed by the same automation and reached through the same login fail together at the speed of the change that broke them.
The useful question is therefore not how far apart the sites are, but what they share. Every shared component is a single point of failure that survived the decision to build a second site, and each one needs naming rather than assuming away.
Dependencies that cross the map
Power is the most physical of the shared dependencies and still surprises people. Two data centers in different cities can draw from the same transmission region, so a grid event or regional operator fault affects both. Generator fuel contracts and the vendors who deliver during a wide-area event are frequently shared as well, which matters once an outage runs past a day.
Networking correlates in less visible ways. Two providers may resell capacity from the same wholesale carrier, and two distinct fiber routes may share a duct, a bridge crossing or a landing station. DNS, certificate issuance and the BGP path both sites advertise are logical dependencies that physical separation does not address. The same applies to the replication link between the sites, often the first thing to fail when a carrier has a bad day.
Identity is the dependency most likely to make recovery impossible rather than slow. If both sites authenticate administrators through one directory or federated provider, losing that service locks operators out of the recovery environment at the moment they need it. The same is true of secrets managers, license servers, time sources and package repositories, all silent until unavailable.
Shared software and shared operators
Running the same software version at both sites is standard practice, and it is the correlation most organizations accept knowingly. Running different versions creates compatibility and support problems of its own. What matters is recognizing that a defect or a metadata corruption bug propagates to the recovery site by design, since replication carries the corrupted state along with the good data.
Operations correlate as well. One team, one set of credentials, one automation pipeline and one change window means a mistaken command reaches both sites in the same minute. That is the reasoning behind restricting who can change the system, applied to the boundary between production and recovery.
| Shared dependency | How it defeats the second site | What to check |
|---|---|---|
| Power transmission region | A grid event or regional operator fault darkens both facilities | Transmission operator, substation feeds, fuel supplier and delivery contracts |
| Carrier and physical route | Two circuits share a wholesale provider, duct or landing station | Underlying carrier behind each contract; route maps for both paths |
| Identity provider | Administrators cannot authenticate into the recovery environment | Break-glass accounts local to each site, tested without the federated path |
| Cloud region or zone | A regional control plane fault affects a replica assumed independent | Which region each service, backup and key store runs in |
| Software version | A defect or corruption replicates to the second copy | Upgrade lag between sites; whether replication can be paused on demand |
| Vendor support organization | Both sites queue behind the same support team during a wide event | Contract scope, escalation path, whether support staff are local |
Enumerating correlated dependencies
The exercise is a dependency inventory rather than a site survey. List every external service, supplier and shared component either site needs in order to serve requests, then mark which are the same entity for both. The useful output is the set of rows where the answer matches, since each one can remove the entire design in a single event.
Supplier identity has to be traced past the contract. The organization selling a circuit, a colocation cage or a managed service is often not the one operating it, and two contracts with different names can resolve to one facility or one carrier. Asking each supplier which upstream provider they depend on, in writing, is the only reliable method.
Cloud services deserve separate treatment because their dependency structure is not visible from the console. A managed database, a key management service and an identity service that appear independent may share a regional control plane. When part of the recovery plan depends on a hosted service, the region and control plane behind it belong in the inventory beside the power and carrier entries, alongside the services that must come back first.
Where Scality RING fits
RING supports multi-site deployments in which data is spread across sites so the loss of a whole site does not cause data loss, and the geographic placement of that data is configured by the operator rather than decided by a provider. That placement decision is what lets a design account for correlated dependencies, since sites can be selected on grid, carrier and facility grounds and configured accordingly.
Because RING is software-defined and runs on standard x86 servers in the customer's own facilities, the surrounding dependencies are the customer's own choices. Network paths, identity and administrative access are operated inside the boundary, so break-glass authentication at each site is a design option rather than a request to a provider. Nodes can be added to a live system and old hardware retired without taking the namespace offline, which makes staged, site-by-site change possible instead of one simultaneous update.
What to record and rehearse
Keep a written dependency register with one row per shared component, naming the supplier, the operator behind it, and what happens at the recovery site if the component is unavailable. Review it whenever a contract is renewed or a provider changes, since consolidation quietly converts two independent entries into one.
Rehearse the failures that geography does not cover. Disable the federated identity path and confirm administrators can still log in at the recovery site. Pause replication and confirm the recovery copy can be promoted. Run a failover during which the primary site is assumed unreachable rather than politely shut down, which is the difference between a test and an exercise that measures something.
Record the upgrade policy explicitly. Decide how long the recovery site lags production, who may change that lag, and when replication is halted to stop a defect propagating. A lag of days is a deliberate cost paid for independence, and it works only if someone is accountable for maintaining it and for the decision to close it.