企业官网建设流程全解析

前两天帮朋友把他的四盘位群晖从 4 块 4TB 换成 4 块 16TB，全程在线做完，中间没停过一次服务，照片、虚拟机镜像、Docker 里的数据库都还在原位躺着。他之前一直担心「换大硬盘会不会把数据搞没」，在论坛里翻了半天帖子反而更慌：有人说直接拔盘就行，有人说必须整池重建，还有人劝他先买块外置硬盘全量备份再拷回来。这些说法各自都成立，但适用的前提完全不同——你把它们混在一起看，当然会觉得矛盾。

所以这篇就把群晖在 DSM 7.0 下保留数据换大硬盘这件事完整拆开：你手上这块阵列的自然类型决定了走哪条路，容量在什么节点才会真正变大，哪些操作一旦点错就真的回不去。适合已经有一台群晖在跑、存储池快满了、想在不丢数据的前提下把容量抬上去的人。也适合刚上手 NAS 不久、看到「存储池降级」四个字就心跳加速的朋友。整个过程不需要命令行，也不需要额外软件，DSM 自带的存储管理器就够用。

1. 换盘前先认清你的阵列类型

1.1 四种常见阵列，换盘逻辑完全不同

很多人上来就问「怎么换盘」，这个问题其实没法直接回答，因为答案取决于你的存储池是哪种 RAID 类型。同样是「拔一块插一块」，Basic 和 SHR 的结局天差地别，一个能原地扩容，另一个只能搬家。

我一般让朋友先去「存储管理器 → 存储池」看一眼这个池子后面标注的类型：

• Basic：单盘独立用，没有冗余。换盘相当于把数据从旧盘搬到新盘，不存在「在线扩容」这回事。
• RAID 1 / SHR（两块盘）：两块盘互为镜像。换掉一块、重建完成、再换另一块，全部换完后容量才会跳上去。
• RAID 5 / SHR（三块及以上）：带奇偶校验，允许坏一块盘。这是最主流的配置，也是换盘收益最明显的一种。
• RAID 6 / SHR-2：允许同时坏两块盘，代价是容量利用率更低，重建时间也更长。

为什么要先分清这个？因为「能不能边用边换」这件事只对带冗余的阵列成立。Basic 那块盘是你唯一的副本，你拔下来的瞬间数据就悬空了，必须走另一条路径。

顺带说一句，SHR 是群晖自家的软 RAID 方案，底层其实是 mdadm + LVM 的组合，好处是允许混插不同容量的盘，代价是它比标准 RAID 更难预测最终容量。后面我会专门拿一节算给你看。

1.2 DSM 7.0 的存储管理器和 6.x 差别不小

如果你是从 DSM 6.2 一路升上来的，第一次打开 DSM 7.0 的存储管理器可能会有点懵——菜单位置变了，原来的「存储空间」概念被拆成了「存储池」和「存储空间」两层。

DSM 7.0 的层级关系是这样的：存储池是物理层，由若干块硬盘组成一个 RAID 组；存储空间是逻辑层，建立在存储池之上，你实际挂载、放共享文件夹的是这一层。一个存储池可以切成多个存储空间，也可以只切一个。这个设计的好处是灵活性高，坏处是很多人扩容时只扩了存储池，忘了扩存储空间，结果发现「怎么容量还是没变」。

换盘相关的入口我整理了一下，DSM 7.0 里主要用到这几个地方：

注意：DSM 的小版本之间菜单文字会有细微差别，比如「修复」有时候显示在存储池页面的操作菜单里，有时候在硬盘页面。找不到就去两个地方都翻一下，逻辑是一样的。

1.3 判断能不能原地扩容的三个硬条件

不是所有阵列换完盘容量都会涨，动手之前先自查三条：

第一，阵列必须有冗余。Basic 和无冗余的 JBOD 没有扩容一说，因为它压根就没有「阵列」的概念，只有一块盘。

第二，所有成员盘都要换成更大的。这是最容易被忽略的一条。RAID 5 里 4 块盘，你只换了 3 块，可用容量一点都不会变，因为阵列的容量取决于最小那块盘。必须四块全部换完，容量才会上台阶。很多人换了两块就急着问「怎么没变大」，就是这个原因。

第三，新盘容量要大于等于旧盘。拿一块 2TB 去替换 4TB 的位置，DSM 会直接拒绝，或者即使装上去也无法参与重建。这是硬性限制，没有绕过的方法。

