块存储

1 块存储回答什么问题：给云服务器一块可挂载的盘

C4 介绍了云服务器：你能得到可运行操作系统与应用的计算资源。接下来要回答的是，数据库写下的记录放在哪里，服务器重启后数据是否还在，实例需要替换时又怎样保留数据。块存储提供的基本能力，就是给云服务器提供可挂载、可持久保存内容的盘。操作系统通常把它识别为块设备，应用再通过文件系统或数据库的存储机制使用它。

“块”描述的是访问接口：设备呈现连续的逻辑地址空间，读写请求按扇区寻址，可以随机修改某些位置，不必每次重写全部内容。设备的逻辑扇区大小与应用的 IO 大小是不同概念；数据库发出 8 KiB 请求，并不代表设备只有 8 KiB 的寻址单位。本文把一次输入或输出请求简称为 IO。数据库更新页、操作系统修改文件，都可能最终变成多个块读写请求。

用一句话区分相邻服务：块存储给出可寻址的设备，对象存储按对象标识访问完整对象，文件存储给出共享文件与目录接口。本课只沿着“设备如何成为可靠的数据盘”展开。目录、文件名、访问权限这些熟悉的东西，并不是空白云盘自带的；它们通常由操作系统在块设备上建立。

云盘通常经网络接入云服务器，底层由存储系统维护数据。它与实例所在物理机上的本地盘有不同的故障边界：实例被替换后，符合条件的云盘可以重新挂载；本地盘往往绑定物理主机，主机故障或实例释放可能导致内容丢失。本地盘可能有很好的性能，但不能因此默认它具有云盘的持久性。选型时要查明产品承诺的持久性、可用性与释放行为，而不能只看操作系统里相似的设备名称。

把云盘看成“远程接入的硬盘”有助于入门，但还要补上 2 个限制：请求会经过实例、网络与存储服务组成的路径，性能受到整条路径限制；盘通常有可用区归属，不能随意挂到任意地点的实例上。持久保存也不等于永远不会误删、损坏或被错误程序覆盖，所以本课还需要讨论快照与恢复。

2 卷类型与性能画像：IOPS、吞吐、时延

卷是云平台管理块设备时常用的资源名称。不同平台的名称不同，但常见产品族可以按性能目的理解：SSD 族偏向低时延与随机访问，HDD 族偏向较大请求的顺序传输，预配置 IOPS 族允许为稳定的随机请求能力付费。这些是选型方向，不是绝对保证；实际能力仍要查产品规格中的容量关系、吞吐上限、请求大小条件与服务承诺。

IOPS 表示每秒完成的 IO 次数，吞吐表示每秒传输的数据量，时延表示请求从发出到完成需要多久。只比较 IOPS 会漏掉大请求的带宽需求，只比较平均时延又可能掩盖少量很慢的请求。数据库用户感受到的卡顿，常与高峰期的尾部时延有关，因此需要同时看平均值与 p95、p99 等分位数，并确认指标的统计窗口。

假设有 1 块 100 GB 的盘，配置为 3000 IOPS，吞吐上限为 125 MiB/s。这里是教学规格，不代表任意厂商的实际套餐。若每个请求为 8 KiB，按 3000 次每秒计算，传输量约为 23.4 MiB/s；即使吞吐额度还有余量，也可能先碰到 IOPS 上限。若每个请求为 1 MiB，则约 125 次每秒就会碰到吞吐上限，远未用满 3000 IOPS。计算采用二进制单位，购买容量标注的 GB 与操作系统显示的 GiB 也要分清。

可用吞吐的粗略上界，可以写成“配置吞吐上限”与“IOPS 上限乘以平均请求大小”中的较小值。它只帮助定位可能的瓶颈，不能保证应用达到该数值。实例自身还有存储带宽或 IOPS 上限，多块盘可能共享实例配额；请求合并、缓存命中、读写比例以及应用并发也会影响结果。购买更快的盘之前，应先查明是哪一层用满了。

随机 8 KiB 工作集与顺序扫描的差别，首先在访问位置和请求大小。数据库频繁访问分散的数据页，即使总流量不大，也可能需要很高的 IOPS；顺序扫描连续的大文件，更容易消耗吞吐。工作集能否放入内存还会改变落到磁盘的请求量，不能用数据总容量直接推算 IOPS。性能试跑需要接近真实读写比例、并发与数据规模，并区分缓存已经预热和首次读取的结果。

