OVHcloud 火灾表明数据本地化不等于灾难隔离

摘要

• 2021 年 3 月 10 日 00:35，OVHcloud 斯特拉斯堡站点的火警报警器启动。火灾始于 SBG2 底层的能源室，摧毁了该建筑，并损坏了 SBG1 十二个房间中的四个，并迫使整个园区断电。SBG3 和 SBG4 并未被最初的火灾吞噬，但由于需要进行电气隔离、安全检查、清洁和分阶段重启，那里的服务无法使用。没有人员伤亡。
• 法国工业安全调查并未确定在 UPS 及其相关铅酸电池上观察到的近乎同时的电气故障的确切原因。它确定了传播和响应因素：斯特拉斯堡的五栋建筑中均未安装自动灭火系统，烟雾通过 SBG2 的开放式冷却设计迅速传播，消防用水容量有限，以及困难的站点级电气关闭。有效的探测、夜间值班人员、保护 SBG3 的防火分隔，以及一艘大容量法德消防船的抵达，限制了更严重的后果。
• 可用性损失和永久数据丢失是两种不同的结果。OVHcloud 报告称，约 65,000 名客户和 120,000 项服务受到影响，而 Netcraft 观察到约 464,000 个域下的 360 万个网站处于离线状态。OVHcloud 表示，许多数据丢失的客户并未选择可选的备份服务。这并未结束问责问题：OVHcloud 自己的注册文件指出，提供的备份可以存储在同一数据中心或不同的数据中心，而后来的一项上诉判决涉及一家客户，其付费的自动备份与生产服务器在同一栋建筑中被销毁。
• 该事件暴露了云采购中的一个类别错误。数据主权、法律管辖权、延迟、可用性、备份和灾难恢复是相关但不可互换的。将数据保存在法国或欧盟可以满足本地化政策，同时仍然允许生产和恢复副本共享同一个物理危险。相反，一个地理上遥远的副本可以留在同一法律管辖区内并受相同的欧洲管控。
• OVHcloud 披露了火灾后的重大变化，包括更广泛的自动灭火、更强的分区、独立的能源室、远程电源切断、站点审计、与消防部门的合作，以及新的多区域和远程备份选项。然而，负责任的闭环需要提供特定于服务和站点的证据：已完成的控制措施覆盖范围、独立检查、真实的消防和电源隔离演习、声明的备份位置、成功的恢复测试，以及证明客户恢复不依赖于受影响的区域或同一控制平面的证据。

一场物理火灾成为云问责事件

“云端数据”这个说法鼓励了一种抽象思维。当工程师需要一个标准接口来获取计算能力时，它是有用的，但当决策者开始将位置、电力和火灾视为别人的细节时，它就是危险的。每一台虚拟服务器都位于一个房间里。每一个存储副本都占用连接到电力和冷却系统的设备。每一个恢复工作流都依赖于人员、网络、凭证、目录，以及一个可以获得替代容量的地方。

斯特拉斯堡事件使这一物理链条变得可见。2021 年 3 月 10 日凌晨，一场大火摧毁了 OVHcloud 位于 Port du Rhin 园区的建筑之一 SBG2。SBG1 部分被毁。尽管公司最初的更新声称站点上另两座数据中心未受损，它们也被关闭了。因此，损失至少通过三种不同的机制扩散：设备被物理摧毁；相邻建筑中的设备暴露于热量、烟雾、水或不确定性中；以及在站点必须被电气隔离并确保安全时，完好的设备也变得不可用。

这些机制很重要，因为它们对应着不同的控制措施。自动灭火和防火分区可以控制火灾。独立的电源区域可以减少消防员需要断电的范围。当一个站点不可用时，多站点应用可以继续运行。一个远程的、经过验证的备份可以在数据被毁后支持重建。一个状态页面可以指导客户通过这些选项。将这一切称为“冗余”掩盖了谁控制每一层以及它能承受什么样的事件。

最权威的公开重建是法国工业风险调查局（Bureau d'enquêtes et d'analyses sur les risques industriels）2022 年 5 月的调查报告。其任务是预防，而不是分配民事或刑事责任。这一界限很重要。该报告可以确定观察结果、可能的原因、促成因素和安全建议。它不能被转化为法院的裁决，即每一个被指出的弱点都是疏忽，或者一个弱点在法律上导致了某个特定客户的损失。

问责分析提出的是一个相关但更广泛的问题：哪些行为者有权控制那些让一次夜间设备事件演变成多栋建筑停电、漫长恢复和不可逆客户损失的条件？OVH 控制了站点的设计和运营、提供的产品、其描述的准确性以及响应。客户控制了工作负载分类、架构、许多服务选择以及独立副本。监管机构和专业机构控制了最低框架的一部分。这些角色中没有哪一个可以抹杀其他角色。

证据证实了什么，又未证实什么

