Google Cloud 比利时磁盘丢失表明局部性无法替代弹性

摘要

• 2015 年 8 月，在四次连续的雷击影响了一座欧洲数据中心的本地电网后，europe-west1-b 区域的 Google Compute Engine 标准 Persistent Disk 出现了读取错误。Google 后来报告称，该区域中极少数已分配的 Persistent Disk 空间发生了无法恢复的近期写入丢失。
• 问责问题不在于百分比是否大。而在于客户是否理解到，即使有提供商管理的区域内冗余，单区域 Persistent Disk 仍处于一个物理故障域内，并非独立快照、区域复制或应用级备份的替代品。
• Google 控制了物理场所的弹性、存储硬件的脆弱性、电力事件处理、Persistent Disk 持久性表述、状态报告以及备份指南的明确性。客户则控制了工作负载架构、快照计划、恢复目标、复制选择，以及局部性要求是否与可恢复性混淆。
• 实际的修复记录应区分恢复的服务、无法恢复的数据、可用的快照变通办法、硬件和软件变更、备份指南以及客户证据。在涉及数据丢失的云事件中，绿色状态页面不能作为整个恢复的证明。

微小的百分比仍可能意味着严重的故障

Google Cloud 比利时事件有时被视为一个奇闻，因为永久丢失的存储百分比极小。这是错误的第一视角。对于磁盘中包含无法恢复的近期写入的客户而言，百分比无关紧要。相关的问题是客户是否有可恢复的独立副本，应用程序能否容忍该恢复点，以及提供商对持久性的表述是否在事件前足够清晰地揭示了剩余的物理场地风险。

Google 的公开Compute Engine 事件 #15056始于 2015 年 8 月 13 日，针对 europe-west1-b 区域中的 Persistent Disk。状态页面最初报告了在区域内有机器运行的客户遇到读取错误，随后说明该区域内不到 1% 的磁盘易出现性能下降，然后是有不到 0.1% 的磁盘在部分块上遇到读取失败。事件记录还告知受影响的客户，从快照恢复是一种变通方法，而创建新的 Persistent Disk 并从快照恢复则不受影响。

记录事件后续解释的媒体报道，包括 数据中心 Dynamics 的关于雷击和数据丢失的报告以及 Silicon UK 的对中断原因的报道，记载了 Google 的声明：四次连续的雷击击中本地电网，导致向 europe-west1-b 区域中 GCE 实例提供磁盘容量的存储系统短暂断电。Google 表示几乎所有数据都已提交到稳定存储，但在极少数情况下，近期写入无法恢复，导致 Persistent Disk 上的永久性数据丢失。广泛引用的数字是受影响区域中已分配 Persistent Disk 空间的不到 0.000001%。

该记录既支持克制，也支持严肃性。将该事件描述为 Google Cloud 上大规模数据破坏是错误的。受影响的服务是一个区域中的标准 Persistent Disk；事后分析索引和当时的报道称，SSD Persistent Disk、快照和本地 SSD 不在永久数据丢失的范围之内。因为分母很大而忽视该事件也是错误的。对于重要的记录而言，数据持久性是一个二元事实。对某些人来说，微小的不可恢复百分比仍然是永久性损失。

因此，问责问题不是“为什么会有雷击？”雷击是外部危险。问题是：谁控制了让反复的电网电力事件影响到最近写入磁盘状态的设计选择；谁控制了持久性和备份指南的清晰度；以及谁控制了客户架构，该架构要么有独立的恢复点，要么没有。触发器是物理的。根本的问责问题是提供商管理的本地持久性与客户管理的可恢复性之间的界限。

局部性和持久性不是相同的承诺

云局部性解决实际问题。客户可能出于对比利时或欧洲用户的延迟考虑、采购原因、更低的碳排放特性或数据驻留承诺而选择 europe-west1 区域。Google 当前的云位置页面和 Compute Engine 的区域和地区文档说明，资源存在于区域和地区中，且地区与区域是底层物理资源的逻辑抽象。这种抽象很有用，因为客户无需管理建筑。但如果客户推断单区域资源已脱离物理故障域，这种抽象就会带来危险。

数据主权和局部性关乎数据的存储或处理位置。可恢复性关乎故障后是否存在另一个可用副本。磁盘可以满足位置要求，但如果其唯一可恢复的状态位于同一区域、同一存储类别，那么对于数据库而言，它可能就是错误的持久性架构。快照可以满足恢复需求，但其本身可能有各自的位置选择。区域磁盘可以提高跨区域的可用性，但可能无法满足每个恢复点目标。第二家提供商可以减少共同依赖，但可能会增加运营复杂性和数据治理风险。这些都是不同的维度。

