群晖NAS插入原硬盘后无法获取IP，拔掉硬盘却正常：DS1621+ RAID 6恢复实录

最近遇到了一个非常离谱的群晖故障：

我的群晖 DS1621+ 状态灯看起来基本正常，网口灯也在闪烁，但是连接到路由器之后，路由器中完全看不到NAS的IP，Synology Assistant同样搜索不到设备。

一开始以为只是网线、DHCP或者固定IP配置的问题，没想到最后一路排查下来，涉及到了：

• DSM系统分区异常
• 六盘RAID 6在线重组
• 临时硬盘安装DSM
• SSD读写缓存
• 系统迁移
• 系统分区修复
• RAID存储池修复

整个过程还是挺惊险的，尤其是NAS里面安装了很多套件、Docker服务以及几十TB的数据。

记录一下完整排查和恢复过程，给遇到类似问题的朋友做个参考~

注意：本文是我这台DS1621+的实际恢复记录。涉及RAID重组、迁移和修复时，一定要根据自己的阵列类型和界面提示判断。看到“初始化”“格式化”“删除存储池”等提示时不要盲目继续。

1. 故障现象

最开始的现象是：

• 群晖可以开机；
• 网口黄色指示灯亮；
• LAN灯持续闪烁；
• 路由器中看不到NAS的IP；
• Synology Assistant无法搜索到设备；
• find.synology.com同样无法发现NAS。

我首先更换了网线和路由器LAN口，并且只保留NAS的LAN 1连接，但是没有效果。

之后执行了一次群晖的Mode 1网络重置：

1. NAS保持开机；
2. 按住背后的RESET按钮约4秒；
3. 听到第一次蜂鸣声后立即松开；
4. 等待NAS重新获取DHCP地址。

但是重置之后仍然没有IP。

这时基本可以确定，问题不只是固定IP或者普通网络配置错误。

2. 电脑直连也找不到NAS

为了排除路由器和局域网隔离的问题，我把NAS的LAN 1直接连接到了电脑网口。

Windows获得了一个：169.254.x.xx的地址。

这说明网线的物理链路已经建立，但是直连环境中没有DHCP服务器。关闭电脑Wi-Fi、VPN、防火墙和虚拟网卡之后，Synology Assistant依然无法找到NAS。

到这里，网线、电脑网口和基本链路已经不是重点怀疑对象了。

3. 拔掉全部机械硬盘后，NAS居然正常了

接下来进行了一个非常关键的测试：

1. 正常关闭NAS；
2. 给六块原硬盘做好编号；
3. 记录每块硬盘原来的槽位；
4. 取出六块SATA机械硬盘；
5. 保留原来的两块M.2缓存SSD；
6. 无机械硬盘启动NAS。

结果NAS很快就出现在了路由器中，并且可以打开群晖安装页面。

这个结果说明：

• NAS主板基本正常；
• 网卡正常；
• 引导程序正常；
• 路由器DHCP正常；
• 问题和原来的六块机械硬盘或硬盘中的系统状态有关。

页面显示“未检测到硬盘”也是正常的。

虽然机器中仍然插着两块M.2 NVMe SSD，但是它们原来是作为SSD缓存使用的，安装页面不会把缓存SSD当作普通DSM安装硬盘。

4. 使用一块空硬盘测试六个槽位

为了排除硬盘背板和某个槽位损坏的问题，我找了一块没有重要数据的 1TB 空硬盘。

先把空硬盘插入槽位1，启动NAS，可以正常进入DSM安装页面。

之后按照下面的方式测试了全部六个槽位：

1. 关机；
2. 把同一块空硬盘移动到下一个槽位；
3. 开机；
4. 查看NAS能否正常获取IP；
5. 不安装DSM；
6. 继续测试下一个槽位。

最终六个槽位全部正常。

这一步基本排除了单个硬盘槽位故障。

5. 原来的任意一块硬盘都会导致NAS没有IP

接下来又尝试把六块原硬盘分别单独放入NAS。

结果非常一致：

• 任意一块原硬盘插入后，NAS都会报警；
• ALERT黄灯闪烁；
• 大约每隔3秒蜂鸣一次；
• NAS无法获取IP；
• 网络重置也没有效果。

一开始很容易怀疑六块硬盘是不是全部损坏了。

但是六块硬盘同时出现相同物理故障的概率很低，而且后续证明这些硬盘的健康状态基本正常。

更合理的判断是：

原硬盘中共同保存的DSM系统状态或系统分区出现了异常，导致NAS读取原系统后无法正常完成启动。

至于最初究竟是异常断电、DSM更新、系统分区错误，还是某个服务在启动阶段卡死，目前没有足够日志能够完全确定。

6. 在1TB空硬盘上安装一套新的DSM