队列深度描述同时等待或正在处理的请求数量。并发太低，设备可能吃不满；持续超过设备处理能力，排队会拉长时延。在稳定状态下，平均在途请求数约等于完成速率乘以平均响应时间：3000 IOPS、平均 2 ms，对应约 6 个在途请求。这个关系可以辅助交叉检查指标，却不意味着把队列固定为 6 就一定最好。应在业务可接受的时延范围内寻找足够的处理能力。

滑块中的容量、IOPS 与吞吐采用明确的教学模型。拖动容量时，观察容量费如何变化；拖动 IOPS 时，观察随机小请求的理论上界；切换请求大小时，观察瓶颈从 IOPS 转到吞吐。成本只是同一模型内的相对比较，正式预算必须代入供应商当期价格，不能把示意结果当作报价。

3 挂载、多挂载限制与可用区绑定

创建云盘时需要选择容量、类型与可用区。一般情况下，普通云盘只能挂载给同一可用区内的兼容实例。这里的“同一”指具体可用区标识相符，而不是同属某个地域。地域中有多个可用区，选择同一地域并不足以建立挂载关系。设计时先画出实例和盘的归属，再讨论高可用与迁移，能提前发现很多无法执行的组合。

挂载包含云平台和操作系统 2 个层次。控制台显示“已挂载”，通常只表示设备关联已经建立；系统还要发现设备，识别分区与文件系统，并把文件系统接入挂载点，应用才有可使用的目录。相反，系统里的卸载操作也不等于平台已经解除关联。设备路径可能因系统、驱动与重启而变化，持续挂载应使用稳定标识，并检查启动时的挂载失败行为。

多数普通数据盘默认只给 1 台实例使用。部分卷提供多挂载能力，但多个操作系统同时看到同一块设备，不等于可以安全地同时写入普通文件系统。缺少并发协调时，各实例可能根据各自缓存修改同一份元数据，造成文件系统或数据库损坏。多挂载只应进入产品明确支持的集群场景，并配合具备相应协调能力的软件；还要核对实例类型、操作系统、写入顺序和故障隔离要求。

实例运行期间是否支持挂载、卸载或调整卷参数，取决于产品与系统能力。即使平台允许在线解除关联，也应先让应用停止使用设备、刷新必要数据并卸载文件系统；强制分离可能留下未完成写入。把数据盘迁到另一台实例，不能理解为任意时刻直接拔走。热迁移实例的能力也不自动意味着数据卷可以跨可用区热搬迁，应分别核对计算与存储的迁移边界。

最后要明确资源释放规则。释放实例不一定自动删除数据盘，也可能因“随实例删除”等设置而删除指定卷。系统盘与数据盘还可能有不同默认值。创建与验收时记录这些设置：保留错误会产生闲置费用，删除错误则可能丢失生产数据。数据盘独立存在，也不代表应用已具备高可用；重新挂载、启动数据库与恢复连接都需要时间。

4 文件系统与分区：块之上才有目录

新建的空白卷只有可寻址空间，没有可以直接放文件的目录。常见准备顺序是识别目标设备、按需创建分区、建立文件系统、创建挂载目录，再将文件系统挂到该目录。分区用来划分设备空间，文件系统管理文件与目录，挂载点则是目录树进入该文件系统的位置。有些方案直接在整块设备上建立文件系统，并非所有盘都必须分区；关键是记录实际布局，保持操作方法一致。

格式化会写入新的文件系统结构，必须被当成可能破坏原有数据的操作。对从快照恢复或从旧实例转来的盘，先确认是否已有分区与文件系统，不能照着“新盘初始化”重新格式化。设备容量、卷标识、文件系统标识和预期用途应相互核对。仅凭设备名看起来像“第 2 块盘”就操作，容易在重启或设备顺序变化后选错目标。

挂载目录还会影响应用看到什么。盘没有挂上时，应用可能继续向根文件系统上的同名普通目录写入；后来盘挂上了，原有文件被挂载内容遮住，便出现“数据消失”的假象。数据库服务启动前应检查目标文件系统确实已挂载，并校验目录权限。验收时需要重启实例，确认挂载与服务启动顺序正确，不能只验证当前会话能读写。

扩容也有分层步骤：先调整云卷容量，再让系统识别新容量，然后按现有布局扩展分区，最后扩展文件系统。直接使用整盘文件系统时，没有扩展分区这一步。平台显示卷已变大，并不保证目录可用空间已经增加。不同文件系统的在线扩容能力不同，应先确认支持方式与维护窗口；缩容通常限制更多，不能把扩容步骤倒过来执行。

在这些动作之前准备可恢复的数据副本，并记录扩容前后的卷容量、分区边界与文件系统容量。扩容后还要检查应用能否继续正常写入。容量增加有时会改变性能额度，有时完全不会，取决于卷的计费与性能模型。本课只建立设备、分区和文件系统的层次关系，不需要引入额外的卷管理结构，才能完成普通数据库数据盘的部署。

