企业官网建设流程全解析

去年帮朋友收拾一台 DS220+，两块 4TB 塞得满满当当，全是家庭照片和孩子的 4K 素材。他的第一反应特别朴素：把老盘拔下来，新盘插进去，数据拷回来不就完事了。结果插上新盘那一刻，DSM 7.0 弹出来一句"存储池已损毁"，他才意识到群晖换大硬盘保留数据这件事，真不是拔插那么简单。

这篇要讲的是：群晖 DSM 7.0 环境下，如何在保留数据的前提下，把硬盘换成更大容量。核心场景是 RAID 或 SHR 阵列里的逐块替换扩容，也覆盖了单盘 Basic 用户只能备份重建的路径。适合已经有一台群晖在跑、盘位快满、又不想把数据搬来搬去重新折腾的人。看完你至少能判断出：自己这台机器到底能不能在线换盘扩容，换盘期间该做什么、不该做什么，以及容量为什么经常"换了却没变"。

1. 先把阵列类型摸清楚，不然换盘就是白折腾

换盘之前，90% 的翻车都源于一件事：没确认自己用的是哪种存储池。DSM 里能建的类型有好几种，扩容能力天差地别。有人看着教程一步步换完，最后发现容量纹丝不动，就是类型不对。

1.1 四类存储池的扩容能力对照

这张表是整个操作的地基。Basic 和 JBOD 没有冗余，也就没有"换一块顶一块"的能力，DSM 根本不会给你在线扩容的入口。而 RAID 1 和 RAID 5 呢，扩容时会卡在最小那块的容量上——你换了 8TB 但还剩一块 4TB，可用容量永远出不来。SHR 相对宽容一些，因为它本质上是 LVM 套 RAID 的分层结构，但限制照样存在。

1.2 在 DSM 7.0 里花两分钟确认自己的架构

打开存储管理器，左侧点"存储池"，右侧会列出所有存储池和它的 RAID 类型。点进去看"存储池信息"，能看到硬盘数量、RAID 类型、总容量和状态。再点上面的"硬盘"标签，会列出这个池里每块盘的槽位、型号、容量、健康状态。

有个判断小技巧：如果存储池页面里只有一块盘，而"存储池类型"写的是 SHR 或 Basic，那基本可以确定没有冗余，后面只能走备份重建。如果写着 RAID 1、RAID 5、SHR 且盘数 ≥2，恭喜你，在线替换的路子走得通。

注意：DSM 7.0 和 7.1、7.2 的界面文案略有不同，7.2 里 Docker 套件改名叫 Container Manager，存储管理器本身的名字和位置没变。如果你是黑群晖用户，请先确认引导版本和存储池状态正常再动手，非官方硬件的兼容性风险要自己评估。

1.3 单盘 Basic 的死结：为什么它不给你扩容的机会

很多人的第一台群晖就是单盘起步，用了一两年盘满了才想换。这时候 DSM 是绝对不会给你"扩展存储池"按钮的——因为单盘没有冗余信息可参照，换盘就等于换掉全部数据。

这种情况下只有一个办法：备份 → 拆盘 → 装新盘建新池 → 恢复数据。听起来麻烦，但如果提前用 Hyper Backup 把数据备出去，实际耗时主要是数据拷贝的时间。反过来说，这也是个升级的好机会——既然要重建，顺手把单盘 Basic 改成 SHR-1 或 RAID 1，以后再换盘就不用遭这个罪了。

2. 动手前的保命三件套：备份、清点、体检

我见过太多人觉得"我这是 RAID，有冗余，不用备份"，然后在重建过程中断电、拔盘、或者插了一块 SMR 盘，数据直接没救。换盘这个操作本身就是对阵列的一次压力测试，冗余不是盾牌，是给意外留的缓冲时间。

2.1 RAID 不是备份：Hyper Backup 的落点怎么选

先说结论：换盘前一定做一次完整备份，哪怕你用的是 RAID 6。重建过程中如果另一块盘挂了，或者电源抖一下，整个池子就完了。

备份落点优先级从高到低：