把这三条对照一遍，如果都满足，恭喜你，可以走最舒服的在线替换路线了。

2. 三条换盘路线怎么选

2.1 逐盘替换：绝大多数人的唯一正解

这是我最推荐的方案，也是这篇文章的重点。核心思路很简单：每次只动一块盘，拔掉旧的、插上新的、等阵列重建完成，再动下一块。整个过程中阵列始终处于降级但可用的状态，服务不中断。

为什么这么设计？因为 RAID 的意义就在于「容忍一块盘缺席」。你把一块盘拔掉，剩下的盘靠校验信息依然能拼出完整数据，读写照常。只要在重建完成之前不再坏第二块盘，数据就是安全的。逐盘替换本质上是在利用这个冗余窗口做腾挪。

它的好处非常明显：不用停机，不用额外的中转硬盘，不用担心拷贝过程中断。代价是慢——一块 16TB 的盘重建一次可能要十几个小时甚至更久，四块盘换下来就是好几天。而且这几天里你的阵列一直处于「降级」状态，风险比平时高，这是必须接受的成本。

2.2 整池重建：什么时候它反而更省事

如果你的数据总量不大，或者你有完整可靠的备份，整池重建有时候反而更快。所谓重建，就是把整个存储池删掉，插上新盘重新组阵列，再把数据拷回去。

这个方案的优点是干脆利落，一次搞定，不用忍受好几天的降级状态，也不用担心重建过程中出意外。而且重组的时候可以顺便把 RAID 类型换掉，比如从 RAID 5 升级到 SHR-2，或者调整条带大小。

缺点是它要求你有一份完整的数据副本，而且这份副本必须放在别的地方——外置硬盘、另一台 NAS、云存储都行，但不能放在同一个池子里。16TB 的数据要找个地方放，这个门槛就把大部分人挡在门外了。

提示：如果你的数据能在 4TB 以内搞定，买一块大容量移动硬盘做中转其实是性价比很高的选择，比逐盘替换少折腾好几天。

2.3 外挂拷贝：单盘 Basic 用户的迂回路线

只有一块盘、跑的是 Basic 的朋友，上面两条路都不好走。你没有冗余可以借用，也没有第二台设备做中转，能依靠的就是外接存储。

常规做法是插一块 USB 硬盘上去，把数据整盘拷过去，然后关机换盘，装好 DSM 之后再拷回来。这里有个细节很多人做错：不要用 SMB 从电脑上中转，那样要过两遍网络，速度慢还容易断。直接在群晖上接 USB 硬盘，用 File Station 或者 rsync 在本地拷，走的是 USB 3.0 通道，快很多。

还有一种更省事的做法，如果你的新盘位够用（比如四盘位机器只插了一块盘），可以先把新盘装到空位上，在 DSM 里把它初始化成一个新的存储池，然后用 File Station 在两个存储池之间直接拷，速度比 USB 快一个数量级，拷完之后删掉旧存储池、把新池改个名字就完事了。

2.4 三种方案的横向对比

选哪条不用纠结，一句话：有冗余就走逐盘替换，没冗余就走中转。至于整池重建，留给那些本来就想重构阵列的人。

3. 硬盘选型与换盘前的准备清单

3.1 选盘：CMR、SMR 和 NAS 专用盘的门道

这一步选错，后面全是坑。先说最要命的一条：不要买 SMR 盘做阵列成员。

SMR 是叠瓦式磁记录，原理上磁道互相重叠，写入新数据时需要把相邻磁道的数据先读出来、再一起写回去，所以随机写入性能很差。单盘当仓库用问题不大，但放进 RAID 里做重建时，会因为写入速度跟不上而被阵列判定为「响应超时」，直接把这块盘踢出去，阵列二次降级，那就麻烦了。而且重建时间会被拉长好几倍，本来 12 小时能完事的拖到三四天。

识别方法很简单：查一下这块盘的型号，看厂商规格书里是不是写了 CMR。或者记住一个经验规律，大容量的入门级消费盘更容易是 SMR，NAS 专用盘线（比如标注了 NAS 字样的那类）基本都是 CMR。

第二件事是转速和缓存。7200 转的盘比 5400 转快，但噪音和发热也大，放在书房或者卧室的机器建议优先考虑静音。缓存方面，256MB 已经是大容量盘的标配，不用特别纠结。