BEA-RI 报告将第一次警报时间定为 00:35。一名保安在 00:37 到达 SBG2 的一个能源室，发现了浓黑的烟雾。该建筑于 00:39 疏散，Bas-Rhin 消防和救援服务部门于 00:42 接到电话，首批队员于 00:59 到达。OVH 的公开事件页面将 00:47 作为火灾发生的时间。这种差异应当保留下来，而不是被强制统一为一个时间戳：安全调查可以访问警报和运营记录，而公司页面提供了一个公开的事件标记。

SBG2 的应急电源于 01:13 被切断，SBG1、SBG3 和 SBG4 的应急电源于 01:28 被切断。消防队员看到了电弧，并且在进行重大喷水作业前必须控制住风险。到 01:42，火势已经蔓延到了整个一层。大约在 02:00，消防队员报告 SBG2 全面着火。大容量消防船 EUROPA 大约在 03:00 抵达，从邻近的水道取水。大火于 10:02 被扑灭，干预行动于 18:13 被认为结束。

调查将火灾的起源定位在存放电池和不间断电源设备的房间。视频和监测记录显示，在 UPS 单元 ASI2 及其相关电池上几乎同时发生了电气故障，这两个单元位于不同的房间。当天早上对该 UPS 进行了维护，当天晚些时候出现了异常的湿度测量值。调查人员列举了几种假设，包括潮湿、与维护相关的故障，或者在预期条件之外运行。他们明确表示，证据不足以确定一个精确的起始原因。

这种克制在那些说泄漏的冷却系统或最近维修过的 UPS“导致”了火灾的复述中常常被丢失。官方的法国 ARIA 事故记录对于厂房环境和响应是有用的佐证，但它并没有将一个看似合理的机制变成已被证实的根本原因。一个可信的叙述应该说，早期的电气事件和起源区域是已知的；但这些事件发生的原因在已发布的 BEA-RI 报告中并未解决。

这种区别并不妨碍控制分析。一个组织必须为设备故障做好准备，而无需知道下一个故障的组件是哪一个。消防保护正是围绕这种不确定性设计的。问责的问题不仅仅是 OVH 是否应该预见到某一特定的电气序列。而是在某物点燃之后，探测、自动控制、防火分区、水、电气隔离、建筑设计和应急程序是否为人员和邻近服务提供了足够的独立保护。

建筑探测到了危险，但无法遏制它

斯特拉斯堡站点很好地完成了一项生命安全任务。光学和吸气式烟雾探测器发挥了作用。夜间值守使得能够快速核实并及早召唤消防员。所有人都逃生了，没有人员受伤。BEA-RI 报告认可了这些控制措施。问责制应该像保留失败屏障一样仔细地保留成功的屏障，因为未来的设计取决于知道是什么真正赢得了时间。

探测并没有配合自动灭火。调查发现，该站点的五栋建筑都没有自动消防系统。SBG2 的电池和 UPS 室受到监控，但没有系统被设计用来在最早阶段扑灭、控制或延缓火灾。这样的系统本可以在完全切断电源之前就采取行动，并且不会让消防员暴露在带电设备之下。它并不能保证完全扑灭火灾，尤其是在一个电气室内，但它可以改变火灾的增长曲线。

然后，建筑帮助烟雾和热量扩散。SBG2 采用了一种开放的、类似塔楼的冷却设计，对室外空气高度通透。在初始事件发生后的十五分钟内，吸气式探测器在每一层都被触发了。BEA-RI 提醒说，探测器的时间显示了烟雾，而不一定是火苗，但结论是这种建筑结构使得烟雾迅速扩散。在大约九十分钟内，SBG2 就全面着火了。与相邻的 SBG3 的对比很有启发性：两小时的防火墙和一扇防火门，加上消防用水，使其比更小且防护更差的 SBG1 受到的损害更小。

水和电源与这种设计相互作用。根据调查，首批响应可用的公共消防供水不足以应对发展中的事件，而且 OVH 既没有自己的灭火水储备，也没有办法从附近的运河直接抽水。EUROPA 的到来是决定性的。电力独立性，通常是数据中心的优势，也使得紧急隔离变得困难：该站点结合了电网馈电、发电机和大型电池系统。消防部门在那些电源被中和之前，无法安全地施加大量的水流。

这就是基础设施韧性的悖论。备用电源在一次普通的电力故障中可以保护计算，但在火灾期间却成为另一个需要管理的能量来源。开放式气流可以降低冷却成本并提高运行效率，但却会削弱烟雾和热量的遏制。密集的设备和共享的站点设施可以改善规模经济效益，但却集中了后果。每一项优化都创造了一种风险，必须由一种不同的屏障来控制。