• 另一台群晖：通过 Hyper Backup 的 rsync 或 Hyper Backup Vault，走局域网速度最快，恢复也最省心。
• 外接 USB 硬盘：插在 NAS 的 USB 口上，用 Hyper Backup 建一个本地文件夹任务。注意 USB 盘的容量要装得下，而且最好单独格式化，别和系统盘混用。
• 云端异地备份：C2、对象存储之类的，速度受限但胜在异地。适合放最核心的那部分数据。

Hyper Backup 建任务时建议选完整备份 + 多版本，第一次会跑全量，后面增量。换盘之前，手动触发一次备份并确认完成，别看着进度条 99% 就以为好了——一定要去备份目标里翻几个大文件试试能不能打开。

2.2 手工抄一份系统资产清单，比重装省三天

数据能备份，但配置往往备份不全。我吃过这个亏：数据完好无损，结果重建之后发现反向代理规则没了、定时任务没了、Docker 容器全没了，一个个重新配花了整整一个周末。

换盘前，花二十分钟手工记一份清单：

• 用户与群组：有哪些账号、各自属于哪些组、有没有开两步验证
• 共享文件夹：名字、所在存储空间、权限分配、有没有开回收站和快照
• 套件清单：套件中心里已安装的列表截个图
• Docker / 容器：docker ps -a输出、每个容器的挂载路径和环境变量（compose 文件记得备份）
• 计划任务：控制面板里的定时任务、SSH 里的 crontab
• 反向代理与证书：控制面板 → 登录门户 → 高级 → 反向代理，规则截图
• iSCSI：有没有 LUN 和目标，IQN 记一下

同时用控制面板 → 更新和还原 → 备份配置导出一份.dss文件，存到别处。它不含数据，但能救回账号和大部分系统设置。

2.3 换盘前的硬件体检和数据清理

换盘前最后一步，是两个容易被跳过的动作。

第一是数据清理。存储管理器里选中存储池，点"数据清理"。它会读取阵列中所有数据块做校验，Btrfs 卷还能顺带发现静默损坏。这个过程可能要跑几个小时甚至一整天，但非常值得——如果阵列本身已经有坏块，趁换盘前发现，总比在重建中途崩溃强。

第二是SMART 体检。存储管理器 → 硬盘 → 选中每块盘 → 健康信息，看"重新分配扇区数""待处理扇区数"是不是 0，看通电时间和温度。想看得更细，可以开 SSH 后跑：

sudo smartctl -A /dev/sata1

设备名因机型而异，先ls /dev/sd*看一眼。重点看 5、187、197、198 这几项的原始值，只要不为 0 就要警惕。

经验提示：如果现有阵列里已经有盘 SMART 报警，别急着换大容量扩充，先把它换掉恢复成健康状态，稳定运行一两周再考虑扩容。带着一块病盘做重建，风险是叠加的。

3. 逐块替换的全流程实操：4TB×2 升 8TB×2

假设你的场景是 DS220+，两块 4TB 组了 SHR-1，想换成 8TB×2。整个流程分四步：换第一块 → 重建 → 换第二块 → 重建 → 扩充。总耗时可能超过一天，别指望一个晚上搞定。

3.1 第一块盘怎么安全拔下来

拔盘有两种做法，我建议按顺序试。

方法一：DSM 里安全摘除。打开存储管理器 → 存储池 → 硬盘标签，选中要换的那块盘，看有没有"停用硬盘"的选项。有的话点它，系统会把这块盘从阵列里摘出来，存储池状态变成"已降级"，然后你就可以直接拔出托架。这个方式不用关机，对硬盘也友好。

方法二：关机换盘。如果找不到"停用硬盘"的入口（部分机型或版本没有），就走关机流程：控制面板 → 硬件和电源 → 关机，等指示灯全灭、风扇停转，再拔电源线。记住拔的是哪一块——存储管理器里的槽位编号和物理位置是对应的，槽位 1 是最上面或最左边那块，别搞反。

拔的时候按下托架上的卡扣，水平抽出来，把新盘装进托架，螺丝固定好，插回去。群晖的托架基本都是免工具的，对准导轨推到底就行。