5 快照与备份直觉：恢复点怎么来

快照记录某个时间点卷的内容，恢复时通常由快照创建新卷，再把新卷交给实例使用。很多服务在底层采用增量方式：首次保存必要数据，后续主要记录变化块，形成可管理的版本关系。用户看到的是可选恢复点，底层可能共享未变化的数据。不能把底层“增量”理解为恢复时必须由用户手工拼接所有快照文件，也不能据此猜测删除某个恢复点会释放多少空间。

快照通常有提交、处理中、完成等阶段。发起请求成功不等于恢复点已可用，应检查最终状态及服务定义的时间点语义。卷仍在写入时创建快照，服务可能捕获类似突然断电时的磁盘状态，称为崩溃一致性。数据库可能借助事务日志完成恢复，但这依赖其自身机制、持久化配置以及日志是否完整，不能保证每次都能恢复业务所需的完整状态。

应用一致性要求应用参与协调，例如按数据库支持的方式建立备份点、刷出必要内容，并协调相关卷的捕获。仅在文件系统层刷新缓存，并不自动完成数据库备份协议。若数据文件和事务日志分散在不同卷，需要使用受支持的一致性组或数据库备份方法，避免各卷来自不相容的时间点。暂停写入应有明确的结束条件与失败处理，防止备份任务失败后业务长期停写。

恢复点目标 RPO 表示允许丢失多长时间内的数据。若只依赖每天 02:00 成功完成的快照，次日 01:59 故障时，最近恢复点可能已接近 24 小时以前；备份失败未被发现，缺口还会更大。若业务只允许丢失 15 分钟数据，每日快照便明显不够，需要更密集的恢复点或数据库支持的连续保护机制。频率写在计划里不等于恢复点已产生，必须监测任务结果。

恢复时间还包含创建新卷、首次读取准备、挂载、数据库恢复和应用验证。有些产品从快照创建卷后，首次访问数据的时延与稳定运行时不同，应查明是否需要预热或专门的加速选项。判断快照是否有用，最终要看恢复出来的数据能否完成业务校验。快照保留多少天、谁检查失败、何时做恢复验证，都属于备份策略；更完整的演练组织方法留到 C44。

6 加密与删除保护：静态数据底线

生产数据盘应把静态加密作为默认要求，并在创建时确认加密状态。静态加密保护存储介质上的内容，服务在授权的读写路径中处理加解密。它不能阻止已经获得数据库访问能力的程序读取明文，也不能替代应用权限与网络访问控制。检查范围还要覆盖快照与恢复出来的新卷，避免只看到源卷上的“已加密”就认定全部副本都满足要求。

有的平台提供服务管理密钥，也可能允许指定用户管理的密钥。选型时记录使用方式、密钥所属地域与恢复所需条件；密钥权限的具体配置放在 C15。这里需要记住的工程事实是：数据副本存在，不代表永远能够解密读取。恢复验证应在实际恢复环境中完成，确认必要的密钥仍可用，不能仅凭快照状态为“成功”作出结论。

删除保护用于降低误操作概率，回收站或延迟删除则提供有限的挽回窗口。它们覆盖哪些资源、是否默认开启、保留多久，都需要核对。源卷受保护，不代表快照也受保护；卷进入回收站，也不代表费用立即停止。方案里要明确解除保护与最终清理的责任，并为闲置卷安排可追踪的处理流程。

加密与删除保护解决不同问题：前者降低介质内容暴露的风险，后者降低错误删除造成损失的概率。它们都不能代替备份。错误程序把合法数据覆盖后，加密会忠实保存被覆盖的结果，删除保护也不会把旧内容变回来。安全底线必须和恢复点一起检查，才能覆盖读取泄露、误删与逻辑损坏等不同故障。

7 常见坑：系统盘当数据盘、快照当备份策略、跨 AZ 硬搬

第 1 个坑是把数据库默认目录留在系统盘，然后只关注数据盘的备份。起初安装方便，后续系统日志、软件升级和数据库增长会争抢空间；重建实例或误选系统盘释放选项时，恢复也更复杂。小型测试环境并非绝对不能共用系统盘，但生产方案应明确盘角色与数据路径，检查数据库实际写入位置，避免“已购买数据盘”与“数据真的写入数据盘”之间存在空档。

