What are data centres?
The buildings, power, cooling and networks that keep an organisation’s systems and data running.
Where the computers live.
A data centre is a facility that houses the servers, storage, networking equipment and supporting systems that run business applications, websites, cloud services and data. It has reliable power, cooling, network connections, physical security and fire protection, and is staffed or monitored all day, every day.
Almost every organisation depends on one, directly or through cloud computing, software or outsourced providers. That makes data centres central to IT service continuity and disaster recovery.
Common kinds of data centre.
Enterprise (own)
Built and run by one organisation for its own systems, such as a bank or government body.
Colocation
A provider rents space, power and cooling to many customers, who bring their own equipment.
Cloud and hyperscale
Very large facilities run by cloud providers, grouped in regions and availability zones.
Edge and micro
Small sites close to users or devices, for fast response and local processing.
Modular and containerised
Prefabricated units that can be added quickly, or placed where needed.
Managed hosting
A provider runs the servers and operations for the customer.
Disaster recovery site
A second facility, away from the main one, kept ready to take over critical systems.
On-premises server room
A small room in an office. Cheaper, but usually with limited power, cooling and resilience.
The building blocks of a resilient data centre.
Power
Utility supply from more than one feed where possible, uninterruptible power supplies (UPS) to bridge short interruptions, and generators with fuel for longer ones.
Cooling
Chillers, air handling and sometimes liquid cooling to remove heat. Cooling failure can force equipment to shut down quickly.
Network
Several carriers and routes into the building, with redundant routers and switches.
Physical security
Perimeter, access control, cameras, visitor logging and secure cages and racks.
Fire and environmental protection
Early detection, gas or water-based suppression, leak detection and monitoring of temperature and humidity.
Operations and monitoring
Staff and tools to monitor, maintain and respond to alarms, with procedures and escalation.
How resilience is described.
N, N+1 and 2N
N is the capacity needed. N+1 adds one spare unit. 2N duplicates the whole system. More redundancy costs more but reduces single points of failure.
Uptime Institute tiers
Tiers I to IV describe increasing levels of redundancy and availability, from basic capacity to fault-tolerant design.
Standards
Examples include ANSI/TIA-942, the EN 50600 and ISO/IEC 22237 series for data centre facilities and infrastructure, ISO/IEC 27001 for information security and ISO 22301 for business continuity.
Availability zones and regions
Cloud providers separate facilities so that a failure in one zone does not stop another. Customers must still design their own systems to use them.
Recovery objectives
The recovery time objective (RTO) and recovery point objective (RPO) decide how fast, and with how much data loss, systems must come back.
Location and risk
Flooding, extreme heat, earthquakes, power and water supply, and political or security risk should all be considered when choosing sites.
Testing
Test failover, generators, UPS and backups regularly. Untested equipment often fails when needed.
Sustainability
Power and cooling use is large, so efficiency, energy sources and water use matter more each year.
Active-active, active-passive and replication.
Resilient designs spread systems across two or more data centres. The main choices are how the sites share the work, and how data is copied between them. These choices set the recovery time objective (RTO) and recovery point objective (RPO).
Site configurations
| Design | How it works | Strengths | Limits |
|---|---|---|---|
| Active-active | Both sites run live workloads at the same time, with traffic shared by load balancing. If one fails, the other takes its share. | Very short failover, uses spare capacity, and can give near-zero downtime. | Complex. Needs data consistency across sites, enough capacity at each site to carry the whole load, and careful testing. |
| Active-passive (active-inactive, hot standby) | One site serves users. The second is running and kept in step, ready to take over. | Simpler to run and reason about. Quick failover. | The standby capacity is idle, and failover must still be triggered and tested. |
| Warm standby | The second site has systems installed but not fully running or current. Data may be copied regularly. | Lower cost than hot standby. | Takes longer to start and has a larger data gap. |
| Cold standby | Space and basic infrastructure, with hardware and data restored from backup when needed. | Lowest cost. | Slowest recovery, from many hours to days or more. |
| N+1 or multi-site | Several sites, with spare capacity across them so that loss of one is absorbed. | Efficient use of capacity. | Needs careful capacity planning and workload placement. |
Replication methods
| Method | How it works | RPO | Trade-offs |
|---|---|---|---|
| Synchronous replication | A write is confirmed only after it has been stored at both sites. | Zero or near zero | Adds latency to every write, so sites are usually within metro distance. A link failure can stall the primary unless configured otherwise. |
| Asynchronous replication | The write is confirmed at the primary and copied to the second site shortly afterwards. | Seconds to minutes, depending on lag | Allows longer distances and less impact on performance, but the latest changes may be lost in a failover. |
| Semi-synchronous | Confirmation waits for the second site to receive the data, but not necessarily to apply it. | Very low | A compromise between performance and data protection. |
| Snapshots and backups | Point-in-time copies stored on separate systems or sites. | Hours or more, depending on schedule | Protects against deletion, corruption and ransomware, and complements replication. |
Latency and distance
Signals take time to travel. Longer distance means higher latency, which is why synchronous replication is usually limited to metro distance and why far-away sites use asynchronous copying.
Three-site designs
Two nearby sites with synchronous replication, plus a third distant site with asynchronous copying, give zero data loss for local failures and protection from regional events.
Split-brain and quorum
If sites lose contact, both may think they are in charge. Witness or quorum systems decide which side continues, and prevent conflicting writes.
Failover and failback
Failover moves service to the other site. Failback returns to the original site safely after repair. Both should be planned, scripted and rehearsed.
Traffic steering
DNS, global load balancers and routing changes direct users to the working site. Their own resilience matters too.
Data consistency
Active-active needs careful design of databases and applications so that two sites do not conflict, using techniques such as clustering, sharding or conflict resolution.
Ransomware and corruption
Replication copies mistakes and malicious changes as well as good data. Keep immutable or offline backups and test restores.
Testing
Regular failover tests, game days and measurements of real RTO and RPO show whether the design works.
Terms and designs vary between vendors. Confirm the details with your architects and providers. See also What is Redundancy? and What is IT Disaster Recovery?.
What is cloud computing?
Cloud computing means using computing services, such as servers, storage, databases, software and networking, over the internet from a provider, instead of owning and running them yourself. You use what you need, when you need it, and usually pay for what you use. The services run in the provider’s data centres, so cloud and data centres are two sides of the same subject.
A widely used definition from the US National Institute of Standards and Technology (NIST) describes five features: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service.
Service models
Infrastructure as a service (IaaS)
You rent virtual servers, storage and networks, and manage the operating systems and applications.
Platform as a service (PaaS)
The provider runs the platform and runtime, and you deploy your own applications and data.
Software as a service (SaaS)
You use finished applications, such as email, payroll or customer relationship management, through a browser.
Function and container services
Code or containers run on demand without managing servers, often called serverless.
Deployment models
Public cloud
Services shared among many customers and run by a provider.
Private cloud
Cloud technology used for one organisation, in its own or a hosted data centre.
Hybrid cloud
A mix of on-premises or private systems and public cloud, connected together.
Multi-cloud
Using services from more than one provider, to reduce dependency or for specific features.
Cloud and business continuity
Shared responsibility
The provider secures and runs the facility and platform. You remain responsible for your data, access, configuration, backups and recovery design. Read the provider’s model carefully.
Regions and availability zones
Providers split their services across regions and zones. A system built in one zone can still fail with that zone, so design critical services to use more than one zone, and sometimes more than one region.
Concentration risk
Many organisations rely on a small number of large providers. An outage can affect many customers at once, and regulators increasingly look at this risk, including in the financial sector.
Backups and exit plans
Keep independent, tested backups, and plan how you would move or run elsewhere if a provider, contract or country becomes unavailable.
Data location and rules
Laws on where data can be stored differ by country and sector, including in the UAE, Saudi Arabia and the wider GCC. Check requirements from your regulators before choosing a region.
Supplier assessment
Ask for certifications such as ISO/IEC 27001 and ISO 22301, audit reports, incident history, service levels and how they will tell you about problems.
Examples of cloud disruption
February 2017, Amazon S3 outage
An operator error during maintenance was reported to have removed more servers than intended in a large US storage region, disrupting many websites and applications that depended on it.
June 2019, Google Cloud network outage
A configuration change was reported to have reduced network capacity in several regions, slowing or disrupting services for many customers.
2021 to 2023, regional facility incidents
Fires, flooding and cooling failures at individual data centres, such as those described above, showed that cloud services depend on physical buildings, and that customers need backups and spread across zones.
Examples are drawn from public reports and simplified. Check the original provider reports for details.
Is the cloud safer than our own data centre?
Does the cloud remove the need for disaster recovery?
What is the difference between cloud and a data centre?
When data centres fail.
March 2021, OVHcloud, Strasbourg
A fire destroyed one data centre and damaged others on the same site, taking many customers’ websites and services offline. Some customers who had kept backups only in the same place lost data.
October 2021, Facebook (Meta)
A configuration change during maintenance cut the company’s data centres off from the internet, and its services, and some internal tools, were unavailable for hours.
July 2022, London heatwave
Record temperatures were reported to have overwhelmed cooling at some data centres in the city, causing outages for some cloud services.
April 2023, Paris
A water leak and fire in a data centre building was reported to have affected a cloud region for some customers, showing the value of using more than one zone or region.
October 2023, Singapore
A cooling problem at a data centre was reported to have disrupted services at two large banks, leading to regulator scrutiny of outsourcing and resilience.
October 2012, Hurricane Sandy
Flooding in lower Manhattan hit basements housing fuel pumps and generators, and some data centres relied on staff carrying fuel up stairs to stay running.
GCC and Middle East
Banks, telecoms and governments in the Gulf rely on in-country and cloud data centres. Extreme heat, power and cooling, and the regional events in our 2026 GCC Incident Log, show why organisations should avoid concentrating critical systems in one location.
Examples are drawn from public reports and are simplified. Details and figures may differ between sources, so check the original reports for the full picture.
What organisations should do.
Know your dependencies
List the data centres, cloud regions and providers behind your critical services.
Set recovery objectives
Agree the RTO and RPO from the business impact analysis, not from what is easy.
Avoid single points of failure
Use a second site or zone, separate backups and more than one network route.
Check your providers
Ask about certifications, resilience, testing, incident history and how they will tell you of problems.
Back up off-site
Keep recoverable copies away from the production site, and test restores.
Exercise failover
Run failover tests and tabletop exercises with the IT, business and provider teams.
Plan for people
Staff may need to work from another place. See work area recovery sites.
Link to incident plans
Make sure data centre incidents trigger the incident management and crisis plans.
Data centre questions.
Is the cloud a data centre?
What is the difference between a data centre and a disaster recovery site?
How far apart should primary and recovery sites be?
Does a Tier IV data centre never fail?
Can ADVOX help with data centre resilience?
Talk to ADVOX about IT resilience.
We aim to reply to your enquiry within 2 hours during working hours.
Related reading: What is IT Disaster Recovery? | What is IT Service Continuity? | What are Work Area Recovery Sites (WRS)?