OVH对 BEA-RI 建议的正式回应辩称，没有自动灭火并未违反监管要求，并且调查引用的行业指南在 SBG2 设计之后才发布。这与法律和合规分析相关。但这并不是运营问责的终点。最低合规性追问的是一条规则是否强制要求了一项控制。韧性追问的则是对于一种可信的高后果情景，这项控制是否必要。OVH 在火灾后决定在未配备的站点普遍安装自动灭火系统，这本身就是风险处理方式发生改变的证据。

四栋建筑并不意味着四个独立的结果

从客户仪表盘来看，SBG1、SBG2、SBG3 和 SBG4 可能看起来像是几个独立的基础设施地点。但在事件期间，它们形成了一个单一的应急站点。SBG2 被烧毁。SBG1 和 SBG3 在不同程度上受到火灾影响。SBG4 并未被最初的火焰损坏。然而，所有四栋建筑的电源都被切断，进出受到控制，共享系统必须被评估，而幸存的基础设施则需要清洁、检查、重新布线以及分阶段重启。

OVHcloud 的斯特拉斯堡站点实时更新日志使得恢复过程的物理特性异常清晰。团队逐室、逐通道、逐机架、逐服务器地移除、清洁、检查、重新安装并重启设备。被烟尘污染的服务器被运往 Croix 的一家工厂进行专业处理。SBG1 中可恢复的机器被转移到其他数据中心。数据恢复专家试图从受损的服务器中提取磁盘。

最初的恢复并非线性的。SBG3 于 3 月 18 日恢复运营。3 月 19 日晚间，在 SBG1 一个未连接的电池室中检测到烟雾。OVH 出于谨慎再次关闭了 SBG1 和 SBG4，并修改了重启时间表。服务恢复于 3 月 22 日重新开始。到 3 月底，SBG4 的裸金属服务器已可访问，SBG3 的服务也按百分比恢复，而来自 SBG1 的设备仍在进行清洁、维修和迁移。

OVH 的注册文件后来表示，大多数客户服务在三到四周内恢复，并且到 5 月初，面向大约 65,000 名受影响客户、使用大约 120,000 项服务的服务已全面恢复。“服务恢复”不能被解读为“所有数据恢复”。在客户的旧磁盘和记录仍然被毁的情况下，一台替代服务器是可以被提供的。恢复报告必须将基础设施可用性、应用程序启动、数据恢复、数据时效性和业务验收分开。

站点范围的停机也表明，“数据中心”这个词语对于灾难规划来说可能粒度太细了。故障域是指任何危险能够共同影响的范围。对于斯特拉斯堡的火灾响应，相关域包括了邻近建筑、电源隔离程序、应急进出、消防用水容量、烟雾、共享运营以及控制重新进入的安全当局。如果同一个应急决定可以使所有建筑都不可用，那么多个建筑名称并不能创造独立的恢复能力。

计算影响需要不止一个数字

Netcraft对此次中断的外部测量发现，在观测窗口期内，大约有 464,000 个不同域下的 360 万个网站处于离线状态，并且在其近期调查中，OVH 归因的 IP 地址中有超过 18%没有响应。这是互联网规模上对可访问性丧失的观察。它捕捉到了托管子域和下游托管安排，这就是它远大于 OVH 客户数量的原因。

OVH 的 65,000 名受影响客户和 120,000 项服务描述的是商业和产品关系。这两个数字都没有说明多少最终用户无法访问一项服务，多少企业损失了一个收入渠道，或者多少数据集无法恢复。当时的路透社报道指出了中断中的政府门户、银行、商店、新闻网站和其他在线服务。这些例子显示了后果的多样性，而非一个完整的统计。

影响也随着时间而变化。一个代码存储在外部仓库中的无状态网站可以在几小时内于另一个区域重建。一个由提供商持有恢复数据的托管服务，可能在 OVH 恢复其平台时回归。一个等待检查或物理迁移的裸金属客户可能数周都不可用。一个仅有生产数据和备份都被销毁的客户则面临永久性的损失，无论一台新的空服务器到达得多快。

因此，一份负责任的故障报告应该使用多种分母：客户、服务、物理服务器、域、外部不可达地址、持续时段、成功的提供商恢复、客户发起的重建以及永久数据丢失案例。它应该指出，有多少客户没有备份，有同建筑副本、同站点副本、一个不同的 OVH 区域，或者一份独立控制的副本。公开证据并未提供这个完整的矩阵。

这种缺失很重要，因为补救措施应该遵循损失机制。如果客户没有选择一个明确提供的远程备份，那么相关的就是更好的产品教育和更安全的默认设置。如果一个名为“备份”的产品将所有副本都放在一栋建筑内，而没有清晰的故障域披露，那么产品设计和合同就是核心。如果存在远程副本但客户无法获取它们，因为身份、密钥、目录或网络路径都与斯特拉斯堡绑定，那么恢复系统的独立性就是问题。将这些情况汇总为“一些客户没有备份”，妨碍了精确的问责。

备份是一项关于未来恢复的声明