第 2 个坑是把快照任务成功当成备份策略已经完成。没人检查保留期，没人验证新卷能否启动数据库，业务要求也未转成可接受的数据丢失与恢复时间，到了故障时才发现缺少日志或密钥。至少需要把恢复点、保留范围、任务失败处理与验证责任连成闭环。恢复验证要检查业务内容，例如指定订单与关联记录是否完整，而不只看卷能否挂载。

第 3 个坑是看到快照可以恢复到另一个可用区，就以为卷可以直接跨区挂载。常见做法是通过快照在目标可用区创建新卷，再切换实例和应用。快照的作用域、目标支持条件、复制过程与费用必须逐项核对，跨地域时尤其不能套用同地域规则。即使无需额外复制，创建卷与数据准备也需要时间，切换时还要处理源端继续写入的问题。

这些坑共同说明，控制台上的资源状态只是证据的一部分。盘存在、快照存在、加密开启，都要落实为应用路径、有效恢复点和可执行切换步骤。设计评审时让操作者说明“数据库现在写到哪块卷，若原实例消失如何找回”，往往比只展示资源清单更容易暴露缺口。

8 案例：数据库数据盘选型与快照节奏

某业务在 C4 选定的云服务器上运行 PostgreSQL，当前数据约 60 GB，预计近期增长到 80 GB。监测显示高峰随机 8 KiB 读写约 1800 IOPS，日常流量较低，批量查询偶尔产生顺序读取。团队先选 100 GB 通用 SSD 数据盘，将 3000 IOPS、125 MiB/s 作为待验证的规格，并确认产品能持续提供所需基线；若这些数字依赖突发额度，就要重新评估持续高峰是否能够支撑。

这份选择不能只用“1800 小于 3000”验收。数据增长会消耗容量余量，并可能降低缓存命中率；批量查询与事务写入重叠，也会增加排队。团队用接近真实数据规模的环境跑峰值负载，同时记录数据库事务响应时间、卷读写时延、队列与实例存储配额。若持续高峰出现排队，先定位瓶颈，再决定增加 IOPS、提高吞吐或改用更稳定的产品族。

部署时，数据盘与实例置于同一可用区，数据库的数据目录明确放在该卷的文件系统中，并核对该数据库部署所需的事务日志位置。系统盘保留操作系统与软件。挂载使用稳定标识，数据库启动依赖挂载检查，数据盘设置为实例释放时保留。加密在创建时开启，删除保护按生产要求配置，重启验收确认数据库没有回退到系统盘上的空目录。

恢复设计先写业务目标。假设该业务现阶段接受最多约 24 小时的数据损失，团队安排每日创建经过应用协调的快照，保留期覆盖约定的回溯窗口，并对失败发出可处理的通知。每周再生成可独立恢复的数据库备份归档，保存到对象存储，作为另一条恢复路径；对象存储的使用方式将在 C7 展开。这里的归档必须有明确的生成与恢复方法，不能把普通快照文件“直接搬过去”当作既成能力。

每日快照加每周归档是否足够，取决于这个已声明的业务目标。若目标改为最多丢失 15 分钟数据，就必须增加数据库支持的日志保护等机制，重新验证恢复链。周归档能增加恢复选择，但不能改善当天最近恢复点的时间间隔，更不能自动构成跨地域容灾。

交付验收包含 3 项实证：性能试跑达到约定负载和时延目标；从选定恢复点恢复到隔离实例，启动 PostgreSQL 并核对样例事务；源卷、快照和恢复卷的加密状态符合要求。恢复用时与实际数据时间点一并记录。只有这些结果落在方案里，100 GB 与 3000 IOPS 才从采购数字变成了可以解释的部署决定。

9 排查案例：IO 高延迟、挂不上、快照恢复后不一致

先看高延迟。某数据库平时响应稳定，活动开始后事务 p99 显著升高。先保存故障时间窗口，将数据库慢请求、卷 IO 指标和实例指标对齐，确认慢请求是否真的伴随存储时延增加。CPU 饱和、锁等待与连接排队也可能表现为“数据库慢”，不能看到磁盘存在就直接归因于盘。证据应覆盖读写 IOPS、吞吐、请求大小、队列与服务端限流指标，而非只有单个利用率数字。

路径 A 是队列深度或类型选错。假设随机请求达到接近 3000 IOPS，吞吐仍只有约 23 MiB/s，队列持续增长，就应优先怀疑小请求遇到 IOPS 瓶颈。若原本选的是偏向顺序吞吐的卷，高随机时延还可能来自类型不适合。处理时先减少非必要并发或错开批任务，再评估提高持续 IOPS。反过来，如果队列很浅且吞吐很低，应检查应用是否串行发请求，盲目购买更高上限可能没有收益。

