中国备份与跨境数据传输合规：电信厂商实例

一句话结论： "我们中国的备份到底放在哪里？"看起来像技术问题，通常不是。三件事被揉在了一起——数据本体在哪、副本去了哪、多快能恢复回来。把它们分开逐一回答，才能把一个继承下来的默认配置，变成一套你解释得清的安排。法律判断请交给你自己的法律顾问。

为什么中国的备份安排会变成跨境数据传输合规问题？

备份是 IT 环境里最不光鲜的部分，而这恰恰是它被配置一次然后就一路继承下去的原因。有人建了一个任务，它变成绿色，接下来四年没有人有理由去看它。这在几乎任何地方都没问题。在中国实体里，它迟早会变得有问题——不是因为备份坏了，而是因为有人对它提出了一个和"它是否能用"完全无关的问题：一个跨境数据传输合规问题，而中国的 IT 团队从来没被要求为此做准备。

这个问题通常来自中国办公室之外。一次集团 IT 审查、一份新的全球数据治理政策、一家企业客户的供应商问卷，或者集团自身风险登记册的一次变更。而这个问题很少是"备份在跑吗"，而是"这些数据去了哪里，是谁决定这样做没问题的"。

这是一个性质完全不同的问题，而一家六十到一百二十人的中国实体常常回答不了它——不是因为疏忽，而是因为这个安排从来就不是一个决定，它是一个默认值。集团有一个区域云租户，中国办公室按集团标准接入，备份目标就指向了那里，因为在当时那是阻力最小的路径。

Brocent（2007 年成立，总部位于新加坡）自 2007 年起在中国大陆运营本地交付团队，服务全国各地的外商投资实体。"运行良好、但没人能用治理语言解释清楚"的备份，是我们接手一个中国环境时最常见到的情况之一。

有一点必须先说清楚，因为它决定了下文的全部框架：某一条数据出境流向是否被允许、以何种机制被允许，是一个法律判断。它取决于数据是什么、涉及谁、体量多大，以及一套已经多次变化、并且还会继续变化的规则。本文讲的是这个问题在运营层面的形状，以及那些让它变得可回答的做法。它不是法律意见，合规判断应该由你自己的法律顾问做出，而不是由你的 IT 服务商。

引出这个问题的那次审查：一个复合情境

以下是示意性内容——根据外资电信与设备厂商的中国实体真实运作方式提炼出的复合情境，不是某一家具名客户。

一家欧洲电信基础设施厂商，中国实体大约九十人。该实体不做制造；它持有区域备件库存，为奔赴全国各地运营商和企业客户现场的工程师做现场服务排程，并保存工程文档、现场勘测记录，以及部署在这些现场的设备配置文件。本地有一台文件服务器、几台应用服务器，以及大约一百一十个终端。

本地的 IT 编制是一个人，能力确实不错，但严重超载。备份是五年前由一位早已离职的工程师配置的。它每晚把文件服务器和现场服务数据库备份到集团的区域云租户，而该租户托管在新加坡。它从来没有以任何人注意得到的方式失败过。它也从来没有被真正恢复过，除了 2023 年一次文件级恢复，那次是成功的。

然后集团 IT 下发了修订版的数据治理标准，其中一项要求是每个实体记录自己的运营数据存储和复制位置，并识别出任何跨境流向。中国 IT 负责人读完，意识到自己没办法诚实地把这张表填完。他知道备份去了新加坡。他不知道里面除了"文件服务器"之外具体有什么——从来没有人清点过内容。他不知道里面的客户现场记录和工程师排程数据，是不是这份标准所担心的那一类。他也不知道公司里是谁决定这样做可以接受的，因为就他所知，从来没有人做过这个决定。

而当他开始翻查时，他还发现了两件本来不在找的事。由于十一个月前一次主机名变更，每晚的任务一直在悄悄跳过其中一台应用服务器。而在集团那一侧，恢复路径要走的正是那条在真正出事时最拥堵的跨境链路。

一条没有记录的数据路径，实际代价是什么？

请注意，以下只有一项是合规代价。其余都是同一种疏忽所产生的普通运营风险。