Google 当前的数据驻留条款和欧洲承诺书说明了所支持服务的客户数据可驻留的位置。它们并未将每个本地资源转变为独立备份。同样，Persistent Disk 产品页面描述了持久性块存储，Compute Engine 的Persistent Disk 文档说明，Persistent Disk 具有内置冗余，可防止设备故障，并在维护事件期间保持数据可用性。这些都是有意义的提供商承诺。但它们并非保证每个可能的场地规模危险在任何配置下都不会留下零近期写入的不可恢复情况。

2015 年的事件暴露了这种解释上的差距。客户可能会将“persistent”理解为磁盘在虚拟机终止后仍能持久存在，这是正确的。另一些客户可能将其理解为磁盘不受数据丢失的影响，这不是安全的推断。客户可能会将“欧洲”或“比利时”作为主要的合规决策而止步于此。该事件表明，位置不是恢复计划。同样的本地部署虽然有助于延迟和策略，但如果不存在独立备份，也可能会集中物理风险。

因此，提供商的表述应明确故障域。单区域 Persistent Disk 在其设计范围内是持久的，但仍依赖于同一个地区。快照、区域磁盘、复制和应用备份会改变故障模型。客户需要在事件发生前，而不是在状态页面告知他们从快照恢复之后，才了解这种区别。最有价值的披露是从存储选择到故障域、恢复点、恢复时间和客户责任的清晰映射。

物理触发器应纳入云问责记录

云可以使物理基础设施从客户的日常工作中消失，但它不会使物理危险消失。供电系统、电池、存储控制器、固件、机架、配电和电网事件仍是服务的一部分。客户付费给提供商来管理这些层面，因为提供商具有更大的规模和专业知识。这使得物理弹性成为提供商的责任，同时将应用恢复架构部分留给客户。

多家媒体报道的事件解释称，自动辅助系统迅速恢复了供电，存储系统设计有电池备份，但有些近期写入的数据位于那些更易受反复或长时间电池耗尽导致电力故障影响的系统上。这句话很重要，因为它区分了单次雷击与重复性物理应力的区别，后者发现了一个易受影响的存储子集。它也说明了为什么一些报道中使用的“旧磁盘”框架应谨慎对待：公开文章描述了硬件易感性，但公开状态记录并未公布每个组件、使用年限或内部工程决策。

据称，Google 表示其对配电、计算硬件以及控制 Persistent Disk 层的软件进行了广泛审查，并正在升级存储硬件，使其对此类电力故障不那么敏感。数据中心 Knowledge 的更新报道记载，Google 正在用更具电力弹性的硬件更换存储系统，并且许多 Persistent Disk 存储已位于较新的硬件上。这些是响应性措施。它们应被理解为提供商对物理和存储堆栈的控制，而不是客户架构的行动。

提供商还控制了事件状态。Cloud 状态页面提供了多次更新、影响百分比和快照变通办法的指导。这一记录明显优于沉默。然而，随着调查的进展，它从读取错误和性能下降，逐渐转向了永久性丢失。客户需要知道哪些磁盘有读取错误，快照是否可用，能否创建新磁盘，哪些写入无法恢复，以及存储对于新工作负载是否安全。在数据丢失事件中，影响分类不仅仅关乎服务可用性；更关乎可恢复的状态。

当 Google 将事件标记为已解决时，状态页面就结束了。对于从快照恢复的客户来说，恢复工作还要继续，包括应用验证、数据核对以及可能丢失最近的事务。这种区别至关重要。提供商服务恢复意味着存储服务正在运行。客户恢复意味着工作负载具有一致的数据集，并且企业能够解释丢失的时间间隔。这两者可能是完全不同的时间点。

快照指南是共同责任具体化的地方

事件期间 Google 的状态更新告知受影响的客户可以从快照恢复。该建议仅对拥有可用快照的客户有用。不存在的、过于陈旧的、位于错误位置的、缺乏应用一致性的或从未经过测试的快照，都无法作为恢复路径。因此，该事件将一个常见的云短语“共同责任”转化为一个具体问题：在物理事件发生前，谁实际创建并验证了恢复点？