OVHcloud 的2021 年注册文件指出，数据备份服务对大多数客户来说是可选的付费服务，并且一些客户遭遇了永久性的数据丢失。它还指出，客户可以选择所提供的选项，在这些选项中，备份的数据可以存储在同一数据中心或不同的数据中心。某些由提供商管理的服务，包括邮件，只受到了轻微的中断，并且没有丢失数据，因为 OVH 对其进行了备份。

这些披露颠覆了两种简单的说法。说 OVH 为每一项服务都做了备份并且没能保留所有副本，这是不准确的。说每一个数据丢失的客户都没有购买备份，也是不充分的。服务模式各不相同。一些客户对唯一的持久性副本保留责任，一些客户选择了具有不同位置的提供商选项，还有一些客户消费了由 OVH 控制恢复的服务。

备份并不仅仅由一个成功的复制作业来定义。它是一项受控的承诺，即在特定的故障发生后，一个组织能够检索到一个足够新、完整的其信息版本，并用它在一个可接受的时间内恢复一项优先服务。这项承诺至少包含六个属性：

1. 范围：包含或有意排除的数据、系统状态、配置、身份存储、密钥、软件和外部依赖。
2. 时点：被恢复数据的最大可接受年龄，通常表示为恢复点目标，以及为应对损坏或延迟发现所需的保留历史。
3. 隔离：物理、逻辑、管理和提供商层面的故障，这些故障不能同时销毁或更改每一份副本。
4. 访问：在危机期间检索副本所需的凭证、加密密钥、目录、工具、网络路径和授权人员。
5. 时间：获取容量、传输数据、重建依赖、协调事务并使业务功能恢复到可接受状态所需的测试时长。
6. 证据：对备份完成的监控、完整性检查、抽样恢复、完整的服务演练以及显示结果的保留记录。

斯特拉斯堡事件主要是一次物理隔离和恢复时间的考验，但它暴露了所有六点。一个没有 DNS 记录、机密、部署代码或数据库一致性的磁盘映像可能无法重启一个应用程序。一个使用仅在故障区域可用的密钥加密的远程副本可能是持久却无法使用的。一个需要数天才能检索的多 TB 归档可能会错失一个 12 小时的业务目标。一份存储在同一能源和火灾域中的备份在被其假定覆盖的事件发生之前，可以是完全最新的。

法国数据保护机构 CNIL 现在在其备份安全指南中明确指出了物理教训：将至少一份副本保存在一个地理位置上不同的站点，将至少一份副本进行离线隔离，将备份保护至与生产同等的安全级别，并测试完整性和恢复能力。CNIL 的云安全指南告诉客户要核实云提供商拥有与其数据中心地理上相距甚远的备份位置。这些 2024 年的材料是后来的指南，并不能证明 2021 年每项 OVH 服务的精确合同义务。但它们为当前实践提供了一个清晰的基准。

Bati Courtage 案使产品语言产生了后果

一位客户的争议为备份边界提供了法律上的具体性。France Bati Courtage 使用了一台 OVH 虚拟私有服务器和一个付费的自动备份选项。根据记录，OVH 在 2021 年 4 月通知它，备份也已被完全且不可逆地销毁，因为副本与主服务器位于同一栋建筑中。该客户因数据丢失和所谓下游业务损害寻求数百万欧元的赔偿。

上诉结果发生了变化。在其2025 年 4 月 24 日的判决中，杜埃上诉法院认定存在合同违约，因为 OVH 无法让客户访问已完成的备份并保存它以供检索。它并未支持客户另外的主张，即 OVH 因未能将服务安置在地理上隔离的位置而存在过错。它还在该争议中保留了早先的裁决，即 OVH 不存在重大过失或严重的消防安全违规，驳回了 OVH 的不可抗力抗辩，维持了相关的责任限制，并将赔偿金额降至 1,800.48 欧元。

这一裁决比广泛报道的一审判决更狭窄且更具启发性。它并没有确定每一份 OVH 备份合同都承诺了一个远程数据中心。它也没有确立一条普遍规则，即任何同站点备份在法律上都是有缺陷的。它的确表明，当客户付费让提供商执行备份并且提供商对所产生的副本负有合同义务时，通过说“客户拥有备份策略”来解决责任问题是行不通的。

该案例也说明了为什么合同标签背后需要拓扑结构。像“物理隔离”、“基础设施”、“本地”、“区域”和“远程”这样的词可能承载着不同的含义。一个单独的磁盘阵列是针对服务器故障隔离的。一个单独的房间可能是针对机架火灾隔离的。一栋单独的建筑可以在某些房间事件中幸存，但不一定能经受住园区范围的断电或边界关闭。一个单独的区域则更强大，前提是这些区域不共享会阻碍恢复的控制、账户、密钥或网络依赖。