第三件事是保修。阵列盘的工作强度比桌面盘高得多，24 小时运转是常态。如果预算允许，优先选标称支持 7×24 运行、MTBF 指标明确的产品线，出问题的时候你会感谢当初多花的那点钱。

3.2 兼容性确认和固件版本检查

买之前先去官网的兼容性列表里查一下你的机型。注意这不是形式主义——某些型号的主板或者背板对特定容量、特定批次确实有兼容问题，尤其是超过某个容量阈值之后。查一遍，两分钟的事。

固件方面有两个要看的：新盘本身的固件版本，以及群晖的 DSM 版本。DSM 最好升到 7.0 的较新小版本，早期版本在处理大容量盘扩容时有过一些已知问题，后来都修掉了。新盘上机之前不用特意刷固件，插上去 DSM 能识别就行，如果提示有固件更新建议先别急着更，等阵列重建完再说，重建期间不要做任何额外动作。

3.3 备份和快照：这一步不能省

我要说一句可能不太讨喜的话：任何声称「换盘不丢数据」的教程，前提都是你运气好。逐盘替换在理论上是安全的，但现实中存在你说不清的意外——重建中途断电、第二块盘恰好也在这一刻读不出来、新盘本身有出厂缺陷。

所以，动手之前做一次备份，不是不信任流程，是给自己留条命。备份放在哪？外置硬盘、另一台设备、云上都行，关键是不能在同一个存储池里。如果你平时就在用 Hyper Backup 或者 Active Backup，直接触发一次增量就好。

有 Btrfs 存储空间的，顺手打个快照。快照不能替代备份（它和源数据在同一块盘上），但能在误删、误改的场景下快速回滚，换盘期间多一层保险总没错。

3.4 换盘前要记录的信息

养成一个习惯，动手前把当前状态记下来，出问题时对比用：

• 存储池的类型、成员盘数量、总容量和已用容量
• 每块硬盘的位置编号（DSM 里会显示硬盘 1、硬盘 2 这样的槽位号）
• 共享文件夹的列表和各自所在的存储空间
• 有没有装 SSD 缓存、M.2 存储池、iSCSI LUN
• 套件里有没有依赖特定路径的应用（数据库、虚拟机、监控录像）

这几项看着琐碎，但一旦阵列出问题，你至少知道原来的配置长什么样，重建之后能照着恢复。我自己有个习惯，换盘前直接在 File Station 里截几张存储管理器的图存到手机里，比事后回忆靠谱。

4. 实操全流程：从拔第一块盘到扩容完成

4.1 先跑一次数据清理，让阵列达到最佳状态

在动手换盘之前，强烈建议先跑一次数据清理（Data Scrubbing）。这个操作会让阵列把所有盘的校验信息重新算一遍，把潜在的坏道读出来并修复掉。

为什么这一步重要？因为重建本质上是「用剩下的盘重算数据」，如果你的阵列里本来就藏着一块状态不太对劲的盘，重建时的巨大读压力很可能把它彻底压垮。提前清一遍，等于把隐患先暴露在低风险阶段。

入口在存储管理器里，选中存储池就能找到「数据清理」相关的操作。四块 16TB 的盘跑一轮完整清理，通常要一整天甚至更久，做好心理准备，让它自己跑就行，期间正常用没问题。跑完看结果，如果有坏道被修复，说明这一步做对了；如果直接报错、掉盘，那就别换了，先处理硬盘问题。

4.2 安全下线第一块硬盘

清理跑完、结果正常，就可以拔第一块盘了。这里有几个动作顺序上的讲究。

先确认阵列状态是「正常」，不是「降级」或者「正在校验」。然后在 DSM 里执行一次「安全移除」或者直接把这块盘设为离线，等系统确认这块盘已经不在阵列里了，再去物理拔盘。为什么强调这个顺序？因为直接热插拔虽然群晖大多支持，但阵列在不知道你要换盘的情况下突然少了一块，处理逻辑会稍微慌一点，稳一点总没坏处。

物理操作上，认准硬盘托架的释放按钮，按下、拉出把手、把盘抽出来。别在机器正在剧烈读写的时候拔，看一眼前面板的硬盘指示灯，不闪了再动。插入新盘的时候注意方向别插反，听到卡扣声就是到位了。

盘插进去之后 DSM 一般会自动识别，存储管理器里会多出一块「未使用」的新盘。这时候阵列应该显示「降级」，这是预期状态，不用慌。