Google 当前的磁盘和实例的数据保护选项指南围绕恢复时间目标、恢复点目标、用例和成本来构建恢复策略。快照创建文档解释了标准和归档快照。快照概述描述了增量快照。计划快照指南建议将计划快照作为一种备份实践，而快照最佳实践页面添加了实际约束和可靠性建议。当前的文档比许多早期云时代的假设要清晰得多。

应用一致性仍然是客户需要关注的问题。磁盘快照捕获的是块状态；数据库可能需要静默、刷新或协调备份操作，才能使恢复的状态可用。Google 的Linux 应用一致性快照文档解释了带有客户机刷新的快照计划。重要的不是 2015 年与现在的确切功能集。而是持久的控制原则：可恢复性需要与应用程序相匹配的备份流程，而不仅仅是提供商的存储承诺。

小型团队尤其容易暴露在这种差距之下。一家初创公司或市政项目可能会选择单个云区域来降低延迟和成本。它可能在 Persistent Disk 上运行数据库，并依赖产品名称和提供商声誉作为备份设计的替代。它可能没有专门的存储工程师、经过测试的恢复流程或业务影响分析。2015 年的事件说明了为什么文档和产品默认值很重要：内部专业知识较少的客户需要那些使故障域边界显而易见的存储选项和警告。

提供商和客户的职责应用运营语言表述。Google 应该设计存储系统以抵御预期的物理危险，发布清晰的故障域信息，提供快照和复制工具，保存事件证据，并识别受影响资源。客户应该选择恢复目标，安排备份计划，验证恢复，将快照或副本放置在相关故障域之外，并决定局部性限制是否允许离开区域或离开地区的副本。任何一方都无法完成另一方的全部工作。

区域磁盘和复制改变了故障模型，但并未消除对恢复思维的需求

Google 现在提供区域 Persistent Disk 和 Hyperdisk 高可用性选项。区域磁盘文档解释了在区域内跨地区复制磁盘以实现更高可用性，而区域磁盘故障转移指南描述了在主区域发生故障时进行强制附加。Google 关于将区域 Persistent Disk 用于高可用性工作负载的博客明确说明了可用性用例。

这些功能对许多工作负载而言是重大改进，但它们并不能消除架构判断。区域复制可以防止一个区域内的区域不可用或存储错误。但它可能无法防止应用级别的损坏被复制、客户删除、凭据泄露、区域范围的控制问题，或者过于接近当前时刻以至于无用的恢复点。客户仍然需要备份来应对损坏、保留和回滚。复制的磁盘是一种高可用性机制；它并不自动成为一套完整的数据保护方案。

同样的谨慎也适用于快照。快照可以独立于故障磁盘，并且可以恢复到另一个区域。但它仍可能过于陈旧、应用不一致、对正确的项目不可用、使用恢复环境无法访问的密钥加密，或者存储在违反策略的位置。Google 的磁盘加密文档提醒客户，磁盘和快照可能涉及不同的密钥选择。备份策略必须包括访问权限、密钥、保留、位置和恢复测试，而不仅仅是存在某个快照条目。

Compute Engine 的当前 SLA和历史上的2015 年 SLA 版本显示了另一个区别。SLA 涉及在定义条件下的服务可用性和积分。它们并非可恢复性或业务损失的全部表述。积分可以补偿一部分服务费用，而客户仍然必须恢复数据、核对事务、通知用户或重建信任。状态页面告知受影响的客户从快照恢复这一事实表明，运营恢复处于 SLA 积分问题之外。

对于数据主权所有者而言，复制选择需要仔细的政策工作。客户可能要求数据保留在欧洲或比利时境内。这并不意味着所有副本都必须位于一个区域。根据服务条款、监管机构期望和风险偏好，这可能允许快照位于欧洲多区域或另一个欧洲区域。反之，严格的位置要求可能会阻止某些跨区域备份，并要求更高的本地可用性设计。负责任的做法是在数据丢失之前明确这种权衡。

客户恢复证据是事件的一部分

提供商的事件报告通常在服务恢复后结束。数据丢失事件需要第二本账本：客户恢复证据。哪些磁盘有读取错误？哪些写入无法恢复？哪些客户从快照恢复了？哪些快照失败或过于陈旧？哪些应用程序需要手动核对？哪些客户工作负载没有备份？向客户发送了哪些关于永久性丢失和变通步骤的消息？有些证据是私有的，但公开的这些类别很重要。

状态页面反复提供的影响百分比很有用，因为它们避免了模糊的保证。不到 1% 易受影响、不到 0.1% 有读取失败、不到 0.000001% 永久丢失，这些描述了不断缩小的类别。不应将它们合并成一个单一的声明。易受影响的磁盘、正在发生故障的磁盘和不可恢复的数据是不同的状态。处于每种状态的客户需要采取不同的行动。