客户不应被迫从一个营销形容词中推断这些边界。一项服务描述应该指明副本的故障域，该位置是通过默认设置还是选项选择的，位置是否会改变，设计旨在承受的危险，恢复目标，以及客户的剩余职责。提供商应该保留这些表述的历史版本，因为在购买服务时可用的界面和文档后来可能成为核心证据。

合同限制和运营问责也是不同的。上诉判决的赔偿金额很小，因为法院在评估了其面前的索赔和条款后，适用了双方商定的限制。一个责任上限并不能使永久性的数据损失在运营上变得可以接受，一项声称的巨额损失也不能证明提供商在法律上欠下该金额。合同分配的是财务敞口。它们不能恢复信息，也不能证明一项控制措施得到了适当的设计。

共享责任必须足够具体才能运作

“共享责任”常常被用作一种礼貌的说法，意指双方都有工作要做。除非点明这项工作，否则这句话在失败后分配的是责备，而不是在失败前分配控制措施。斯特拉斯堡事件支持一种更精确的划分。

OVH 拥有一个局部电气事件演变为建筑损失的概率。它选择了物理设计、火灾探测和灭火、防火分区、电力隔离、应急程序、维护框架、水资源以及与公共消防员的关系。客户无法在 SBG2 安装喷淋头或创建紧急断电。即使在客户合同限制损害赔偿的情况下，这些也属于提供商的控制措施。

OVH 还拥有其产品的事实真相。只有提供商才知道一个自动备份落在了哪里，它为哪些服务默认进行了备份，哪些区域共享了系统，以及在斯特拉斯堡丢失期间控制平面如何表现。它必须足够准确地描述这些属性，以便客户做出风险决策。在 OVH 承担备份服务的地方，它拥有对所承诺服务的执行以及关于所产生副本的证据。

客户拥有后果模型。如果没有特定的托管安排，提供商无法知道一台小型虚拟服务器是承载着一个一次性的测试站点，还是承载着多年业务记录的唯一副本。客户必须对数据进行分类，设定恢复目标，选择一个与影响相匹配的架构，在主要故障域之外保存副本，并测试重建。购买基础设施并没有转移客户决定其业务能够容忍多长停机时间的责任。

这种边界随着服务模式而移动。在非托管的裸金属或基础设施即服务中，客户通常拥有应用一致性的备份和故障转移。在托管数据库、托管邮件产品或显式的备份服务中，提供商则拥有更多的副本、保留、一致性和恢复路径。市场上的转售商或托管服务提供商引入了另一层面：它可以选择 OVH，配置备份，向其自己的客户代表弹性，并保留唯一的管理访问权。最终客户需要了解这条链条。

法国网络安全机构 ANSSI 的当前备份基础指南将这些职责转化为实际的控制措施。它们要求设定恢复点目标和恢复时间目标，采用 3-2-1 模式，至少有一个离线或受到适当保护的异地副本，定期进行恢复测试，制定恢复的顺序，并保护安装介质和应用程序配置。对于外包备份，ANSSI 强调了欧盟位置、提供商复制行为、客户控制的加密以及检索时间。这是一个有用的提醒，即物理韧性、网络隔离、主权和可恢复性需要被一同设计。

本地化回答几个不同的问题

OVHcloud 的欧洲身份在 2021 年至关重要，并且现在仍然重要。对于寻求非欧洲超大规模云服务商替代方案的政府和受监管组织来说，一家运营着欧洲数据中心的法国提供商能够提供有意义的管辖权、经济和运营优势。斯特拉斯堡大火并没有让数据主权变得无关紧要。它表明主权并不是可用性工程的替代品。

“数据在哪里？”至少可以意味着五件事：

• 法律位置：哪个国家的数据保护、披露、破产和行业规则管辖着存储、处理和访问。
• 公司控制：哪些母公司、管理者、次级处理者以及外国法律要求能够影响服务。
• 物理位置：哪栋建筑、泛洪区、电网、供水、园区和区域危险包含了每份副本。
• 逻辑位置：必须运行哪个区域、可用区、账户、租户、密钥系统和控制平面才能检索或故障转移数据。
• 运营距离：多少延迟、带宽、人员配置和恢复时间将生产与其用户以及恢复副本分开。

一项规定“所有数据必须留在法国”的政策回答了第一个问题的一部分，并约束了第三个问题。它并不要求生产和备份占用同一栋建筑。法国境内包含多个大都市区域和云区域。一项要求欧盟存储的政策允许更大的地理多样性，同时保持一个欧盟法律边界。这是否足够取决于该组织的法律、威胁模型、数据敏感性和恢复目标。

欧盟委员会关于国际数据传输的解释也阻止了一种相反的简化：GDPR 并未强加一条绝对规则，即个人数据永远不能离开欧洲经济区。它为传输提供了充分性决定、保障措施和有限的克减。然而，一些组织因为行业法律、公共政策、合同承诺或对外国管辖权的暴露而采用了更严格的本地化要求。

