OVHcloud 火灾揭示数据本地化不等于灾难隔离

概述

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

一场物理火灾演变为云端问责事件

“云端数据”这一说法助长了抽象化。当工程师希望为计算能力提供标准接口时，它是有用的；但当决策者开始将位置、电力和火灾视为他人的细节时，它就变得危险了。每台虚拟服务器都安放在一个房间里。每个存储副本都占据着连接到电气和冷却系统的设备。每条恢复工作流都依赖于人员、网络、凭证、目录以及可以从中获取替换容量的地点。

斯特拉斯堡让这条物理链清晰可见。2021 年 3 月 10 日凌晨，火灾摧毁了 OVHcloud 位于莱茵港园区的一栋建筑 SBG2，SBG1 部分被毁。尽管公司最初的更新称园区内另外两个数据中心未受损，它们也被关闭了。因此，损失至少通过三种不同机制蔓延：设备被物理摧毁；邻近建筑中的设备暴露于热、烟、水或不确定性之中；当整个园区必须进行电气隔离并确保安全时，原本完好的设备也变得不可用。

这些机制之所以重要，是因为它们对应着不同的控制措施。自动灭火和隔断可以遏制火灾。独立的电力区域可缩小消防员需要断电的范围。多站点应用可以在一个站点不可用时继续运行。一个经过验证的远程备份可在数据被毁后支撑重建。状态页面可以引导客户通过这些选项。将这一切统称为“冗余”掩盖了由谁控制每一层以及它能承受何种事件。

最权威的公开重建是法国工业风险调查与分析局（BEA-RI）2022 年 5 月的调查报告。其任务是预防，而非划分民事或刑事责任。这一界限很重要。报告可以确立观察结果、可能的原因、促成因素和安全建议。但它不能转化为法院的裁定，即每一项被识别的弱点都是疏忽，或一项弱点在法律上导致了特定客户的损失。

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

证据确立了什么，又未能确立什么

BEA-RI 报告将首次警报时间定为 00 时 35 分。一名保安于 00 时 37 分到达 SBG2 的一个能源室，发现浓黑烟雾。建筑于 00 时 39 分疏散，下莱茵消防与救援服务于 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对该中断的外部测量发现，在测量窗口内，约有 360 万个网站跨 464,000 个独立域名下线，并且在其近期调查中，归因于 OVH 的 IP 地址中有超过 18%无响应。这是一个从互联网尺度观测到的可达性丧失。它捕获了托管子域名和下游托管安排，因而远超 OVH 的客户数。

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

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

因此，一份负责任的故障报告应当使用多个分母：客户、服务、物理服务器、域名、外部不可达地址、时长分段、成功的提供商还原次数、客户主动重建次数以及永久数据丢失案例。它还应识别出多少客户无备份、持有同一建筑内的副本、同一站点的副本、不同的 OVH 区域副本，或处于独立控制下的副本。公开证据并未提供这一完整矩阵。

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

备份是对未来恢复的一份声明

OVHcloud2021 年注册文件称，数据备份服务是面向大多数客户的可选付费服务，并且一些客户遭遇了永久数据丢失。该文件还称，客户可选择将备份数据存储在同一数据中心或不同数据中心的选项。某些由提供商管理的服务，包括邮件服务，仅受到轻微中断且未丢失数据，因为 OVH 对它们进行了备份。

这些披露推翻了两个简单的叙事。称“OVH 为每项服务都做了备份且未能保留所有副本”是不准确的。同样，称“每位丢失数据的客户都未能购买备份”也是不充分的。服务模式各不相同。有些客户自行负责唯一的持久副本，有些则选择了提供商提供的不同位置选项，还有些消费的是 OVH 控制恢复的服务。

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

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

斯特拉斯堡主要是一场物理隔离和恢复时间的测试，但它暴露了全部六点。没有 DNS 记录、密钥、部署代码或数据库一致性的磁盘镜像可能无法重启应用。一份用只有在故障区域才能获得的密钥加密的远程副本，可能持久却却无法使用。一个庞大到需花费数日来取回的多 TB 存档，可能错过十二小时的业务目标。一个存储在同一能源和火灾域中的备份，可以直到它本应覆盖的事件发生前都保持完全最新。