3.2 修复存储池：重建期间什么能做什么不能碰

开机登录 DSM，打开存储管理器，你会看到存储池变成"已降级"状态，旁边有个修复按钮。点它，系统会让你选一块可用硬盘——就是你刚插进去的那块 8TB，确认后开始重建。

重建本质上是把健康的那块盘上的数据，按 RAID 算法重新算一遍写到新盘上。这个过程：

• 能做：正常浏览文件、看视频（别用高码率转码）、轻度使用套件
• 不能做：跑大批量文件拷贝、开 Docker 里的重负载任务、做套件更新、重启或关机
• 绝对不能做：拔任何一块盘、拔电源、同时换第二块

想知道重建进度，可以开 SSH 跑：

cat /proc/mdstat

输出里会有一行类似[====>....] resync = 42.3% (1687/4000) finish=412.5min speed=98000K/sec，能直接看到百分比、剩余时间和速度。这个命令在换盘期间我基本每半小时刷一次，心里有底。

DSM 里也有进度条，但藏得比较深，存储管理器 → 存储池 → 存储池信息里能看到。重建期间不要去改阵列配置，也不要插拔其他硬盘，任何一个误操作都可能让重建失败。

3.3 换完第二块盘，为什么容量还是老数字

第一块重建完成后，存储池状态回到"正常"。这时候你会发现一件很反直觉的事：容量一点没变，还是 4TB。

原因是 RAID 和 SHR 阵列的可用容量受最小盘限制。现在池里是 4TB 和 8TB 混搭，系统只会按照 4TB 的可用空间做镜像，8TB 多出来的部分暂时闲置。所以要把第二块也换掉。

重复 3.1 和 3.2 的步骤：摘除剩下的那块 4TB，插入第二块 8TB，修复存储池，再等一次重建。这第二次重建的量更大——因为数据已经分散在 8TB 盘上，实际读写的数据块更多，耗时会比第一次长不少。

这是整个流程里最容易急躁的阶段。两块盘的重建加起来十几个小时很常见，中间千万别因为"看着没动静"就手动重启。硬盘灯在闪，/proc/mdstat在动，就是正常的。

3.4 扩充存储池与被忽略的卷扩容

两块都是 8TB 之后，存储池状态正常，但容量可能还是 4TB。这时候需要手动触发扩容。

操作位置：存储管理器 → 存储池 → 选中存储池 → 右上角三个点或"更多" → 扩充。点下去，系统会提示扩容后不可回退，确认后开始。这个过程通常是秒到几分钟，取决于文件系统要扩展多少元数据。

如果存储池里有多个卷（不是单一卷），存储池扩充完后，还要去**"存储空间"标签里逐个选中卷 → 更多 → 扩充**，把文件系统也一起撑开。单一卷的存储池一般会自动跟着扩，但多卷的情况必须手动来。

扩容完成后回到存储管理器首页，容量数字应该从 4TB 变成 8TB（SHR-1 双盘，可用容量等于单盘容量）。用df -h确认一下挂载点的容量：

df -h /volume1

如果这里的数字还不对，先确认存储池容量是否已经变了，再确认卷有没有扩。这两个是独立的两层，经常有人只做了第一层就以为完事了。

4. 老教程不讲的四个坑：容量、SMR、耗时、温度

流程本身不难，真正让人头疼的是流程之外的东西。下面这四个问题，官方文档基本不会展开讲，但实际会遇到。

4.1 SHR 的容量账本：为什么三块盘只多了一点

SHR-1 的可用容量计算公式是：所有盘容量之和，减去最大单盘容量。这个公式看着简单，但实际算起来很容易算错。

举个例子，三盘位 SHR-1，原来 4TB + 4TB + 4TB，可用容量 = 12 - 4 = 8TB。现在你把其中两块换成 8TB，变成 8TB + 8TB + 4TB，可用容量 = 20 - 8 = 12TB。你以为换了 16TB 的盘就能白赚 8TB？实际上只多了 4TB。