ANSSI 的SecNumCloud 资格认证指南说明了更丰富的主权模型。它不仅针对客户数据，而且针对管理、监督、备份、目录和技术数据，解决欧盟位置问题，同时考虑公司控制和对非欧盟法律的暴露。该框架涉及的是对服务和数据的控制，而不仅仅是一个磁盘的经纬度。

实际结论是建设性的：主权和灾难隔离可以相互加强。一个法国公共机构可以将其敏感的生产环境保留在一个经过认证的欧洲环境中，维护一个地理上不同的欧盟恢复副本，使用客户控制的加密和密钥，并保留经过测试的出口程序到另一个经过批准的环境。该架构可能成本更高，并且需要仔细的法律审查。这种权衡应该是明确的，而不是隐藏在“本地”这个词里面。

集中化既是一种应用属性，也是一种市场属性

此次中断影响了政府门户、商业、媒体、游戏和面向公众的服务，因为许多组织选择了一个提供商，或者是通过供应商继承了它。这是市场层面的云集中化。在各个应用程序内部也存在集中化：生产环境、备份、DNS、邮件、管理和部署工具都可能共享 OVH 乃至斯特拉斯堡，即使它们表现为不同的产品。

这两种形式需要不同的处理方式。监管机构可以监控对一小群云提供商的系统性依赖。采购团队可以避免跨部门未经审查的提供商集中化。应用程序所有者必须梳理出决定其自身服务能否恢复的依赖关系。一家公司可能在其产品组合中使用三家云提供商，而其中一个关键系统仍然没有独立的副本。另一家可能继续使用一个提供商，但使用真正独立的区域、可导出的备份、独立的 DNS 和离线恢复材料。

金融监管越来越多地表达了这种保留的客户责任。欧洲银行管理局的2019 年外包指南要求受监管的机构治理外包风险，并保持监督能力，而不是变成空壳。后来的欧盟数字运营韧性法案（DORA）要求受监管的金融实体维护并定期测试备份、恢复和还原安排。其第 12 条要求包括，当实体使用自己的系统恢复备份数据时，要实行物理和逻辑上的隔离。这些规则有确定的适用范围，不应被追溯性地投射到 2021 年的每一位 OVH 客户身上。它们显示了负责任实践的方向：外包并没有将治理机构对连续性的责任转移出去。

DORA 的详细实施框架走得更远。关于 ICT 风险管理的2024 年授权条例包括了涉及场所和数据中心部分或全部损失、第三方服务故障、切换到冗余容量以及大范围停电的情景。斯特拉斯堡正是那种一项严肃的演练应该模拟的结合了物理和供应商的事件。

多云设计可以减少一些依赖，但并非自动就更好。它增加了身份、网络、数据一致性、技能、可观测性以及事件协调的复杂性。正确的目标是为重要功能实现可移植、可测试的恢复，而不是一个架构口号。有时这意味着跨独立区域的主动服务。有时意味着在另一个区域准备热备容量。有时一个受保护的备份加上基础设施即代码和一次经过演练的重建，就能以低得多的成本满足业务需求。

恢复必须从客户侧得到证明

提供商的恢复和客户的恢复不是同一个时钟。OVH 可以在电力、网络和大部分服务器可用时宣布一个数据中心已投入运营。而客户仍然需要验证文件系统、数据库、队列、证书、DNS、集成和业务事务。如果原始服务器被毁，客户必须提供一个替代品，检索数据，重建应用程序，并协调所有在最后一个可用副本之后发生的事务。

一次成熟的恢复演练始于一个假定的损失，而不是一个方便的导出。团队应该假装主区域不可访问，普通管理员无法通过其身份路径登录，并且提供商的支持已饱和。它应该使用存储在故障环境外部的凭证和密钥获取备份，在已批准的目的地构建干净容量，按照文档记载的顺序恢复依赖关系，验证数据完整性，重定向用户，并衡量业务成果。

证据应当回答实际的问题。被恢复数据库的时间戳是什么？哪些写入丢失了？是否包含了所有的对象存储版本？能否在不削弱访问控制的情况下恢复密钥？DNS 是否在预期的时间内完成更改？外部支付、邮件和身份提供商是否接受了新的地址？距离第一笔安全交易有多长时间？达到满容量又用了多久？谁批准了返回，还剩下哪些对账工作？

单单是备份监控无法回答这些问题。一个绿色的作业证明软件向某个目标写入了东西。一次完整性测试证明选定的数据可以被读取。一次技术恢复证明系统可以被重建。一次服务演练证明组织可以在假定的故障下交付其优先功能。每一次都是有用的；都不应被表述为下一次。