因为使用空硬盘时NAS可以正常启动，所以决定先利用这块空硬盘安装一套新的DSM，再通过新系统读取原来的RAID 6。

操作如下：

1. 六块原硬盘全部取出并保持编号；
2. 1TB空硬盘放入槽位1；
3. 两块原M.2缓存SSD保持不动；
4. 安装新的DSM；
5. 创建一个临时管理员账号；
6. 不在1TB硬盘上创建存储池；
7. 不初始化M.2 SSD；
8. 不创建或删除SSD缓存。

这里所谓的“临时DSM”，并不是一个简化系统，而是一套正常安装的全新DSM。

称它为临时系统，只是因为安装它的目的不是长期使用1TB硬盘，而是先获得一个可以正常启动的管理环境。

7. 安装五块原硬盘，识别到“可用池”

原来的阵列应该是六盘RAID 6。

RAID 6缺少一块成员盘时，理论上仍然具有组装条件，因此我进行了下面的操作：

1. 1TB系统盘继续留在槽位1；
2. 原来的2～6号硬盘分别装回槽位2～6；
3. 原来的1号16TB硬盘暂时放在机器外；
4. 两块M.2缓存SSD保持原位置；
5. 启动NAS并进入新安装的DSM。

进入存储管理器后，系统成功检测到了：

五块16TB机械硬盘和两块M.2缓存盘也都能够正常识别。

这就是整个恢复过程中的第一个重大转折：

原来的RAID 6数据池还在，数据并没有因为DSM无法启动而直接消失。

8. 在线重组RAID 6

确认页面显示的是原来的RAID 6、容量基本正确、M.2缓存盘也已经识别之后，选择了：

在线重组完成后，原来的存储池和数据卷成功挂载，File Station中也可以看到原来的共享文件夹和文件。

不过这时出现了一个意外情况：

系统最终只使用了原来的硬盘3、4、5、6组成存储池，硬盘2虽然显示健康，但是没有加入阵列。

此时的RAID 6处于：缺少两块成员盘的状态。

RAID虽然能够访问，但是已经没有额外容错能力。因此恢复访问之后，第一件事不是折腾套件，而是先备份最重要的数据。

9. 使用原硬盘2进行第一次修复

进入：

查看硬盘2，发现：

• 容量正常；
• 温度正常；
• 健康状态为良好；
• 快速S.M.A.R.T.检测通过；
• 配置用途显示为“-”。

这说明硬盘2能够被系统正常识别，但是没有被当前存储池作为有效成员使用。

完整S.M.A.R.T.检测预计需要约24小时。考虑到当时的RAID 6已经缺少两块硬盘，继续等待期间同样没有多余容错能力，所以在备份关键数据并检查硬盘历史记录没有明显异常后，直接使用硬盘2修复存储池。

修复时DSM会提示：

这里的“擦除”仅针对被选中的硬盘2。

DSM会重新写入硬盘2，并根据当前阵列中的数据块和校验信息重建它，使其重新成为RAID 6成员。

第一次修复完成后，存储池变为五块16TB硬盘运行，虽然仍然缺少一块成员盘，但是已经重新获得了一块硬盘的容错空间。

10. 换回原来的16TB一号盘

硬盘2修复完成后，我关闭了NAS，取出槽位1中的1TB临时系统盘，并把原来的16TB一号硬盘装回槽位1。

重新开机后，并没有直接进入DSM，而是出现了硬盘迁移页面。

系统提示：

可以选择：

或者：

这里一定要选择：

然后继续迁移。

没想到迁移完成之后，居然成功进入了原来的DSM系统！

原来的NAS名称、账号和大量系统设置也重新出现了。

这说明原16TB一号盘中保存的旧DSM系统配置仍然可以被迁移程序识别。之前单独使用这块盘无法正常启动，并不代表里面的系统配置已经完全消失。

11. 修复硬盘2～6的系统分区

虽然原系统已经成功进入，但是存储管理器中显示硬盘2～6：

此时不能急着直接修复RAID存储池。

因为原DSM目前主要依靠硬盘1中可用的系统分区启动，应该先把正常的系统分区同步到其他五块硬盘。

进入存储管理器中的：

系统列出了硬盘2～6，点击修复后，DSM开始同步这些硬盘上的系统分区。

这个过程比16TB硬盘的RAID重建快很多。

完成之后，硬盘2～6全部恢复绿色“良好”，原DSM系统也已经不再只依赖硬盘1。

需要特别注意：修复系统分区和：修复存储池

是两个完全不同的操作。

前者主要处理DSM所在的系统分区，后者则会把选定硬盘重新写入RAID阵列。

12. 最后修复RAID 6存储池

系统分区全部恢复正常之后，存储池仍然缺少原来的一号成员盘。

此时再进入：