再往下推：如果三块全换成 8TB，可用 = 24 - 8 = 16TB。这才是完整扩容。所以 SHR-1 有个经验法则——想扩容，至少要换两块容量相同的大盘，只用一块大的基本看不到容量变化。SHR-2 更严格，需要至少四块盘、换掉两块以上才能动容量。

RAID 5 就更直白了：（盘数 - 1）× 最小盘容量。三盘 RAID 5 换了两块 8TB 留一块 4TB，可用容量还是 8TB，一点没变。必须三块全换。

4.2 重建到底要多久，以及一个靠谱的估算方法

重建时间没有标准答案，取决于盘容量、盘速、CPU 性能和当时的负载。但有个粗略的估算方式：

• 每 TB 数据大约需要2 到 5 小时（机械盘 + 有负载的场景）
• 4TB 单盘重建：6 到 15 小时
• 8TB 单盘重建：12 到 30 小时
• 16TB 以上：可能两天以上

/proc/mdstat里的finish字段是最靠谱的预测，一开始会剧烈波动，等到进度过了 10% 之后基本就稳定了。

有个细节值得注意：重建速度会被后台任务严重拖慢。如果你在重建时开着 Hyper Backup 跑全量、或者 Plex 在做视频转码，速度掉一半很正常。我的做法是重建期间把能停的套件全停掉，媒体库扫描、缩略图生成、索引重建这些也一并关掉，让硬盘专心做一件事。

4.3 SMR 硬盘：最容易在重建时翻车的型号

这是个大坑，必须单独说。SMR（叠瓦式磁记录）硬盘不适合做 RAID 重建。

SMR 盘的写入机制是叠瓦式的，覆盖写的时候需要先把整条磁道读出来、改完再写回去，随机写入性能极差。在 RAID 重建这种持续大块写入的场景下，SMR 盘的速度可能掉到个位数 MB/s，重建时间从十几个小时变成好几天，而且中间失败的概率大幅上升。

怎么识别？DSM 7.0 在创建或修复存储池时，如果检测到 SMR 盘会给出警告。另外可以查硬盘型号，2.5 寸的大容量机械盘基本全是 SMR，3.5 寸里部分型号也是。买盘之前查一下官方规格表里的"记录技术"字段，写着 CMR 或 PMR 的才放心。

我自己的原则是：换盘只买 CMR 盘。多花的那点钱，比起重建失败后重新折腾的时间和风险，根本不值一提。

4.4 温度、噪音与电源：几十小时不间断压力测试的代价

换盘期间硬盘是满负荷连续运转的，热量和噪音都会明显上升。

温度这块，重建时硬盘温度冲到 50°C 以上很常见。建议提前把风扇调到全速模式：控制面板 → 硬件和电源 → 风扇转速模式 → 全速模式。等重建完再调回来。如果机箱放在密闭的柜子里，把柜门打开，别让热风在里面循环。

噪音这块，两块盘同时寻道的声音在夜里会非常明显。做好心理准备，或者把 NAS 挪到客厅、储藏间。

电源这块，是最不该省的一环。重建过程中掉电，如果是 RAID 5 或 SHR 而且恰好另一块盘也有坏块，那就只能上数据恢复了。有条件的话接一个 UPS，DSM 支持在断电时自动安全关机。花几百块钱买个几百瓦的小 UPS，比起数据丢失的代价，实在划算。

5. 只能备份重建的情况：单盘与无空位用户的搬迁路径

如果你的存储池是 Basic、JBOD，或者是盘位已满且阵列类型不支持在线扩容，那就走另一条路。这条路更原始，但只要流程对，同样安全。

5.1 单盘用户的完整搬迁链路

假设你是一台 DS120j 或 DS220+ 单盘，4TB 要换 16TB。

第一步，把 Hyper Backup 的任务建好，目标指向外接 USB 硬盘或另一台 NAS，跑一次完整备份，确认完成并抽查文件可读。

第二步，备份配置。控制面板 → 更新和还原 → 备份配置，导出.dss文件到本地电脑。

第三步，记录共享文件夹名字和权限。这一步别偷懒，恢复时如果名字对不上，套件可能找不到路径。