面对集团合规没有答案，而诚实的答案听起来比实情更糟。 "我们备份到新加坡，我不太确定里面有什么"是一句真话，但在治理审查人员听来，它读起来像是一项未受管理的风险。真实风险和这个答案听起来的样子之间，差距往往很大，而弥合这个差距主要是文档工作，不是重新做架构。

没有人验证过备份能恢复。 一个报告成功的备份任务，只证明数据被写出去了。它不证明数据能被读回来、不证明它所属的应用能基于它启动，也不证明有人知道恢复流程。静默失败很常见，而且特别难被发现：改名之后悄悄不再覆盖某台服务器的任务、把某样东西唯一副本按保留策略淘汰掉、在没有正确一致性处理的情况下热备的数据库。这些都不会自己宣告出来。

恢复路径取决于最坏情况下的网络。 如果一百多 GB 运营数据的唯一副本在另一个国家，你的恢复时间就是事故当天那条跨境链路的函数。而那条链路在区域性中断期间不会处于最佳状态，在季度末也不会。一个从来没有被真正算过的恢复时间目标，往往是在它本该覆盖的那次事件中被痛苦地发现的。

中国境内的云和团队熟悉的那一套行为不同。 这一点反复让人意外。主要国际云在中国大陆只能通过强制性的持牌本地运营方运营——Azure 中国由世纪互联（21Vianet/VNET）运营，AWS 中国区由光环新网（Sinnet）和西云数据（NWCD）运营——它们是与全球版本在法律上和技术上都相互独立的环境，账号独立、服务目录独立、功能上线节奏也独立。托管还会把面向互联网服务的 ICP 备案要求纳入范围。一份按全球 Azure 或全球 AWS 写就的集团标准，不能原样搬到中国；而一位假定它可以的工程师，会造出一个和文档描述不一样的东西。

没有人拥有这个问题。 中国办公室假定集团 IT 定了标准。集团 IT 假定中国办公室懂本地要求。这是最常见的失效模式，而它之所以持续存在，是因为两边的假定单独看都很合理。

我们的看法：把被揉在一起的三个问题拆开

当这件事落到我们桌上时，有用的第一步不是重新设计任何东西，而是把一个混淆的问题拆成三个清晰的问题——因为它们答案不同、责任人不同、紧急程度也不同。

数据本体在哪里？ 这说的是主副本——文件服务器、应用数据库、大家每天在里面工作的那些系统。对多数中国实体来说，这直截了当地在中国境内，而且不是任何人担心的那一部分。

副本去了哪里？ 这是备份与复制的问题，也是上面那个情境里演变成治理议题的那一个。它有两个常被混为一谈的半边：被复制的是什么（这需要一次真正的清点，而不是一个假定），以及每一份副本落在哪里。

多快能恢复回来？ 这是恢复问题，纯粹是运营层面的，完全没有法律维度。它同时也是实务中最可能伤到你的那一个，因为它是事故会去检验的那一个。

分开回答这三件事，通常会让问题变简单而不是变复杂。据我们的经验，当一家中国实体真的把备份里的内容清点一遍之后，"确实需要出境的数据"这个集合，往往远小于"因为默认配置而正在出境的数据"这个集合。一份在本地、经过恢复验证的备份，加上一小组有明确记录、写清了为什么的跨境数据，无论在运营上还是在可辩护性上，都胜过一句没有记录的"全都传到集团租户"。

中国实体处理这件事的三种方式

直接备份到集团的境外租户。 简单、与全球标准一致，也不需要在本地做任何决定。但内容通常没有清点过，跨境流向是一个默认值而不是一个有记录的决定，而恢复时间取决于最糟糕那天的国际链路。只有当确实有人看过里面是什么、并且能解释为什么这样安排合适时，它才是可辩护的。
只做本地备份，什么都不出去。 形态上合规、也容易解释，而且它彻底解决了恢复时间问题。但它的弱点是真实的：只有一个站点、没有地理隔离，这不构成一个灾备位置。一场火灾、一次水淹，或者一次波及到备份目标的勒索软件事件，会同时带走两份副本。这是被合规问题吓到的实体常见的过度纠正——用取消第二站点的方式解决了问题。
境内备份 + 经过验证的恢复 + 有记录的出境数据集。 主备份目标位于中国境内，恢复时间目标和恢复点目标是与业务商定的，而不是继承来的。恢复演练产出带日期的证据，证明恢复确实可行。地理隔离在中国境内实现。而一小组被明确列出的数据出于真实的集团用途跨境，并附有一份有人签字的书面理由。前期工作量更大，但它是三者中唯一同时回答了合规问题和恢复问题的。