这对于小型组织尤其重要。它们可能不需要活跃-活跃的基础设施或专用的第二朵云。但它们确实需要一条相称的出路。一家小型企业可以将其数据库和关键文档导出到一个独立账户下的加密目的地，独立地保留其域和部署凭证，记录一个清晰的重建过程，并测试一次样本恢复。控制措施应该匹配丢失记录的成本，而不是服务器的月度价格。

OVHcloud 的补救措施触及了物理链条

OVH 对 BEA-RI 的回应描述了一个重大的“超强韧性”计划。该公司表示将加强探测，在缺失的地方普及自动灭火，重新设计区域和防火分区，将普通的耐火时间从 60 分钟增加到 120 分钟，并在新站点以及现有站点可行的地方，将能源和电池室置于数据中心建筑之外。它计划实施按区域进行的远程电源切断，以便响应者能够隔离危险，而不必不必要地禁用未受影响的区域。

回应还指出，地方消防部门在事故发生后四个月内视察了每一个 OVH 站点，修订了应急文件和断电程序，并成立了一个新的工业风险部门。在斯特拉斯堡，OVH 与 SIS67 合作安装了一个 120 立方米的专用水箱。它表示所有站点都接受了火灾风险分析，并且在工程完工后，将通过脆弱性研究来衡量有效性。于 2022 年 7 月启用的 SBG5 被作为新标准的范例提出。

这些行动很好地对应了调查中的因果和传播链条。灭火解决了早期增长。更强的防火分隔解决了垂直和建筑间的蔓延。外置的能源室将点火危险与服务器室分开。分区切断解决了电气隔离的延迟和波及范围。储水解决了首批响应的容量问题。消防部门的视察和演练解决了不熟悉、计划和指挥决策问题。

OVHcloud 的2025 年通用注册文件指出，该集团在 2025 年继续进行了站点风险测绘，并将“超强韧性”描述为加强数据中心安全，使其超过监管和保险公司的建议。它还记录了一项为斯特拉斯堡火灾后果持续计提的准备金，包括责任诉讼。这是一个持续项目和财务处理的证据，而不是一份站点独立的完工证书。

负责任的闭环将发布或向合格的客户和审计师提供一份控制矩阵：哪些站点在每个相关的能源和 IT 室中都配备了自动灭火；哪些拥有 120 分钟的防火分区；哪些电池室是外置的；哪些区域有遥控隔离；哪些水流要求经过了测试；进行了哪些消防演练；哪些发现仍未解决；以及哪个独立方验证了运行。一份政策承诺是补救的开始。覆盖范围和对抗性演练则显示它是否有效。

该公司也值得赞赏，因为它在艰难的恢复过程中保留了详细的公开更新日志，动员了专业的清洁和恢复能力，更换了基础设施，传达了针对特定产品的进展，并发布了针对安全建议的正式回应。透明度并不仅仅因为更新频繁就变得完备，但这些记录使客户和调查人员能够重建本会消失的决策。

产品设计已经向前发展，但配置仍然决定韧性

OVHcloud 当前的文档比在 Bati Courtage 争议中可见的火灾前的语言更明确地指出了故障域。其部署模式指南区分了单可用区区域、三可用区区域和本地可用区。它指出，一个 1-AZ 区域对于影响整个数据中心的故障仍然是脆弱的，而 3-AZ 架构则使用独立的区域，用于要求更高的生产和灾难恢复场景。

该公司的区域和可用区概览同样指出，寻求更高韧性的客户应该选择一个支持的多可用区区域，并针对多个可用区进行构建。动词很重要：提供商提供区域；客户必须将资源和应用程序状态分布在这些区域之上。仅仅在一个 3-AZ 区域中启动，并不能确保一台虚拟机、一个数据库或一个手动放置的卷能够跨区域。

当前的实例备份文档现在区分了本地备份和远距离备份。本地备份保留在同一区域。远距离备份在另一个选定区域创建一份副本，并单独计费。这是一种清晰得多的故障域语言。它也保留了一个明确的客户选择，这意味着采购和配置仍然是控制的一部分。

现在的文档不应被用来重构 2021 年 3 月每位客户被提供了什么。它与当前的问责问题相关：市场是否学会了将本地化和韧性分开来揭示？OVHcloud 现在在这些产品指南中做到了这一点。下一步的保证措施是，要使这种区分在跨产品页面、合同、控制面板默认设置、API、发票和支持响应中保持一致，包括那些提供商管理的备份遵循不同规则的产品。

更安全的设计也可以使用渐进式的默认设置。一项低成本的开发服务可以合理地默认使用本地备份，如果其界面将其标记为针对实例故障的保护，而非区域灾难。一个生产数据库或品牌备份产品可以要求客户确认故障域，在所有副本共享一个站点时显示警告，并在同一法律区域内提供一个远程目的地。目标是知情风险接受，而不是强迫每个工作负载进入最昂贵的架构。

董事会需要跨两个控制平面的证据