第四步，关机拔盘，装新盘，开机。DSM 会提示找不到系统，重新安装 DSM（如果系统是装在数据盘上的话）。装完之后建一个新的存储池，建议这次直接选 SHR-1 或 RAID 1，避免下次再遭这个罪。

第五步，装回 Hyper Backup 套件，接上备份盘，建恢复任务，把数据导回去。恢复比备份慢，16TB 的量跑一两天很正常。

5.2 恢复之后必须核对的一份清单

数据恢复完不是终点，下面这些必须逐项过一遍：

• 共享文件夹名字、层级、权限是否和原来一致
• 套件是否全部装回，版本是否兼容 DSM 7.0
• Docker 容器是否起得来，挂载路径是否正确
• 反向代理规则、证书是否重新配好，外网访问是否正常
• iSCSI LUN 和目标是否重建，客户端能否挂载
• 计划任务、通知设置、用户账号是否齐全
• 虚拟机（如果有）的硬盘镜像是否完整

我一般会建一个_checklist.txt放在共享文件夹里，做完一项打个勾，避免遗漏。

5.3 换盘之外的另一个选择：把新盘当新存储池

还有一种很省心的思路：如果 NAS 还有空槽位，别换盘，加盘。

比如四盘位的机器只用了两块 4TB，那直接插两块 8TB 进去，建一个新的存储池和存储空间，然后用 File Station 或 rsync 把老池里的数据搬过去，搬完删掉老池，把老盘拔了留作离线备份。

这个方案的好处是全程在线、零风险，老数据一直躺在原处直到你确认新数据完整。缺点是要求有空槽，而且如果数据量很大，拷贝时间也不短。

6. 扩容完成后必须回头验证的几件事

容量数字变了，不代表一切就绪。下面这几件事，我在每次换盘后都会过一遍。

6.1 共享文件夹配额、快照与回收站

如果你给某些共享文件夹设了配额（比如限制"下载"文件夹最多 500GB），扩容后配额不会自动跟着变。要去控制面板 → 共享文件夹 → 编辑 → 配额设置里手动调，否则新增的空间对那个文件夹依然不可用。

同样要检查的还有快照。Btrfs 卷的快照计划在扩容后应该照常运行，但如果快照保留策略是"保证可用空间不低于 X%"，扩容后这个比例的绝对值变大了，实际可用空间反而可能被快照吃掉更多。建议去 Snapshot Replication 里看一眼计划任务和保留规则。

回收站也是个隐形空间杀手。换盘后容量大了，很多人就把回收站保留期从 30 天改成永久，结果半年后发现空间又满了。建议保持一个明确的清理周期。

6.2 套件与容器服务的连通性抽查

存储扩容本身不会影响套件，但如果前面经历了备份重建，这里就要仔细查。

重点查这几个：

抽查方式很简单：每个服务实际用一次。反向代理用手机流量访问一下，iSCSI 在客户端拷个文件试试，Docker 容器看日志有没有报错。别只看"运行中"的状态灯。

6.3 把新增容量真正用起来的几种分配方式

容量到手之后，怎么分配也有讲究。

一种做法是全部留给主存储空间，让所有共享文件夹共享这个大池子。好处是灵活，坏处是没有隔离，某个文件夹疯狂增长可能拖累所有人。

另一种是划分多个卷：一个卷放重要数据并开启快照，一个卷放媒体库和下载缓存，一个卷专门给 Docker 和虚拟机用。这样不同业务的 IO 和快照策略可以分开管理，某一类数据出问题也不会影响全局。

我个人偏向第二种，虽然管理稍微复杂一点，但出问题时排查范围小很多。特别提醒一句：划分多卷之后，每次扩充存储池都要记得逐个扩充卷，这是最容易被忘掉的一步，很多人扩容完发现某个卷还是老容量，就是漏了这步。

踩过几次坑之后，我现在的习惯是：换盘前一天把所有备份跑完并验证，换盘当天把手机静音、UPS 接好、风扇开全速，然后每隔半小时cat /proc/mdstat看一眼进度。整个过程不需要什么高深技术，靠的就是耐心和不手贱。硬盘灯在闪的时候，最好的操作就是什么都不做。