一套可辩护的中国备份实践包含什么？

细节比架构图更重要。以下是我们认为必须存在的东西。

与业务商定、而不是继承来的 RTO 和 RPO。 恢复时间目标和恢复点目标是其余一切的推导起点，而在多数继承下来的配置里，没有人说得出它们是多少。它们不该由 IT 单方面决定——"现场服务排程停多久会开始造成客户承诺上的损失"是一个业务问题，而文件服务器和备件系统的答案差别很大。Brocent 的云托管备份是从这里开始的，而不是从工具开始，因为本地与云端的保留策略、目标选型和架构，全都是这两个数字的下游产物。

监控，让静默失败在同一周内浮现。 上面情境里那十一个月的空档，是无人监控的备份任务的正常结果，而不是一个异常。备份任务监控需要是某个人真正的职责，并在失败时告警，而不是一个指望忙人记得去打开的仪表板。在管理型IT外包服务方案下，这由我们的服务控制与网络运营团队 7×24 执行，任务失败时立即告警——这就是"一周内发现空档"和"在恢复过程中发现空档"之间的区别。

一次能产出带日期结果的恢复演练。 这是最常被跳过的一项做法，也是唯一真正能证明什么的一项。周期性恢复演练把真实数据恢复到一个经授权的测试环境里，验证它完整可用，并产出一份演练报告，记录哪些恢复成功、哪些没有。报告才是重点。它把"我们有备份"从一种信念变成一件产物，而这正是集团治理审查人员和你自己的管理层都想看到的东西。演练还会暴露监控抓不到的那些不光鲜的失败：基于恢复出来的数据库启动不了的应用、缺失的服务账号、只有那位已离职工程师知道的、没有写下来的一个步骤。

搞清楚你实际在用哪一朵中国的云，以及它由谁运营。 如果你在中国大陆托管，请对"你托管在什么之上"这件事保持精确。国际云通过持牌本地运营方以独立环境的形式运行——Azure 中国经由世纪互联（21Vianet/VNET），AWS 中国区经由光环新网（Sinnet）与西云数据（NWCD）——此外还有国内云厂商和中立第三方数据中心运营商。合同、支持路径、可用服务和功能对齐程度，都与全球版本不同。对中国实体而言，托管云服务意味着在照着设计之前就知道这些差异，而不是在实施过程中才发现。它同时也意味着 ICP 备案的问题在设计阶段就被提出来，而不是在上线时。

一份"什么被复制到了哪里"的清单。 能够终结治理对话的那份文件，不是架构图，而是一份清单：来自这些系统的这些数据集，按这个周期被复制到这些目标，保留这么久，出于这个原因。做出这份清单很枯燥，通常要花上一两天。但它也是整个练习中价值最高的单一产物，因为正是它让人能够对"跨境的那一部分"做出知情的决定，而不是把它继续留作默认值。当这些数据集包含带有安全或保密义务的材料时，这份清单会直接输入到那些控制措施如何施加的问题上——而这也是管理型IT安全服务和备份设计不再是两场独立对话的地方。

这件事和集团的全球标准是什么关系？

集团层面的直觉通常是"一套标准全球通用"，而这个直觉在精神上是对的。错误在于把它当作"一套实现全球通用"。

一个可行的模式是：把标准维持在结果层面——每个实体都有记录在案的 RTO 和 RPO、被监控的任务、经过验证的恢复、以及一份被复制数据的清单——同时允许实现方式在本地环境确实不同的地方有所不同。中国是这一点最清晰的案例，但它并不特殊；任何本地托管或监管现实与总部假设发生偏离的地方，同样适用这个逻辑。