注意：如果你的机器是免工具托架，插新盘之前确认一下托架的固定螺丝或者卡扣是不是给到位了，移动过程中盘没固定好导致的接触不良，是很多「莫名掉盘」的真实原因。

4.3 插入新盘并触发修复

接下来就是触发重建。位置在存储管理器里，选中那块新盘，找到「修复」操作，系统会让你确认用哪块盘去修复哪个降级的阵列，确认之后就开始。

这一步有个选择：修复的优先级。有些机型会问你「修复速度」或者「阵列同步优先级」，选项一般是「加快修复」和「保持系统性能」。我一般选后者偏平衡一档，原因是优先修复会把磁盘 IO 吃满，你这几天基本别想正常用 NAS 了，而优先性能的话重建时间大概拉长 20% 到 30%，但白天办公、看片都不受影响。晚上没人的时候它自己会跑快一点，实际体感差距没数字上那么大。

重建开始后，存储管理器里能看到进度百分比和预计剩余时间。这个时间估算非常不准，前期可能显示 20 小时，跑着跑着变成 40 小时，都是正常现象，因为后半程涉及大量随机读，速度会掉。

重建期间有几件事不要做：不要装新套件、不要跑大批量文件校验、不要让虚拟机做全盘扫描、不要扩容。把机器当它不存在，让它专心干活。

4.4 第二块及之后的盘，节奏怎么把握

第一块盘的重建是最慢的，因为要读全部数据重算。后面几块也是同样的流程，但有一个重要的判断点：必须等上一块盘的重建彻底完成后，才能拔下一块。

「彻底完成」的标志是存储管理器里阵列状态从「修复中」变回「正常」，进度条消失，并且最好再做一次数据清理确认。千万别说「进度到 99% 了应该差不多了」就把下一块拔了——那 1% 里可能就是最关键的收尾写入，这时候再少一块盘，阵列直接崩，全盘数据就悬了。

我自己的节奏是：一块盘修完，让它静置半天，跑一次 SMART 快速检测，确认新盘没报错，第二天再动下一块。四块盘换下来差不多要一周，慢是慢了点，但每次都在安全区里操作。

有人会问：能不能一次性全拔了插新的？答案是不能。RAID 5 只允许一块盘缺席，你同时拔两块，剩下的盘拼不出完整数据，阵列会直接进入「已损毁」状态，那就不是换盘了，是数据恢复。

4.5 最后一步：扩展存储池和存储空间

全部盘换完、阵列恢复「正常」，这时候你会发现一件奇怪的事：容量没变。

别急，这是正常的。RAID 扩容分两步，重建只是把新盘纳入了阵列，还需要显式地告诉系统「把这个池子扩到新容量」。

第一步，扩展存储池。在存储管理器 → 存储池里选中它，找到「配置」或者「扩展」的入口，系统会算出扩容后的可用容量，确认执行。

第二步，扩展存储空间。存储池扩完之后，上层存储空间的容量未必跟着变，需要到「存储空间」页面再执行一次扩展。Btrfs 格式的存储空间一般能在线完成，ext4 的也支持，但如果你的存储空间里挂了很多共享文件夹，扩展过程可能稍微久一点，耐心等它跑完。

这两个步骤顺序不能反，先池后空间。做完之后回共享文件夹看属性，可用容量应该已经跳上去了。如果只扩了池没扩空间，文件管理器里显示的可用空间还是旧的，很多人卡在这一步以为扩容失败，其实就是少点了那一下。

4.6 容量到底怎么算，拿个例子走一遍

我拿刚才那台四盘位机器算给你看，这样你心里有数。

改造前：4 块 4TB，SHR-1。SHR-1 在四盘等容量场景下等价于 RAID 5，可用容量的算法是（盘数 − 1）× 单盘容量 =（4 − 1）× 4TB =12TB。另外大概有 4TB 左右被校验信息占用，不体现为可用空间。

改造后：4 块 16TB，SHR-1。可用容量 =（4 − 1）× 16TB =48TB。加上文件系统的元数据开销，实际能在共享文件夹里用的差不多在 47TB 上下，这个损耗来自 Btrfs 的元数据和系统分区预留，属于正常范围。

再算一个混合场景，很多人的实际情况是分阶段升级的，比如先换两块：