路径 B 是突发余额耗尽。有些产品允许短时间超过基线，低负载阶段积累额度，高负载阶段消耗。现象可能是活动前段正常，持续运行后吞吐或 IOPS 降到基线，时延开始上升。需要查明产品是否采用该机制，再把余额下降与性能转折时间对齐。可行处置包括减少持续负载、增加符合需求的基线或切换到持续性能更合适的规格；等待余额恢复只能缓解当前症状，不能证明选型已经合理。

路径 C 是怀疑共享环境中的“吵闹邻居”。若实际负载未增加、卷与实例配额未到上限、突发额度正常，却出现异常时延，可以收集连续时间窗口、卷标识、可用区与对照测试，交由平台进一步定位。租户通常无法仅凭自己的图表证明底层邻居活动，因此应把它作为待证假设。平台事件、网络路径变化和自身后台维护也需要排除；不应一开始就强制卸载生产卷做迁移试验。

再看“挂不上”。某操作者要把保留下来的数据盘挂给替换实例，接口返回失败。先核对卷与实例的可用区标识：若不一致，原卷就不能按普通挂载流程直接连接，需要在目标区准备受支持的新卷。若可用区相同，再检查卷是否仍关联旧实例、是否处于处理中或异常状态、实例与卷类型是否兼容。平台已显示挂载成功而系统没有目录时，转查设备识别、文件系统与挂载配置。对已有数据的卷，格式化不能作为发现设备后的默认下一步。

最后看“快照恢复后不一致”。恢复卷能够挂载，PostgreSQL 却需要恢复，或应用发现预期记录缺失。先记录快照时间点、完成状态与恢复卷来源，确认没有选错日期；预期记录若产生在恢复点之后，缺失可能符合当前 RPO。若数据库报错，再检查快照时是否持续写入、数据与日志是否跨卷，以及是否采用受支持的协调方法。未停写并不必然导致损坏，但它要求数据库能够从捕获状态完成崩溃恢复。

排查时保留源卷与当前恢复副本，在隔离环境验证数据库恢复方法，避免应用继续向不完整副本写入。若缺少必要日志，应寻找其他有效备份或恢复点，不能用反复挂载代替数据恢复。最终证据包至少包含 IO 指标、卷状态、快照时间点和数据库恢复日志。修复之后还要补上导致问题的配置或备份缺口，否则同样的故障会在下一次切换时重现。

放进方案里

在 C4 的云服务器方案旁增加块存储页，先用盘角色表标明哪些内容写到哪里。表中记录卷标识、容量、类型、可用区、挂载点、数据责任人与随实例删除设置。不要只写“数据库有数据盘”，还要写清数据目录与必要日志的实际位置，避免安装默认值绕过方案。

性能目标要同时记录峰值请求大小、随机读写比例、持续 IOPS、吞吐与可接受的业务时延，并注明测试数据规模和持续时间。写出实例存储上限及卷基线，说明突发额度是否参与承诺。容量规划包含当前占用、增长预期与扩容触发条件，性能试跑结果作为附件，不能只留下产品名称。

挂载拓扑标明实例和卷的可用区、正常关联与替换实例路径。记录稳定挂载标识、启动依赖和卸载前的应用处理；若使用多挂载，必须附上软件协调能力与产品支持依据。跨区恢复则单列新卷创建、数据准备和应用切换所需时间。

快照与恢复部分写明 RPO、快照频率、保留窗口、一致性方法和失败处理责任。列出最近一次隔离恢复的日期、耗时、数据时间点及业务校验结果，说明周归档承担什么恢复用途。最后记录源卷、快照和恢复卷的加密要求、恢复所需密钥条件、删除保护及回收窗口。交付时逐项对应可见状态或验证记录，让接手者能据此选盘、找盘并恢复数据。

10 小结：走向对象存储（C7）与文件存储（C8）

块存储给云服务器提供按地址读写的设备；文件系统使它成为目录，应用决定数据怎样保持一致。选盘要把容量、IOPS、吞吐与时延放在同一张性能画像里，挂载要尊重可用区和并发访问边界，快照则必须经过恢复验证才有可靠的业务意义。

可以用 3 个问题自查：随机 8 KiB 请求为何可能先用满 IOPS？平台显示挂载成功后，应用为何还不能写目录？每天都有快照，为何仍可能达不到 15 分钟的 RPO？能够用本课的计算、层次与时间点回答，就掌握了数据盘方案的核心。下一课 C7 转向按对象访问的存储，C8 再讨论共享文件接口，继续比较不同访问方式适合解决的问题。

下一课转向 C7 对象存储：把本章验收过的结论带进后续主题，写成可检查的方案约束。