这个框架同时也解决了归属问题。集团 IT 拥有标准和结果。中国实体拥有实现和证据。而两者都不拥有关于跨境传输的法律判断——那属于法律顾问，并由 IT 侧产出的那份清单来支撑。Brocent 服务过的电信行业客户包括一家覆盖六十八个国家的全球电信基础设施供应商；在多国安排中，这种责任划分始终是行得通的那一种：一套共同的标准、在本地正确的实现，以及由有资格的人做出的法律判断。

常见问题

把中国办公室备份到境外的云，是不是自动就有问题？

不是。而任何告诉你"这自动没问题"或"这自动被禁止"的人，都在过度简化。某一条特定流向是否被允许、以何种机制被允许，取决于数据是什么、涉及谁、体量多大，以及一套已经多次变化的规则。这是给你自己的法律顾问做的判断，不是给你的 IT 服务商做的。我们能告诉你的是：要拿到一个真正的答案，实务上的前置条件是把备份里到底有什么清点出来——多数实体拿不到法律意见，是因为他们描述不出那份数据。

在这个语境里，备份和灾备有什么区别？

备份是数据的副本。灾备是在约定时间内让业务重新跑起来的能力。你完全可能拥有出色的备份却没有任何灾备位置——只有一个本地备份目标、没有第二站点，给你的恰恰就是这个；而只有一份境外副本、恢复路径跨境且缓慢，给你的也是这个。把两者连起来的概念是恢复时间目标和恢复点目标，再加上一份记录了"到时候某个人实际要走哪些步骤"的业务连续性计划。没有这份计划的备份，是数据，不是恢复。

恢复到底应该多久测试一次？

底线是至少每年一次，并且在任何重大变更之后——新增应用、服务器迁移、更换备份目标，或者更换负责这件事的人。测试必须是把数据真正恢复到一个经授权的环境里，而不是验证备份文件能打开。而且它必须产出一份带日期的报告，因为对审查人员来说，一个未经测试的声明和一次没有记录的测试，价值差不多。

哪些云服务商可以合法在中国托管这类数据？

可选项包括国内云厂商、中立第三方运营商，以及通过强制性持牌本地运营方落地的国际云——Azure 中国经由世纪互联（21Vianet/VNET），AWS 中国区经由光环新网（Sinnet）与西云数据（NWCD）。其中哪一个适合你这份特定数据，是一个把法律处境和技术要求结合起来的问题，而法律那一半不该由我们回答。我们要从运营角度提醒的是：这些环境在账号、服务目录和功能节奏上，都与全球版本真正独立，所以一份在全球 Azure 或 AWS 上验证过的设计，需要重新验证，而不是平移。

如果我们关闭这个实体，中国的数据会怎么样？

在需要之前就规划好，因为实体关闭有一个数据维度，很容易被留到最后，而到最后就很难处理。实务上的问题是：什么必须保留、保留多久、可以保留在哪里、什么必须销毁、销毁需要什么证据，以及谁持有那些存续下来的东西的凭证。在管理型IT外包服务方案下，环境文档与凭证归客户所有，而这一点在退出时比在这段关系的任何其他时点都更重要。至于保留和销毁义务本身，仍然是一个法律问题。

这个问题归谁——中国办公室还是集团 IT？

拆开。集团 IT 应该拥有标准和所要求的结果。中国实体应该拥有实现并产出证据。法务或合规应该拥有"什么可以跨境"的判断，并以那份清单为依据。我们见得最多的失效模式是双方都不拥有它，因为每一方都假定对方已经拥有了；而修复方式是行政性的而不是技术性的：写下三者各归谁，并给那份清单一个截止日期。

我们的中国团队很小。一套像样的备份实践对我们现实吗？

现实，而且规模这个论据通常是反过来起作用的。一家九十人、只有一位 IT 人员的实体，恰恰是"没有外力就不会发生监控、演练和文档工作"的那种处境，因为那个人的一周已经被正在着火的事情占满了。务实的路径是把周期性的那几件事——任务监控、演练、年度文档更新——变成某一方受合同约束的职责，而不是一个意愿。这正是管理型IT外包服务在这个规模上的用途：不是取代你的 IT 负责人，而是接走那些可靠地会被拖延的工作。首页的报价工具会为中国大陆办公室在按用户计价的方案旁边，同时列出云备份按设备计价的附加项，让你在联系任何人之前就能看到这些周期性工作的费用。