法国数据保护机构 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 的详细实施框架更进一步。2024 年关于 ICT 风险管理的授权条例包含涉及场所和数据中心的局部或完全损失、第三方服务故障、切换到冗余容量以及大范围停电的场景。斯特拉斯堡恰好是一种应被严肃演练的组合式物理和供应商事件。

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

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

提供商的还原与客户的恢复并非同一时钟。当电力、网络和大部分服务器可用时，OVH 可以宣布一个数据中心恢复运营。客户仍需验证文件系统、数据库、队列、证书、DNS、集成和业务事务。如果原始服务器被毁，客户必须配置替代资源、取回数据、重建应用，并调节最后一次可用副本之后所发生的一切。

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

证据应回答实践中的问题。恢复的数据库时间戳是什么？哪些写入丢失了？是否包含了所有对象存储版本？密钥能否在不妨碍访问控制的情况下恢复？DNS 变更是否在预期时间内完成？外部支付、邮件和身份提供商是否接受了新的地址？距第一笔安全交易相隔多久，距完全恢复容量又相隔多久？谁批准了回退，还剩下哪些待调节事项？

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

这对小型组织尤其重要。它们可能不需要“双活”基础架构或专门的第二朵云。但它们需要一条相称的退出路径。一家小企业可以将其数据库和关键文档导出到一个独立账户下的加密目标，独立保留其域名和部署凭证，记录一次干净的重建，并测试一次样本还原。控制措施应与丢失记录的成本相匹配，而非服务器的月度价格。

OVHcloud 的补救措施针对了物理链

OVH 对 BEA-RI 的回应描述了一项规模可观的“Hyper Resilience”计划。公司表示将加强探测，在未配备自动灭火处全面加装，重新设计可用区和隔断，将普通耐火时间从 60 分钟提高到 120 分钟，并将能源和电池室移至数据中心建筑之外（针对新站点，且在现有站点可行处亦如此）。它计划按区域实现远程电力切断，使响应者能隔离危险，而不必不必要地停用未受影响区域。

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

这些行动很好地对应了调查中的因果和蔓延链条。灭火系统对应早期增长。更强的防火隔断对应垂直和建筑间蔓延。外部能源室将着火风险与服务器间分离。分区断电对应电气隔离的延迟和波及半径。储水对应首批响应的能力。消防部门参观和演练对应不熟悉、方案和指挥决策。

OVHcloud 的2025 年通用注册文件称，集团在 2025 年期间继续进行站点风险测绘，并将“Hyper Resilience”描述为将数据中心安全性强化至超出监管和保险人建议的水平。它还记录了为斯特拉斯堡火灾后果计提的持续准备金，包括责任诉讼。这是持续计划和财务处理的证据，但并非一份逐个站点的独立完工证书。

可信的收尾应发布或向经过认证的客户和审计师提供一份控制矩阵：哪些站点在每个相关的能源和 IT 间都装有自动灭火系统；哪些拥有 120 分钟隔断；哪些电池室位于外部；哪些区域装有远程操作的隔离；哪些水流要求经过了测试；进行了哪些消防演练；还有哪些发现项未关闭；以及由哪一方独立方验证了运行。政策承诺是补救的开始。覆盖范围和对抗性演练才能证明它是否有效。

公司也值得肯定，它在一次艰难的恢复过程中维护了一份详细的公开更新日志，动员了专业清洁和恢复能力，更换了基础设施，传达了针对产品的进展，并发布了针对安全建议的正式回应。透明度并不仅因更新频繁而完整，但这些记录允许客户和调查人员重建那些本会消失的决策。

产品设计已经改进，但配置仍决定韧性

OVHcloud 当前的文档在故障域方面比 Bati Courtage 案中可见的火灾前表述更为明确。其部署模式指南区分了单一可用区区域、三可用区区域和本地区域。它指出，单 AZ 区域仍易受影响整个数据中心故障的影响，而 3-AZ 架构则针对更严格的生产和灾难恢复案例使用了独立的可用区。

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

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

