eco - Verband der deutschen Internetwirtschaft e.V.

11/10/2026 | News release | Distributed by Public on 11/11/2026 02:19

Resilience Requires Distance: What Matters in Geographically Redundant Data Centres

A single data centre location can become a risk in the event of widespread disruptions. Geographically redundant infrastructure therefore distributes business-critical systems across geographically separate locations - provided that networking, data replication and failover work together reliably.

Ahead of the final eco Data Centre Roadshow of the year on 26 November 2026 in Hannover, Maik Nyisztor from enviaTEL explains when a second location makes sense, what companies should consider during planning and why geographic redundancy is becoming increasingly relevant for business continuity and regulatory requirements.

What role does geographic redundancy play today in ensuring the resilience of business-critical IT systems, and in which scenarios is a second, geographically separate location particularly beneficial?

For us at enviaTEL, geographic redundancy is the foundation for making business-critical IT systems truly resilient to outages: If one location goes down due to a fire, power outage or cyberattack, the second location automatically takes over operations. A single data centre, on the other hand, always remains a single point of failure that can jeopardise the entire business operation. With our data centres in Leipzig and Hannover, as well as additional partner locations, we offer companies precisely this geographically separate infrastructure in Germany. In addition to traditional operators of critical infrastructure, a second location is particularly beneficial for companies subject to strict compliance requirements, for which predictable recovery times and customer trust are vital, or where downtime directly jeopardises revenue.

What should companies consider when planning a geographically redundant infrastructure, and what technical requirements must be met to ensure that two data centre locations work together reliably in an emergency?

First, the geographical distance must be appropriate - we follow the BSI recommendation of approximately 200 kilometres, as is the case with our locations in Leipzig and Hannover, so that a major incident, such as a prolonged, widespread power outage, does not affect both locations simultaneously. From a technical standpoint, the appropriate strategy depends on the criticality of the systems, desired recovery times, data volume and the customer's budget. Essentially, both data replication between the sites and a clearly defined failover process must be in place to ensure that the switchover works not only in theory but also in practice during an emergency. Finally, companies should test how these components work together regularly - geographic redundancy that exists only on paper does not help anyone in an emergency.

How are increasing requirements for availability, business continuity and regulatory compliance changing the importance of geographic redundancy in companies' IT strategies?

With critical infrastructure requirements (KRITIS), NIS2 and DORA, geographic redundancy is increasingly becoming a requirement that must be demonstrated - rather than a voluntary option - for many of our customers, particularly operators of critical infrastructure and companies in the financial sector. At the same time, customers and business partners have rising expectations for continuous availability - an outage lasting several hours is hardly acceptable in many industries today. That's why we and our data centres in Leipzig and Hannover are certified to ISO 27001, ISO 9001, ISO 50001 and data centre-specific standards such as EN 50600, so that customers can also use these certifications as evidence of their own compliance. For us, geographic redundancy is no longer merely a technical issue; we view it as an integral part of our customers' corporate strategy and risk management.

What role does connectivity between sites play in ensuring effective geographic redundancy, and what factors are particularly important when it comes to bandwidth, latency and redundant connections?

Even the best geographic redundancy is of little use if the connection between sites becomes a bottleneck - which is why network connectivity is actually the heart of the entire concept. Key factors include sufficient bandwidth for data replication, low and - above all - stable latency to ensure that synchronous mirroring does not stall, as well as redundant, physically separate transmission paths to prevent the connection itself from becoming a single point of failure. We typically implement such site-to-site networking for our customers using our own fibre-optic connections with bandwidths of up to 100 Gbit/s and optional redundancy ports. It's also important that the cable routes themselves run separately - two cables that happen to run through the same trench do not provide true redundancy in the event of a failure.

What additional possibilities arise when interconnection services are available across multiple sites alongside a geographically redundant data centre infrastructure?

When interconnection services - such as direct cloud connections or peering points - are added to the geographically redundant data centre infrastructure, basic resilience to outages becomes genuine flexibility. Customers can then, for example, connect directly and redundantly to platforms such as Microsoft Azure or AWS via Cloud Connect without having to route traffic through the public Internet - which reduces latency while simultaneously increasing security. Peering points such as DE-CIX Leipzig can also significantly accelerate data exchange with other networks. Overall, this creates an ecosystem in which not only are the company's own systems mirrored to ensure resilience to outages, but connections to cloud services, partners and customers also benefit from the geographically redundant infrastructure.

eco - Verband der deutschen Internetwirtschaft e.V. published this content on November 10, 2026, and is solely responsible for the information contained herein. Distributed via Public Technologies (PUBT), unedited and unaltered, on November 11, 2026 at 08:19 UTC. If you believe the information included in the content is inaccurate or outdated and requires editing or removal, please contact us at [email protected]