Geo-redundancy: how far a disaster recovery site should be from the primary data centre

How far away a disaster recovery site should be

A disaster recovery site should be far enough from the primary data centre that no single fire, flood, grid failure or regional event can disable both, and close enough for the replication mode its recovery point needs. Implementing Regulation (EU) 2024/2690 under NIS2 gives no figure and asks for backup copies “at sufficient distance to escape any damage from a disaster at the main site” (Annex, point 4.2.2(c)). Germany’s Federal Office for Information Security (BSI) recommends at least 200 km between geo-redundant data centres, as reported by the standards body DKE in 2019 and the consultancy ComConsult in 2025.

The replication mode sets the upper limit, and vendors state it mostly as round-trip time (RTT). Synchronous replication, where a write is complete only when both sites hold it, is supported up to a few milliseconds; Broadcom allows no more than 5 ms RTT between the two data sites of a vSAN stretched cluster. Asynchronous replication acknowledges each write locally, so it also works between countries.

If some systems need a recovery point of zero, use two distances: a synchronous pair inside a metro area for those systems and an asynchronous copy far enough away for a regional disaster. A distant asynchronous site alone covers both the loss of the primary site and a regional disaster when minutes of data loss are acceptable.

Risks two sites share at each distance

Since each kind of event has its own reach, start from what the two sites have in common. Buildings on one campus usually share the utility feed, access roads, operator and staff. When a fire broke out on OVHcloud’s Strasbourg site on 10 March 2021, the operator’s account says firefighters could work only “after the electrical power was switched off for the entire site, including all four datacentres”.

Sites in one country usually share a transmission grid, and neighbouring grids can fail together. ENTSO-E reports that on 28 April 2025 “the power systems of continental Spain and Portugal experienced a total blackout”, so sites hundreds of kilometres apart, in two countries, lost grid power together, while the rest of the European power system saw no significant disturbance. Floods follow a river along its valley, and fibre is a shared risk at any distance when the links of both sites run through the same duct or carrier exchange. The regulation’s point 4.2.4 also lists personnel among the resources that need at least partial redundancy.

Distance gives no protection against logical damage, because replication copies whatever was written, encrypted or corrupted data included, to the second site, synchronous replication at once. Protection against it needs restore points from before the damage that cannot be altered or deleted, which our article on what immutable backup protects against covers.

Our classification. RTT limits: Broadcom and NetApp documentation (August to October 2026); grid event: ENTSO-E (updated 20 March 2026); campus power-down: OVHcloud’s account of the Strasbourg fire (2021).

What EU rules, the BSI and NIST say about distance

The Annex to Implementing Regulation (EU) 2024/2690 details the NIS2 measures for the providers listed in its Article 1 and bases backup plans on their own risk assessment. ENISA’s guidance of June 2025 lists “failover sites in other regions” among recovery measures. Whether the regulation or the national law transposing NIS2 binds your company is an assessment for your legal department.

Of the sources in the table below, only the BSI names a distance. Its site criteria, first published at the end of 2018, recommended a minimum of about 200 km between data centres that provide geo-redundancy for each other. A clearly shorter distance needed a written justification and a risk analysis, and 100 km was the floor, in the wording quoted by the German standards committee DKE/GK 719 in March 2019. The committee replied that a risk assessment is in principle preferable to fixed distances and that the data centre standard EN 50600 deliberately names no figures.

Version 2.0 followed in October 2019. The current version 2.1, dated 18 December 2024, adds sections on communication links and the legal framework. ComConsult’s summary of it (March 2025) gives 200 km as the minimum and 100 km as the floor where a justified exception cannot be avoided. It is a national agency’s guidance, not an EU rule. NIST SP 800-34 Rev. 1 asks for an alternate site in an area “unlikely to be negatively affected by the same hazard”, chosen with the travel time for people and equipment in mind.

Implementing Regulation (EU) 2024/2690, Annex; ENISA Technical Implementation Guidance v1.0 (26 June 2025); BSI version dates from BSI pages, figures for version 2.1 from ComConsult’s summary (5 March 2025); DKE/GK 719 statement (20 March 2019); NIST SP 800-34 Rev. 1 (May 2010).

Latency limits for synchronous replication

With synchronous replication, in the words of Cisco’s Data Center High Availability Clusters Design Guide, “All data is written to the local storage array and the remote array before the I/O is considered complete or acknowledged to the host.” Every write waits for at least one round trip, and a Fibre Channel write without write acceleration waits for two. The same guide puts the latency of light in fibre at “approximately 5 µs per kilometer”, which is about 1 ms of round trip per 100 km of route. NetApp plans MetroCluster IP links with the same rule: “You must allocate 1ms for every 100km.” The fibre route is never shorter than the straight line, and every switch, router, DWDM system and firewall adds latency; in NetApp’s words, “Any device that contributes to latency must be accounted for.”