客户还需要特定于资源的通知。通用的状态页面告诉市场出了问题。它不会告诉某个数据库管理员特定的磁盘是否受影响。Google 拥有最强大的能力来识别受影响的资源、关联存储系统并提供账户级别的通知。客户拥有最强大的能力来检查应用一致性、从自己的快照恢复，并决定可能丢失了哪些最近的业务数据。这两类证据都是必需的。

这种划分对审计人员尤其重要。审计师在事件发生后审查云工作负载时，不应只询问提供商是否报告了一个小百分比。正确的问题是：组织是否知道其恢复点目标，事件前是否存在快照，恢复测试是否通过，备份位置是否符合策略，应用所有者是否接受了残余损失，以及提供商的通知是否提供了足够的细节来分类受影响的资源。如果答案是否定的，那么故障不仅仅是一次提供商事件；它也是一个架构治理的缺失。

采购部门应事先提出同样的问题。这个磁盘属于哪个故障域？存在什么独立的副本？谁负责快照计划？如何测试恢复？最大可容忍的写入丢失间隔是多少？局部性策略是否允许在别处放置副本？如果存储介质、电源或控制系统威胁到数据持久性，提供商将发出什么通知？在数据丢失事件期间的支持路径是什么？这些问题将“云持久性”从口号转变为风险决策。

采购不应将一个区域视为备份

比利时事件对采购特别有用，因为它揭露了一种常见的捷径。采购方询问数据将存放在哪里。提供商用区域或地区作答。采购方将那个答案视为弹性。但位置答案和恢复答案是不同的合同问题。一个描述的是放置；另一个描述的是丢失、损坏或不可用之后会发生什么。一份确保数据局部性但将备份设计留空白的合同，只解决了问题的一半。

一份强健的采购记录应在选择存储之前，明确工作负载所需恢复点和恢复时间。日志工作负载可以容忍一些延迟，但不能容忍无声丢失。事务性数据库可能需要每隔几分钟进行一次应用一致性备份。公共登记机构可能需要不可变备份和经过测试的恢复。一个小型分析项目可能接受每日快照。存储产品、快照计划、副本位置、加密密钥设计和恢复演练都应跟随任务需求，而不是反过来。

采购部门还应要求提供商建立通知模型。在存储事件期间，提供商可能比客户通过应用程序错误诊断更早地知道某个磁盘属于受影响群体。合同或支持计划应规定如何识别受影响的资源、如何告知客户是否建议进行恢复、如何报告永久性丢失、如何保留日志，以及如何优先处理技术支持。通用的服务状态页面对数据丢失事件而言不够充分，因为客户的行动是针对具体资源的。

采购方还应避免在主权和弹性之间做出错误选择。对于许多欧洲工作负载，位于另一个欧洲区域的独立副本可以满足策略要求，同时降低单区域风险。对于更严格的工作负载，可能需要在同一个国家内进行区域复制，或者需要经过仔细治理的备份位置。对于某些数据而言，额外副本的成本和复杂性可能不成比例。问责点不在于每个工作负载都需要相同的设计。而在于这种权衡应该被记录在案，并由理解丢失写入后果的业务所有者所接受。

审计人员应警惕打勾式的回答。“数据存储在欧洲”并不能回答它能否被恢复。“Persistent Disk 是持久的”并不能回答应用程序能否容忍近期写入的丢失。“快照可用”并不能回答它们是否已配置、近期、完整且经过测试。“提供商有 SLA”并不能回答客户是否有可用的副本。审计证据应包括恢复测试结果、备份时间、备份位置、密钥访问权限，以及谁接受了残余风险的记录。

小型团队需要让可恢复性可见的默认设置

最可能误解边界的客户，往往是最缺乏从越界中恢复能力的人。大型企业可能拥有存储团队、备份平台、审计委员会和桌面演练。小型团队可能只有一名工程师、一个项目、一个区域，以及一个使磁盘看起来持久的仪表板，因为可以在不删除卷的情况下删除虚拟机。他们的风险不是出于贬义的无知；而是抽象化做得太好的正常结果。

云提供商可以通过默认设置和警告来降低这种风险。当客户为类似数据库的工作负载创建单区域磁盘时，界面可以询问备份计划、推荐快照策略、显示故障域，并警告独立恢复需要快照。文档可以将故障域表放在创建工作流附近，而不是深藏在可靠性指南中。定价页面可以将无备份的成本显示为风险接受，而不仅仅是快照的额外成本。