选择硬盘1作为第六块成员盘。

系统同样会提示硬盘1上的数据将被擦除。

这是正常现象，因为硬盘1虽然保留了可用的旧DSM系统配置，但是它需要重新作为第六块成员盘加入当前RAID 6，数据区域会被重新构建。

截至本文记录时，RAID 6存储池正在修复中。而且预计修复的时间特别久，硬盘2的修复时间是23小时，而硬盘1的修复时间是15天！！

修复期间需要注意：

• 不要关机；
• 不要重启；
• 不要拔插硬盘；
• 保持供电稳定；
• 尽量暂停虚拟机、下载和大量文件写入；
• 不要删除或重建两块M.2缓存；
• 定期查看硬盘状态和修复进度。

等修复全部完成后，六块16TB硬盘应当重新成为完整的RAID 6成员，存储池状态恢复健康。

13. 哪些东西最终恢复了？

这次恢复过程中，比较幸运的是原来的DSM迁移成功了。

目前恢复的内容包括：

• 原NAS设备名称；
• 原管理员账号；
• 原用户和用户组；
• 原共享文件夹；
• 原文件和数据卷；
• 大量控制面板设置；
• 原套件信息；
• 部分网络和服务配置；
• 原RAID 6存储池；
• 原M.2 SSD缓存关系。

不过迁移页面也明确提醒，部分配置仍然可能丢失。

后续还需要逐项检查：

• QuickConnect；
• DDNS；
• HTTPS证书；
• 防火墙规则；
• 反向代理；
• Docker/Container Manager；
• 数据库；
• 虚拟机；
• Synology Drive；
• Photos；
• Hyper Backup；
• 定时任务；
• 套件授权及运行状态。

套件中心中如果出现“修复”，建议先确认套件数据目录和共享文件夹仍然存在，再逐个处理，不要批量卸载和重装。

14. 这次故障中的几个关键转折点

回头看，整个过程中最关键的几个判断是：

14.1 无硬盘启动能够发现NAS

这一步证明了主板、网卡和基本引导功能正常，把问题范围缩小到了原硬盘和原系统状态。

14.2 用空硬盘测试全部六个槽位

六个槽位全部正常，基本排除了单个硬盘槽和背板通道问题。

14.3 不要因为单盘启动报警，就认为六块盘全部坏了

六盘RAID 6只插入一块原成员盘时，存储池和缓存都会处于严重缺盘状态，报警并不等于这块硬盘已经物理损坏。

真正有价值的判断是：

• 是否能够识别硬盘；
• 容量是否正常；
• S.M.A.R.T.是否正常；
• 是否存在I/O错误；
• 原存储池能否被识别。

14.4 临时DSM只是恢复工具

1TB硬盘上的新DSM帮助我重新识别并在线组装原RAID 6，但是它不需要永久留在NAS中。

原存储池成功组装并同步系统分区后，NAS仍然可以使用原来的16TB硬盘运行。

14.5 原系统配置还有机会通过迁移找回

之前我一度认为，在线重组之后只能继续使用新安装的DSM，原账号、套件和服务配置需要全部重新配置。

但是把原16TB一号盘装回去后，迁移程序检测到了原来的系统配置，并且成功通过“保留系统配置”进入了旧DSM。

所以在数据恢复过程中，不要轻易格式化最后一块可能保留旧系统配置的原硬盘。

15. 需要特别避开的操作

整个恢复过程中，下面这些操作风险很高：

• 不确认页面内容就点击安装；
• 选择“重置系统配置”；
• 创建新的存储池；
• 初始化原硬盘；
• 格式化原阵列成员盘；
• 删除原M.2读写缓存；
• 随意打乱六块原硬盘顺序；
• RAID修复过程中关机或拔盘；
• 在数据未备份时运行数据清理；
• Windows提示初始化磁盘时点击确定；
• 对群晖阵列硬盘运行chkdsk；
• 不区分“修复系统分区”和“修复存储池”。

尤其是看到下面这些关键词时，一定要停下来确认：

16. 总结

这次故障表面上看是：

但最后证明，网络本身并不是根本问题。

更准确的现象是：

NAS在读取原硬盘中的DSM系统状态后，没有正常启动到网络服务阶段。

这次也再次说明：

RAID不是备份，能够降级运行也不代表数据绝对安全。

以后还是要把最重要的数据另外保存一份，同时开启UPS、配置监控通知、定期检查S.M.A.R.T.状态，并做好DSM配置和套件数据备份。

不得不说，几十TB数据突然无法访问的时候还是挺吓人的……

好在最终原系统和数据都回来了，目前就等RAID 6修复完成了~

记录一下，给同样遇到“插入原硬盘就没有IP、拔掉硬盘却能正常发现NAS”的朋友做个参考。