Most guidance on deploying in China is written for the first site, which is reasonable — the first deployment carries the hardest questions about entity, licensing, ICP, and whether the workload belongs in-country at all. Teams that cleared those questions two or three years ago tend to arrive at a quieter second one. Production is live, it matters now, and it is running in a single location. If that describes your estate, the next decision is where a second site goes — and in China the constraints on that choice work differently than they do elsewhere in the region.
Why does a China DR site usually have to sit inside China?
Generally because the data cannot leave. Under Article 37 of the Cybersecurity Law, operators of critical information infrastructure must store personal information and important data collected in China within the mainland, and may transfer it abroad only after a security assessment. For workloads in that scope, a recovery site in Singapore or Hong Kong is not a straightforward option.
It is worth separating this from the wider cross-border conversation. China adjusted its cross-border data-flow framework in March 2024, easing some transfer routes, and that is sometimes read as reopening offshore DR. In practice the easing applies to defined categories and does not remove the storage obligation for in-scope operators. Whether a given workload falls inside that scope is a question for counsel rather than for infrastructure, but it is worth asking early — the answer determines whether the second site is a China question at all, and that shapes everything downstream.
How far apart do the two sites need to be?
Far enough to survive the same event, close enough to meet the recovery point objective. That tension is most of the geographic decision, and it tends to resolve at a fairly specific distance. Synchronous replication — the mode that gives zero data loss — is practically bounded at around 100 kilometres, because round-trip latency beyond that starts to exceed what most databases tolerate.
Past roughly 100 kilometres, replication becomes asynchronous: any distance is possible, but the recovery point is no longer zero. The useful consequence is that the distance question largely answers itself once recovery objectives are set. A workload that genuinely requires zero data loss is describing a site in the same metro. A workload that needs to survive a regional event is describing a site far enough away that some data loss on failover has to be designed for. Most enterprise estates contain both kinds of workload, which is why these two patterns are more often combined than chosen between.
Does a second site with the same provider in the same metro count?
It depends what the second site is meant to protect against. A same-metro standby with the existing provider is a genuinely useful thing — it handles facility-level failure, gives fast failover, and supports synchronous replication. It is simply not doing the job a regional event requires.
The reason is that resilience follows shared dependencies rather than distance alone. Two sites 30 kilometres apart on the same regional grid, in the same flood basin, reached over the same fibre routes and operated by the same entity share most of the failure modes that would take the first one offline. China adds a layer here, because facilities are operated by licensed local entities. That makes the operator an operational dependency and a regulatory one at the same time — a consideration that does not really arise in markets where an international provider holds the licence directly, and one reason the provider evaluation for a China second site looks different from the same exercise elsewhere in the region.
What does that leave for the second site?
In practice, a different metro in a different part of the country, operated by a different entity. For the many multinationals whose China production sits in Shanghai with an international provider, that points north.
Beijing sits more than 1,000 kilometres from Shanghai — a different metro, a different climate and flood profile, and a separate set of network paths. Whether the two sites also draw on genuinely separate grid infrastructure is worth confirming directly with both providers rather than inferring from distance. Beijing also carries a secondary benefit that is easy to overlook when a site is framed purely as insurance: a recovery site in the capital sits close to users, branches, and counterparties across northern China, so standby capacity can do something useful between incidents. That tends to matter for how well the site is maintained. This is the same in-country pairing logic that shapes how enterprises weigh Tokyo against Osaka in Japan, applied to a market where the onshore requirement makes the pairing less optional. Digital Edge operates in Beijing through PEK1, which is the footprint the later sections work through in detail.
How do power, water, and land shape a northern China site?
These three shape which sites exist in the first place, and they behave differently in China than the compliance discussion suggests.
On power, China steers large compute toward energy efficiency, and under the national “East Data, West Compute” strategy toward western provinces with cheaper and cleaner supply. Tier-1 hubs including Beijing apply strict efficiency requirements to new data centers, so high-density and AI-heavy builds face tighter siting constraints in the capital than inland. On water, northern China including the Beijing–Hebei corridor is water-stressed, which makes cooling-water access and local usage rules a genuine design input rather than a footnote. On land, tier-1 metro land and power allocations are constrained and often policy-gated, which affects both cost and build cycle.
Read together, these point somewhere slightly counterintuitive for a DR conversation. They mostly constrain *new* capacity in the capital, which raises the practical value of an operating facility with power already allocated. For a team that needs a recovery site working within a planning cycle rather than a construction cycle, an existing footprint is often the more realistic starting point. The China colocation guide covers how these same factors apply to a first deployment.
What replication model does that distance imply?
Asynchronous, with a recovery point measured in seconds or minutes rather than zero. That follows from the distance, and it is easier to treat as a design input than as something to negotiate away.
One way teams resolve it is to run both patterns rather than pick one. Synchronous replication to a standby in the primary metro covers facility-level failure with no data loss; asynchronous replication to a distant site covers the regional event. The two are complementary, and separating them clarifies what each site is for — which in turn clarifies how much needs to run at the second site. That is the real cost dial: a cold site holding backups, a minimal always-on footprint that scales up on failover, a scaled-down running replica, or a fully active second site carrying live traffic. Matching that posture to the recovery objectives set at the outset is usually what keeps the budget conversation grounded.
What is worth checking before committing to a second site?
Much of the standard colocation evaluation applies unchanged. A few things shift when the site is a recovery site rather than a primary.
Availability is worth comparing directly rather than assuming parity, since a DR target with weaker power topology than the primary quietly caps the resilience of the whole design — UPS redundancy and dual-power commitments are the concrete points of comparison. Certification scope matters in a specific way here: if the primary sits within China’s graded cybersecurity protection regime, it is worth confirming with counsel whether the recovery site needs to hold the same level, because a gap there can undermine the compliance position the second site was meant to support. Failover testing deserves an explicit contractual conversation, since a recovery plan that has never been exercised is an assumption. And remote hands and escalation carry more weight than usual, because the second site is typically in a metro where the team has no permanent presence, and will be leaning on the provider precisely when things are going badly.
Density deserves a slightly different question here than it gets in a primary-site search. The instinct is to look for parity with production, but DR sizing tends to follow recovery scope rather than the full footprint — most teams fail over a defined tier of transactional, database, and core application systems rather than the entire estate, and those tiers usually sit at moderate density. It is also worth asking how per-cabinet figures are allocated, since a published number often describes a design average across a hall rather than a fixed limit for a given deployment. The productive conversation is what the recovery scope actually draws, and how the provider can arrange power to meet it.
How PEK1 maps to a Shanghai primary
Against that checklist, this is where our own Beijing facility sits. PEK1 is in Chaoyang District, operated in partnership with a fully licensed nationwide IDC operator, Chuanjun Information Technology (Shanghai) Co., Ltd. — a Shanghai-registered company, though PEK1 itself is a Beijing facility. For a primary running in Shanghai with an international provider, that means both the metro and the operating entity change.
On availability, the facility runs 2N UPS redundancy with a 100% dual-power SLA, and holds CQC GB50174-2018 Level A, China’s national data center classification at its highest grade. On compliance, it meets Cybersecurity Protection Level 3 alongside ISO/IEC 27001, SOC 2 Type II, and PCI DSS. That combination tends to matter more for a recovery site than a primary, because it lets a parent company’s existing audit and security review process assess the site without commissioning a separate China-only assurance exercise — often the practical blocker when a security team first looks at a mainland facility. On capacity, 7.8 MW across 1,801 cabinets in 8,361m² leaves room to absorb a meaningful production load on failover rather than a token presence, at a published 4.4 kVA per cabinet. On connectivity, the Chaoyang location sits on Beijing’s network infrastructure, which is what the replication link between the two sites ultimately depends on — interconnection design usually determines whether a DR pair performs as intended far more than floor space does.
None of this makes the decision automatic, and the density and testing questions above are worth putting to us directly. What it does mean is that a China primary has a credible recovery pairing available in Beijing without a new build or a new market entry — the facility is operating, the licensing is in place, and the compliance posture is already documented. That is usually the point at which a second-site conversation becomes worth having.
Conclusion
The second site is a different exercise from the first deployment, and the China colocation guide covers the ground that comes before it. Once production is live, the constraints narrow fairly quickly: the onshore requirement tends to keep the recovery site in China, the need for genuine separation makes the same metro with the same operator a harder case to argue, and the distance that follows sets the replication model.
For a Shanghai primary that path leads somewhere reasonably specific, though the sequence matters more than the destination. Setting recovery objectives first and working outward to distance, replication, and site tends to produce a design that holds up to both an auditor and an incident review — which is a more useful test than whether it looked efficient on the day it was procured.
Talk to Digital Edge
If your China production is already live and the second site is the open question, Digital Edge can work through what PEK1 in Beijing would look like as your recovery site — recovery scope, replication, density, and failover testing — alongside our wider China data center capabilities and the interconnection between the two sites. Talk to our team to test it against your recovery objectives.