不应使用当前的文档来重构 2021 年 3 月时每位客户获得了何种服务。它与当前的问责问题相关：市场是否学会了将本地化和韧性分开揭露？OVHcloud 如今在这些产品指南中做到了。下一步的 assurance 是在产品页面、合同、控制台默认设置、API、发票和支持响应中保持一致，包括那些由提供商管理的备份遵循不同规则的产品。

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

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

斯特拉斯堡火灾穿越了设施控制平面和客户恢复控制平面。OVH 的董事会和风险领导层需要对两者都获得 assurance。消防工程不能被视作不动产的脚注，而备份产品也不能仅被视为存储营收。

在设施层，领导层应了解每个站点的最大可能损失，而不仅仅是设备冗余。报告应展示灭火覆盖、隔断完整性、能源室分离、探测性能、应急用水、电力隔离时间、消防员熟悉度、维护例外情况和逾期的纠正工作。演练应假设常规控制失效，消防员需要即时、准确的授权来隔离能源。

在服务层，领导层应了解产品故障域是如何被表述和测试的。报告应显示有多少项以备份或高可用性措辞销售的服务，其所有副本均存储在一个站点或区域；有多少客户选择了远程保护；按产品和规模划分的还原成功率；密钥和身份依赖关系；恢复时间分布；文档漂移；以及表明客户误解位置的投诉。

董事会还应收到例外情况，而不仅仅是平均数。99.99%的备份作业成功率可能与成百上千份副本同处于一个物理域并存。一个全球性的灭火覆盖百分比可能掩盖一栋老旧的高密度建筑。一个平均还原时间可能掩盖最大且最关键的后果集。尾部风险应进入治理，因为斯特拉斯堡正是一次后果集中的尾部事件。

独立的挑战应全程追溯一份客户承诺。选取一项作为备份出售的服务。记录界面和合同所言的。定位每份副本及其控制元数据。将主站点从演练中移除。拒绝正常的身份和支持路径。在一个满足客户本地化规则的目的地进行还原。将测量到的结果与承诺的恢复目标进行比对。任何断裂都是一个可诉诸行动的差距，无论其所有者是产品、基础设施、支持还是客户。

客户在称一项服务有韧性之前应要求什么

组织不需查阅每一张数据中心蓝图。但他们需要足够详细的答案来决定一项服务是否符合失效的后果。以下问题将斯特拉斯堡的教训转化为采购证据：

答案应与确切产品绑定。一份提供商的企业韧性报告可能无法描述所购买的低价 VPS、本地快照或托管数据库。认证可以确立有用的控制，但可能存在范围排除。一份可用性服务水平协议在阈值被突破后提供救济；它本身并不描述数据持久性或保证恢复。

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

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

持久的启示

斯特拉斯堡火灾不仅仅是一次不幸的起火，外加一个关于要做备份的提醒。它是一次展示，表明抽象概念如何在物理压力下失效。独立的建筑形成了一个单一的应急现场。完好的服务器与受损的服务器一同变得不可用。一份已完成的备份可能与生产数据一同消失。一个有助于主权和延迟的欧洲位置，却可能变成火灾风险的集中点。一台替换服务器可以恢复基础设施，却不能恢复客户的业务。

公开记录中也包含了有意义的改进。探测和夜间值班人员保护了生命。消防员和 EUROPA 消防船限制了蔓延。OVH 执行了艰难而透明的恢复，以运营性措辞接受了 BEA-RI 的建议，并启动了一项广泛的物理韧性计划。它目前的产品文档更清晰地区分了本地与远程备份，以及单可用区与多可用区部署。这些并非表面化的改变。

剩余的问责标准是随时间推移的证据。OVH 应能展示，火灾后确定的物理控制已在相关站点安装、维护和演练；产品语言映射至真实的故障域；并且当某个区域及其正常控制路径缺席时，托管恢复可以奏效。客户应能展示，关键数据在主风险源之外拥有一份可用的副本，处于经批准的法律边界内，并且他们的人员能够在业务目标内将其还原。

没有云提供商能承诺建筑永不起火。没有客户能消除每一种依赖。可信的承诺更为克制：一次可预见的物理事件不会静默地吞噬生产、恢复以及理解已丢失之物的手段；本地化选择将明确同时涉及管辖权和风险源；“备份”一词将得到最终唯一重要的证据的支持——在购买该副本所针对的条件下，一次成功的还原。