客户可以通过简单的例程来降低风险。每个持久数据存储都应该有一个指定所有者、一个恢复点目标、一个快照或备份计划、一个恢复测试日期、一个备份位置和一个密钥访问计划。第一次恢复测试应在生产启动前进行，而不是在第一次事件期间。测试应将数据恢复到单独的环境，检查应用一致性，并确认团队能够认证、解密并重新连接工作负载。如果团队无法负担恢复设计，那应该是一个有意识的业务决定。

2015 年的事件是一个很好的教学案例，因为损失并不惊人。没有全球性崩溃让教训变得不可回避。百分比很小。然而，一个拥有单个受影响磁盘且没有近期快照的小团队仍可能面临永久性丢失。弹性教育常常侧重于巨大的灾难；此事件表明，罕见、狭窄的故障足以惩罚未经测试的备份假设。

同样的逻辑也适用于企业构建的内部平台。企业平台团队可能向产品团队提供“批准的云模板”。这些模板不应仅仅创建一个单区域磁盘，然后将备份选择留给可能不了解存储层的应用所有者。平台应要求或强烈引导快照计划、复制选项、保留期限和恢复测试。公司内部的共同责任镜像了与云提供商的共同责任。

数据丢失改变了状态语言的道义分量

许多中断状态可以用错误率升高、性能下降或恢复来描述。数据丢失需要不同的词汇。客户需要知道数据是延迟、不可用、损坏、回滚、部分不可恢复还是永久丢失。这些类别会产生不同的职责。延迟的数据可能需要队列处理。不可用的数据可能需要故障转移。损坏的数据可能需要验证和回滚。永久丢失可能需要通知、核对、赔偿或法律审查。

Google 的状态页面谨慎地经历了读取错误、性能下降和快照变通办法。当时的报道后来记录了极小存储比例的永久丢失。受影响人群的缩小是有用的，但公开的教训是，永久丢失应在获知后明确命名。过于长时间停留在可用性语言上的状态页面可能会使客户将数据丢失事件视为重试问题。过于宽泛地命名永久丢失的状态页面可能会引起不必要的恐慌。因此，精确性并非装饰；它控制着客户的响应。

存储事件的良好状态语言应说明受影响的产品、区域、时间范围、资源类别、症状、当前客户行动以及证据状态。它应将有风险的资源与已知有读取失败的资源以及确认有不可恢复数据的资源区分开来。它应说明快照、新磁盘、区域磁盘或其他存储产品是否受到影响。它应说明提供商能否直接识别受影响的资源，以及如何联系客户。当提供商从服务修复转向数据核对时，它应进行更新。

这种精确性也有助于客户向其自身利益相关者报告。数据保护官、审计师、董事会或小型企业主需要知道事件是否改变了机密性、完整性、可用性或可恢复性。2015 年的事件对于狭窄的磁盘群体是可用性加可恢复性问题。它不是未经授权访问的证据。将每次云事件都视为违规是错误的；将每次存储事件都视为短暂的可用性问题也是错误的。类别应与事实相符。

局部性决策应包含退出场景

每个局部性决策都应包含一个退出场景：如果这个区域、地区或本地存储选择失败，工作负载将迁移到何处，哪些数据会随之迁移？2015 年选择 europe-west1-b 区域的客户需要知道，故障磁盘是否可以在另一个区域恢复，快照是否存在于故障系统之外，应用程序能否附加恢复后的磁盘，DNS、凭据和运维人员能否恢复服务。尽管产品名称和功能已发生变化，这些问题至今仍然存在。

退出场景有几个部分。第一部分是数据：存在什么副本，它有多旧，它位于何处。第二部分是计算：什么环境可以运行恢复后的数据。第三部分是身份和密钥：谁可以访问并解密它。第四部分是网络和路由：用户如何到达恢复后的服务。第五部分是验证：团队如何知道恢复后的应用程序是正确的。第六部分是沟通：如何告知用户和利益相关者发生了什么，以及可能缺失了哪些区间数据。

局部性限制使退出场景变得更加复杂，但并非可选。如果数据必须留在比利时，设计可能需要多区域本地弹性、更频繁的快照和更强的现场备份控制。如果数据可以留在欧洲范围内，设计可以使用另一个欧洲区域或多区域快照存储。如果策略允许为灾难恢复进行全球备份，设计仍必须处理隐私、加密和访问控制。关键是要明确决定，而不是让默认的磁盘放置默默做出决定。

