去年帮朋友收拾一台 DS220两块 4TB 塞得满满当当全是家庭照片和孩子的 4K 素材。他的第一反应特别朴素把老盘拔下来新盘插进去数据拷回来不就完事了。结果插上新盘那一刻DSM 7.0 弹出来一句存储池已损毁他才意识到群晖换大硬盘保留数据这件事真不是拔插那么简单。这篇要讲的是群晖 DSM 7.0 环境下如何在保留数据的前提下把硬盘换成更大容量。核心场景是 RAID 或 SHR 阵列里的逐块替换扩容也覆盖了单盘 Basic 用户只能备份重建的路径。适合已经有一台群晖在跑、盘位快满、又不想把数据搬来搬去重新折腾的人。看完你至少能判断出自己这台机器到底能不能在线换盘扩容换盘期间该做什么、不该做什么以及容量为什么经常换了却没变。1. 先把阵列类型摸清楚不然换盘就是白折腾换盘之前90% 的翻车都源于一件事没确认自己用的是哪种存储池。DSM 里能建的类型有好几种扩容能力天差地别。有人看着教程一步步换完最后发现容量纹丝不动就是类型不对。1.1 四类存储池的扩容能力对照存储池类型最少盘数逐块替换扩容换盘后可用容量规则Basic1不支持单盘容量无冗余JBOD1不支持各盘容量相加一块坏全丢SHR单盘容错2支持总容量减去最大单盘容量SHR-2 / RAID 64支持总容量减去两块最大盘RAID 12支持等于最小单盘容量RAID 53支持盘数-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) finish412.5min speed98000K/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 变成 8TBSHR-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 寸的大容量机械盘基本全是 SMR3.5 寸里部分型号也是。买盘之前查一下官方规格表里的记录技术字段写着 CMR 或 PMR 的才放心。我自己的原则是换盘只买 CMR 盘。多花的那点钱比起重建失败后重新折腾的时间和风险根本不值一提。4.4 温度、噪音与电源几十小时不间断压力测试的代价换盘期间硬盘是满负荷连续运转的热量和噪音都会明显上升。温度这块重建时硬盘温度冲到 50°C 以上很常见。建议提前把风扇调到全速模式控制面板 → 硬件和电源 → 风扇转速模式 → 全速模式。等重建完再调回来。如果机箱放在密闭的柜子里把柜门打开别让热风在里面循环。噪音这块两块盘同时寻道的声音在夜里会非常明显。做好心理准备或者把 NAS 挪到客厅、储藏间。电源这块是最不该省的一环。重建过程中掉电如果是 RAID 5 或 SHR 而且恰好另一块盘也有坏块那就只能上数据恢复了。有条件的话接一个 UPSDSM 支持在断电时自动安全关机。花几百块钱买个几百瓦的小 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.0Docker 容器是否起得来挂载路径是否正确反向代理规则、证书是否重新配好外网访问是否正常iSCSI LUN 和目标是否重建客户端能否挂载计划任务、通知设置、用户账号是否齐全虚拟机如果有的硬盘镜像是否完整我一般会建一个_checklist.txt放在共享文件夹里做完一项打个勾避免遗漏。5.3 换盘之外的另一个选择把新盘当新存储池还有一种很省心的思路如果 NAS 还有空槽位别换盘加盘。比如四盘位的机器只用了两块 4TB那直接插两块 8TB 进去建一个新的存储池和存储空间然后用 File Station 或 rsync 把老池里的数据搬过去搬完删掉老池把老盘拔了留作离线备份。这个方案的好处是全程在线、零风险老数据一直躺在原处直到你确认新数据完整。缺点是要求有空槽而且如果数据量很大拷贝时间也不短。6. 扩容完成后必须回头验证的几件事容量数字变了不代表一切就绪。下面这几件事我在每次换盘后都会过一遍。6.1 共享文件夹配额、快照与回收站如果你给某些共享文件夹设了配额比如限制下载文件夹最多 500GB扩容后配额不会自动跟着变。要去控制面板 → 共享文件夹 → 编辑 → 配额设置里手动调否则新增的空间对那个文件夹依然不可用。同样要检查的还有快照。Btrfs 卷的快照计划在扩容后应该照常运行但如果快照保留策略是保证可用空间不低于 X%扩容后这个比例的绝对值变大了实际可用空间反而可能被快照吃掉更多。建议去 Snapshot Replication 里看一眼计划任务和保留规则。回收站也是个隐形空间杀手。换盘后容量大了很多人就把回收站保留期从 30 天改成永久结果半年后发现空间又满了。建议保持一个明确的清理周期。6.2 套件与容器服务的连通性抽查存储扩容本身不会影响套件但如果前面经历了备份重建这里就要仔细查。重点查这几个服务检查点Hyper Backup任务是否还在目标路径是否有效Docker / Container Manager容器是否全部启动端口映射是否正常反向代理域名能否正常访问证书是否过期iSCSI客户端能否挂载读写是否正常虚拟机镜像文件路径是否有效能否开机媒体服务器媒体库路径是否指向新位置索引是否重建抽查方式很简单每个服务实际用一次。反向代理用手机流量访问一下iSCSI 在客户端拷个文件试试Docker 容器看日志有没有报错。别只看运行中的状态灯。6.3 把新增容量真正用起来的几种分配方式容量到手之后怎么分配也有讲究。一种做法是全部留给主存储空间让所有共享文件夹共享这个大池子。好处是灵活坏处是没有隔离某个文件夹疯狂增长可能拖累所有人。另一种是划分多个卷一个卷放重要数据并开启快照一个卷放媒体库和下载缓存一个卷专门给 Docker 和虚拟机用。这样不同业务的 IO 和快照策略可以分开管理某一类数据出问题也不会影响全局。我个人偏向第二种虽然管理稍微复杂一点但出问题时排查范围小很多。特别提醒一句划分多卷之后每次扩充存储池都要记得逐个扩充卷这是最容易被忘掉的一步很多人扩容完发现某个卷还是老容量就是漏了这步。踩过几次坑之后我现在的习惯是换盘前一天把所有备份跑完并验证换盘当天把手机静音、UPS 接好、风扇开全速然后每隔半小时cat /proc/mdstat看一眼进度。整个过程不需要什么高深技术靠的就是耐心和不手贱。硬盘灯在闪的时候最好的操作就是什么都不做。