过渡态：4 盘位里 2 块 16TB + 2 块 4TB。SHR-1 的处理逻辑是把盘按容量分层：先用所有盘的最小容量部分（4TB）做一层 RAID 5，得到（4 − 1）× 4TB = 12TB；剩下两块 16TB 各多出 12TB，这部分只有两块盘，做一层 RAID 1，得到 12TB。总计24TB。这个数字比很多人直觉里以为的要多，SHR 的分层算法在这里体现得比较明显。

过渡态二：3 块 16TB + 1 块 4TB。最小层 4TB × 4 做 RAID 5 = 12TB，剩余层 12TB × 3 做 RAID 5 = 24TB，总计36TB。

可以看出，每换一块大盘，容量就往上跳一截，不用等全换完。这也是 SHR 相对标准 RAID 的一个实际好处——虽然它底层复杂度更高、扩容算法更玄学，但中间态确实没有浪费太多空间。

5. 特殊场景处理

5.1 Basic 单盘：换盘等于搬家

单盘用户没有捷径，只能走「迁出 → 换盘 → 迁回」。我建议优先用空盘位的方案，没有空盘位就接 USB 硬盘。拷贝之前记得先用 File Station 或者 rsync 做一次校验，拷完抽样打开几个大文件确认完整性，别等到换完盘才发现拷贝中断了几个 G。

如果共享文件夹很多、权限关系复杂，建议先把共享文件夹的权限结构记下来，迁回之后重建会快很多。用户和用户组的信息存在系统分区里，换盘不影响，但共享文件夹是需要手动重建的。

5.2 RAID 1 和两盘 SHR：最简单也最容易踩坑

两块盘的阵列只有 2 块成员，冗余度为 1，也就是说你拔掉一块的瞬间，阵列完全失去保护。整个换盘过程中，剩下那块就是唯一副本。

所以这个场景下我特别强调：拔盘之前一定备份，重建期间不要做任何额外操作，一块修完再动下一块。两盘 SHR 的容量算法很简单，可用容量等于单盘容量，两块 16TB 就是 16TB，没有额外收益。如果空间需求持续增长，建议趁这次机会考虑升级到四盘位的机器，不然下次又要折腾一遍。

5.3 混合容量 SHR 扩容后的真实可用空间

上一节算过几个过渡态的数字，这里补一个容易被忽视的点：SHR 上层的存储空间和存储池是分离的，如果你的存储池里有多个存储空间，扩展池子之后要逐个扩展，不然只有第一个空间拿到了新容量。

另外，SHR 在全部换成等容量大盘之后，可用空间会接近标准 RAID 5 的水平，但 VMM 虚拟机、Docker 容器这些对 IOPS 敏感的应用，性能表现和 RAID 5 差不多，不会因为 SHR 的 LVM 层有明显衰减，这点可以放心。

5.4 挂过 SSD 缓存或 M.2 存储池的注意点

如果你的机器装了 M.2 做读写缓存，换盘前建议先把它卸掉。原因有两个：一是 SSD 缓存会拦截一部分写入，重建期间的 IO 模式发生变化，可能出现缓存命中率暴跌、写入放大严重的情况；二是万一下层阵列出问题，缓存里的脏数据反倒成了不确定因素。

卸缓存之后阵列性能会掉一截，但重建本来就慢，影响可控。等全部换完、容量扩完、跑完一次数据清理，再重新挂上缓存。

如果 M.2 上建的是独立的存储池，那不受这次换盘影响，但要检查一下缓存分层（Tiering）的配置有没有指到正在扩容的存储池上，有的话先解除关联。

6. 常见问题与排查实录

6.1 扩展按钮变灰点不动

这是问得最多的一个问题。几种原因按概率排：

第一种，还有盘没换完。阵列容量取决于最小那块成员盘，只要阵列里还留着一块旧的小盘，容量就不会增长，扩展按钮自然是灰的。去存储管理器看一眼成员盘的容量列。

第二种，存储池里有多个存储空间，你扩的是空间不是池。逻辑顺序是先扩池再扩空间，跳过第一步的话第二步会失败。

第三种，文件系统类型不支持在线扩展。极少数老旧的 ext4 存储空间需要先做一致性检查再扩展，或者扩容量太大时需要分批做。

第四种，SSD 缓存正在充电或阵列正在做校验，属于临时占用状态，等它跑完再试。

6.2 修复进度卡住或反复降级

进度条长时间停在某个百分比不动，先别慌，去 HDD/SSD 页面看新盘的 SMART。如果 SMART 正常、阵列状态是「修复中」，那多半只是 IO 被别的任务抢占了，比如夜里跑的备份任务、媒体索引、照片缩略图生成。把这些后台任务暂停掉，进度会慢慢跟上。