提供商可以通过以客户的语言呈现故障域来简化这一点。界面可以用“在虚拟机删除后仍存在”、“承受区域硬件故障类别”、“通过区域复制承受区域中断”，以及“通过快照支持时间点恢复”来代替单纯的产品名称。没有哪个简短短语能够涵盖所有边缘情况，但平实的故障域语言比宽泛的持久性形容词更不容易被误读。

未知因素与谨慎的边界

公开记录并未指明每个受影响的客户、每个丢失的写入、每个内部硬件型号或每个事件后的工程变更。它并未证明某个特定客户的备份故障导致了其损失。它并未确立法律违规、过失裁定、损害赔偿或合规性违反。它也未证明所有当前的 Google Cloud 存储产品带有相同的 2015 年风险。自那时以来，云基础设施和产品功能已发生显著变化。

公开记录确实支持几个明确的结论。该事件影响了 europe-west1-b 区域的 Persistent Disk。客户遇到了读取错误。Google 指示受影响的客户从快照恢复。基于 Google 说法的当时报道描述了四次连续的雷击击中本地电网、存储系统短暂断电、一部分存储的硬件易感性，以及极小比例的已分配 Persistent Disk 空间永久丢失。Google 表示将审查整体技术栈并升级存储硬件。当前的 Google 文档已明确说明快照、计划备份、区域磁盘和数据保护选择。

最重要的推论得到支持，但应被标注为推论：更清晰的故障域披露和经过测试的独立备份，可以减少物理场地危险变成永久性应用丢失的可能性。这与说每个没有快照的客户都是疏忽大意，或说 Google 未能履行法律义务不同。这是一个实际的控制结论。提供商可以使边界可见，并构建更具弹性的基础设施。客户可以选择不依赖单个本地磁盘的恢复设计。

该事件还提醒要防范两种相反的错误。第一种是云失败主义：因为一家超大规模提供商曾经丢失过极少量的数据，就认为云存储不可信。第二种是云自满：因为百分比极小，就认为没有人需要独立备份。成熟的立场更为苛刻，也更有用。利用提供商的持久性，但不要将其与恢复点混淆。利用局部性，但不要将其与弹性混淆。利用 SLA，但不要将积分与恢复后的状态混淆。

实际的证据测试足够简单，可以在采购结束前运行。采购方应能指出活跃磁盘、最新的独立恢复点、恢复目标、身份和密钥路径、负责恢复的人员，以及最近的成功测试。提供商应能指出故障域、针对特定资源的通知路径、事件状态类别，以及为面临永久丢失的客户提供的支持路径。如果任何一方在罕见存储事件发生前无法回答这些问题，那么架构就是在依赖隐藏在令人尊敬的产品名称背后的侥幸心理。

这就是为什么 2015 年的一个小事件在 2026 年的问责计划中仍然占有一席之地。它将抽象的共担责任模型转变为可见的运营契约。提供商的堆栈现在可能更强大，客户拥有更多工具，但决策逻辑仍然相同：局部性必须与可恢复的副本相配，可恢复的副本必须经过测试，经过测试的恢复必须被那些在数据缺失时将面对用户的业务所有者所理解。

该决策的最终所有者不应隐藏于基础设施缩写之中。它应该是一位了解丢失一小时、一天或一个事务间隔成本的指定服务所有者。

该所有者还应有权为备份提供资金。

排版是安排字体的艺术与技术，以使书面语言清晰、可读且视觉悦目。它涉及选择字体、点数、行长、行距和字距。

• 排版起源于 15 世纪约翰内斯·古腾堡发明的活字印刷术。
• 关键元素包括字体选择、字距调整、字间调整和行距。
• 良好的排版可以增强可读性，并在设计中传达情绪或基调。

比利时磁盘丢失记录之所以仍然有用，是因为它足够小，可以研究，足够严重，可以改变实践。它表明，提供商管理的冗余可能在物理危险的边缘失效，状态百分比必须按类别解读，快照只有在它们存在且能干净恢复时才重要，局部性不能替代独立的可恢复性。Google 控制了数据中心和存储堆栈；客户控制了他们的恢复架构；审计师和采购团队控制了这两种责任是否在下一次罕见事件发生前得到审查。负责任的结果是一个存储计划，能够说明数据位于何处，可恢复的副本位于何处，它有多新，谁可以恢复它，以及当本地区域不再有能力时，哪些证据将证明恢复成功。