斯特拉斯堡大火跨越了一个设施控制平面和一个客户恢复控制平面。OVH 的董事会和风险领导层需要对两者都有保证。消防工程不能被当作房地产的一个脚注，备份产品也不能仅仅被看作存储收入。

在设施层面，领导层应该知道每个站点的最大可能损失，而不仅仅是设备冗余。报告应该显示灭火覆盖范围、防火分区完整性、能源室分离、探测性能、应急供水、电源隔离时间、消防部门熟悉程度、维护的例外情况以及逾期的整改工作。演练应该假定常规控制失效，并且消防员需要即时、准确的授权来隔离能源。

在服务层面，领导层应该知道产品故障域是如何被表述和测试的。报告应该显示有多少以备份或高可用性语言推销的服务将每一份副本都存储在一个站点或区域；有多少客户选择了远距离保护；按产品和规模划分的恢复成功率；密钥和身份依赖性；恢复时间分布；文档偏差；以及表明客户误解了位置的投诉。

董事会还应该收到例外情况，而不仅仅是平均值。一种 99.99%的备份作业成功率可能与数千份处于同一物理域中的副本共存。一个全局性的灭火百分比可能隐藏着一栋老旧的高密度建筑。一个平均恢复时间可能隐藏着最大和最重要的数据集。尾部风险敞口属于治理，因为斯特拉斯堡就是一个具有集中影响的尾部事件。

独立挑战应该从头到尾追踪一项客户承诺。选择一项被宣传为已备份的服务。记录界面和合同上的说法。定位每一份副本及其控制元数据。从演练中移除主站点。拒绝正常的身份和支持路径。在满足客户本地化规则的目的地中进行恢复。将测量得到的结果与所承诺的恢复目标进行比较。任何中断都是一个可操作的差距，无论它是由产品、基础设施、支持还是客户所拥有。

客户在将一项服务称为具备韧性之前应该要求什么

组织不需要私人访问每个数据中心的蓝图。他们确实需要足够详细的答案，以便决定一项服务是否符合故障的后果。以下问题将斯特拉斯堡的教训转化为采购证据：

答案应该与确切的产品绑定。一份提供商的企业韧性报告可能不会描述正在被购买的预算 VPS、本地快照或托管数据库。认证可以确立有用的控制，但可能存在范围排除。一份可用性服务水平协议在一个阈值被错过时提供一种补救措施；它本身并不能描述数据耐久性或保证恢复。

客户还应该核实转售商名称之下的集中度。一个托管备份供应商可能将其存储库存放在与生产相同的 OVH 区域中。一个二级托管品牌底层可能使用 OVH。DNS、邮件、源代码、机密和事件沟通可能全部分享同一家提供商。多样性是通过幸存的路径来衡量的，而不是通过发票的数量。

最后，客户必须决定多少损失是可以接受的。跨区域灾难的零数据丢失和近乎零停机需要持续复制、应用设计、容量和运营测试，这可能代价高昂。对于静态归档，每周一次的离线副本可能足够了，而对于事务处理来说则是灾难性的。问责制并不要求处处都有相同的控制。它要求在后果、承诺的恢复、架构和证据之间建立一种自觉的关系。

持久的信号

斯特拉斯堡火灾不仅仅是“一次不幸的起火，然后提醒人们要做备份”。它是一次演示，展示了抽象概念在物理压力下如何失效。独立的建筑构成了一个统一应急站点。完好的服务器和受损的服务器一起变得不可用。一份已完成的备份可能与生产一起消失。一个服务于主权和延迟的欧洲位置可能成为火灾风险的集中地。一台替代服务器可以恢复基础设施，却无法恢复客户的业务。

公开记录也包含着有意义的改进。探测和夜间值守保护了生命。消防员和 EUROPA 消防船限制了火势蔓延。OVH 实施了一次艰难而透明的恢复，以运营条款接受了 BEA-RI 的建议，并发起了一项广泛的物理韧性计划。其当前的产品文档更清晰地区分了本地备份和远距离备份，以及单可用区部署和多可用区部署。这些不是表面的变化。

剩下的问责标准是随时间推移的证据。OVH 应该能够表明，火灾后确定的物理控制措施已在相关站点安装、维护和演练；产品语言映射到真实的故障域；并且当某个区域及其常规控制路径缺失时，托管的恢复能够发挥作用。客户应该能够表明，关键数据在主危险之外拥有一个可用的副本，处于经批准的法律边界之内，并且他们的人员能够在业务目标内恢复它。

没有一家云提供商可以保证一栋建筑永不发生火灾。没有客户可以消除每一项依赖。可信的承诺更为狭窄：一次可预见的物理事件不会悄无声息地同时吞噬生产、恢复以及理解损失的手段；本地化的选择将在管辖权和危险两方面都是明确的；而“备份”这个词将得到唯一最终重要的证据的支持，即在该副本被购买时所针对的条件下，一次成功的恢复。