如果阵列反复从「修复中」跳到「降级」，那就是新盘或者旧盘真的有问题了。这种时候不要再尝试修复，先停止，把可疑的盘拿去单独检测。反复失败的重建非常伤盘，事不过三。

还有一个容易被忽视的原因：SATA 接口接触不良。尤其是换过盘的槽位，插的时候没插到底，平时读写看不出来，一到高负载重建就掉线。重新插拔一次、把托架推到底，很多时候问题就这么解决了。

6.3 全部换完容量却没变

排除前面说的「没扩池」「没扩空间」之外，还有一种情况：扩展操作确实执行了，但文件管理器里显示的可用空间还是旧值。

这多半是 SMB 或者 AFP 的挂载缓存没刷新。断开重连一次共享，或者在电脑上卸载再重新映射网络驱动器，数字就对了。NAS 本地的 File Station 一般显示的是实时值，用它对照一下就知道是不是缓存问题。

另外要提醒的是，扩容完成后有一部分空间会被文件系统元数据占用，48TB 的池子实际能用 47TB 出头是正常的，不要拿这个差值去找客服。

6.4 排查速查表

7. 换完之后要做的验证和维护

7.1 一致性检查与 SMART 复检

阵列恢复「正常」只是第一步，别急着把这事翻篇。先跑一次完整的数据清理，让系统把所有校验块重算一遍。这一步能发现重建过程中因为 IO 压力产生的静默错误，报出来就说明有盘需要关注。

清理跑完后，去 HDD/SSD 页面把四块新盘的 SMART 完整看一遍，重点看三个值：重映射扇区计数、待定扇区计数、UDMA CRC 错误计数。前两个是 0 最好，UDMA CRC 如果不是 0，说明数据线或者背板有传输问题，要查线和接口，跟盘本身没关系。

顺便看一眼硬盘温度，重建期间温度会明显偏高，结束后应该回落。如果长期在 50 度以上，考虑加个风扇或者改善机箱通风，硬盘寿命和温度关系很大。

7.2 抽样校验数据完整性

重建理论上不会改变数据，但做个抽样检查成本很低。找几个大文件算一下校验值，跟换盘前记录的对比。视频文件可以看能不能正常播放到最后几分钟，压缩包可以试试能不能完整解压。

如果你平时有跑档案校验的习惯（Hyper Backup 的完整性检查、或者自己写的哈希脚本），这时候正好用上。没做过也没关系，挑几个关键目录，用 File Station 的「属性」看文件数量和大小的汇总值是否合理，大方向对得上就说明没问题。

7.3 性能复测和共享权限检查

容量上去了，性能也值得看一眼。用同一套测试方法跑一遍，跟换盘前对比。一般来说，换成更大容量、更高缓存的新盘之后，顺序读取速度会略有提升，随机 IOPS 变化不大。如果发现速度反而下降了，回头查一下是不是新盘混进了 SMR，或者阵列的条带大小配置和以前不一样。

共享权限这块，逐盘替换不会动权限配置，但整池重建之后要重新配一遍。换完盘之后，我会逐个共享文件夹点进去，看看用户的读写权限、NFS 的 squash 设置、iSCSI 的 IQN 是不是都还在。这些细节平时不注意，等到别的设备连不上才发现，排查起来更麻烦。

7.4 长期维护的几个建议

换完这次的经历，我一般会顺手把几个习惯固定下来：

• 每月跑一次数据清理，把它设成定时任务，不用手动记。群晖的存储管理器里可以直接配置计划。
• 每季度看一次 SMART，重点看趋势不看单点值，某个指标连续几次上涨就要预警了。
• 容量留 20% 余量，别用到 95% 才开始想换盘。Btrfs 在空间接近满的时候性能掉得比较明显，而且快照和元数据都需要余量。
• 换盘前先想清楚下一次。如果这次已经感觉到盘位不够用，那不如直接规划下一代机型，因为单次换盘的折腾成本，比换机器还高。

最后分享一个我在实际操作里踩过的坑：第一次换盘的时候，我在重建期间手贱去点了一次存储池的「配置」，想提前看看扩容选项长什么样，结果 DSM 弹了一堆警告，虽然最后没出事，但那半天我一直在刷新页面看阵列状态。重建期间，存储管理器只用来「看」，不用来「点」，这条经验比任何教程都管用。