By our arithmetic, a database log that writes one block after another, each waiting 5 ms for the other site, completes at most 200 writes per second before its own storage latency is counted. At 1 ms the ceiling is 1,000.

Broadcom’s VCF 9.1 documentation (updated 5 October 2026) says the two data sites of a vSAN stretched cluster “must have a network latency of no more than five milliseconds (5 ms) round trip (RTT)”. The documentation for VCF 9.0 and vSAN 8.0 gives the same 5 ms. NetApp requires an inter-cluster RTT of less than 10 ms for SnapMirror active sync. Because these are product maximums, measure the RTT on your link under load and test your busiest database’s write latency before you commit to a site.

Both products also use a third location. vSAN places a witness host “at a third site” as a tie-breaker, with less than 200 ms RTT to the data sites. NetApp requires the ONTAP Mediator “in a third failure domain, separate from the two ONTAP clusters”. Our article on vSAN stretched cluster requirements has the details.

Asynchronous replication over long distances

In asynchronous replication, as Cisco’s guide puts it, “the data is replicated to the remote array after the I/O is acknowledged as complete to the host”, so distance no longer slows the application. Broadcom’s vSphere Replication 9.0 documentation states there is “no hard requirement” on WAN latency between the data centres, but warns that latency, out-of-order or dropped packets can reduce replication throughput and cause RPO violations.

At a distant site the recovery point depends on bandwidth against change rate. The replica is as old as the last completed transfer, so the link has to carry everything that changed within one interval before the next one starts. The same documentation sizes the link from “the data change rate within the RPO period” and assumes that only about 70% of a link is available for replication. Measure each system’s change rate over several days, month-end processing and database maintenance included.

Our disaster recovery service replicates virtual machines with Veeam from a 15-minute interval. Describe the systems you would replicate and their recovery targets in the form below.

A recovery site in another EU country

A site in another member state is on another transmission system operator’s grid and often in another river basin and weather system, which removes many physical events from the list of shared risks, though not every grid failure. It usually also means a longer fibre route, and 1,000 km of route adds at least 10 ms to every round trip, beyond the synchronous limits above.

For non-personal data, Regulation (EU) 2018/1807 states that “Data localisation requirements shall be prohibited, unless they are justified on grounds of public security in compliance with the principle of proportionality.” Whether personal data in the replicas, a sector rule or a contract limits where the copies may sit is a legal assessment for your legal department.

At a hosted site your team works remotely, and a VPN that terminates at the primary site fails with it. Plan an access path that does not depend on the primary site and use it in every failover test.

Our recovery site is in Baltneta’s Tier-3 data centres in Lithuania, geographically separate from your primary infrastructure, with EU data residency. Tell us where your primary site is and which systems you would replicate first.

What drives the cost of geo-redundancy

Most of the cost follows from the replication mode. A synchronous pair needs a second set of compute and storage that runs all the time and, with the products above, a third location for the witness or mediator. Its links have to stay inside the vendor’s RTT limit, preferably over two separate fibre routes. An asynchronous site needs capacity and licences only for the systems you would start there, and a link sized to the change rate, which an encrypted internet connection can provide. Both need regular recovery tests, which point 4.2.6 of the regulation asks for.

A hosted recovery site replaces the second data centre with a subscription for capacity, replication, tests and support. What to check in such a contract is in our DRaaS checklist before you sign, and what each kind of site keeps ready in our comparison of hot, warm and cold DR sites.

How to choose the distance for your systems

1. List what can stop the primary site: its river and flood zones, the substation and grid operator that feed it, the carriers and ducts of its links, industrial neighbours and where its staff are based.
2. Set RPO and RTO for each tier of systems, as in our guide on how to choose RPO and RTO.
3. For the tier that needs a recovery point of zero, find a second site whose measured RTT under load fits your product’s limit, and check it against that list.
4. For everything else, choose an asynchronous site that shares none of the entries on that list.
5. Size the link from each system’s change rate within its RPO interval, with headroom for peaks.
6. Write down why the distance is sufficient; the BSI criteria described above ask for a justification below 200 km.
7. Test the failover and record the measured recovery time against the RTO.

What we do

Our disaster recovery service gives you a recovery site in Baltneta’s Tier-3 data centres in Lithuania (ISO 27001, PCI DSS), geographically separate from your primary infrastructure and with EU data residency. Virtual machines replicate with Veeam from a 15-minute interval via Veeam Cloud Connect, managed from your existing Veeam console or entirely on our side, with RPO and RTO fixed in the SLA. Our engineering partner Vixen.UNO designs the DR strategy with you, including the disaster scenarios you protect against, and runs scheduled failover tests in an isolated environment, with a report after each one. If a system needs zero RPO, that is active-active synchronous clustering, a different class of solution and budget, and we say so on the first call, which is free of charge. The service and how we handle your data are described on our disaster recovery and security and compliance pages.

FAQ