群晖存储空间损毁修复续集：文件系统损坏的诊断与恢复

距离上次写《群晖“存储空间损毁”修复小记》才过去小半年我这边又踩了一次雷。群晖玩了五六年最让人血压飙升的弹窗莫过于存储管理器里那行红色的“存储空间 2 已损毁”后面还跟着一句“卷已卸载”或者“文件系统只读”。第一次遇到时我是真慌了手忙脚乱折腾了一整晚这次倒好凌晨收到群晖发来的告警邮件看到熟悉的红色提示心里反而平静了——因为我知道这个提示背后藏着的往往不是同一类问题。这次的情况和上次有明显的区别。上次是一块盘有坏道导致掉盘存储池状态直接“堪用”属于典型的物理层故障这次则是家里半夜断电NAS被硬生生断电后重启存储池本身还在但存储空间直接变“损毁”。说白了一个是硬盘坏了一个是数据组织方式乱了。两种场景对应的处理思路完全不同用错方法轻则白等重则可能让数据二次受伤。所以这篇续集我想把所有判断逻辑、实操步骤和踩坑经验完整记录下来给同样被这个红色告警折磨过的朋友一个可参考的排查路径。这篇内容比较适合两类人看一类是群晖NAS玩家尤其是存了重要资料、担心数据安全的用户另一类是准备入手或正在研究NAS的小白了解一下这类故障的本质能让你真遇到时少走很多弯路。整个修复过程不需要太高深的Linux知识但需要你冷静、按顺序操作我会把每一步背后的原理和判断依据都讲清楚。1. 故障现场先搞清楚“损毁”到底坏在哪一层1.1 这次的具体现象先说现象。那天凌晨四点左右手机上弹了条群晖邮件告警大意是“存储空间 2 已降级部分卷变为只读”。打开DSM的存储管理器一看存储空间 2 的状态栏是红色“已损毁”下面卷的挂载状态显示“已卸载”存储池那边则是黄色“堪用”degraded。乍一看挺吓人但仔细分析一下这个信息量其实很大。存储池显示“堪用”意味着阵列层面的冗余还在也就是说不是所有盘都挂了而存储空间直接损毁多半是卷内的文件系统元数据出了问题。进系统日志翻了半天看到几条“ext4-fs error”的报错时间点正好卡在断电重启之后心里就有数了——这是典型的非正常断电导致的文件系统损坏。“存储空间损毁”这个提示其实是个很宽泛的“错误帽子”就像医生跟你说“你身体不舒服”一样你得先搞清楚是哪个器官出了毛病不能上来就开刀。它可能是阵列里某块盘掉线可能是文件系统逻辑损坏也可能是硬盘物理坏道导致的连串反应。判断错了方向后面每一步都可能白费。1.2 关键判断逻辑损毁还是物理损毁第一次遇到这个提示的人最容易犯的错就是一看到“损毁”就急着点“修复”或者干脆把硬盘拔下来重新插一遍。我的建议是先花十分钟做三个基础判断。第一步看存储池状态。如果存储池显示“正常”只是存储空间损毁那大概率是文件系统或者卷层面的逻辑问题如果存储池显示“堪用”或“已损毁”那说明阵列里有一块或多块盘掉线了属于阵列健康度问题。第二步看硬盘SMART信息。这一步能判断是硬盘物理损坏还是单纯逻辑异常。物理问题就像水管真的裂了逻辑问题则像水管没破但阀门卡住了处理方式完全不同。第三步看系统日志。登录后执行tail -n 200 /var/log/messages重点找有没有ata、I/O error、ext4-fs error、md/raid这类关键词。如果看到大量ata3.00: exception Emask 0x0说明硬盘I/O层面已经出问题如果只是ext4_find_entry: deleted inode referenced这类再多也只是文件系统逻辑错误。用个生活化的类比逻辑损毁是书架上的书顺序乱了、标签贴错了你花点时间重新整理就行物理损毁是书架搁板断了、书掉了一地那就得先修书架。这次我判断下来属于前者。1.3 硬件排查别让“背锅”的硬盘真背锅在做任何文件系统修复之前我先用smartctl把每一块盘的健康状况过了一遍。这一步很重要因为如果硬盘已经出现大量坏道那后续的fsck操作越用力可能反而加速硬盘报废。sudo smartctl -a /dev/sda重点看几个关键指标Reallocated_Sector_Ct重映射扇区数硬盘发现坏扇区后会自动用备用扇区替换这个数值是 0 最安心。如果它持续增长说明盘体正在劣化。Current_Pending_Sector待映射扇区盘发现了读不出来的扇区但在等待时机做重映射。这个值一旦大于0就是强烈的坏道预警信号。UDMA_CRC_Error_Count如果这个数字在涨往往不是盘体问题而是SATA数据线接触不良或接口松动换根线或换个槽位就能解决。这次四块盘查下来除了系统盘SSD因为经常刷写日志导致磨损值略高之外数据盘的SMART指标都算干净。这进一步验证了我的判断问题出在文件系统层面而不是盘本身。确认这一条我才敢放心动手。2. 动手之前备份、诊断工具和准备工作2.1 为什么我不建议直接点“修复”群晖的存储管理器在检测到异常时经常会给一个“修复”按钮。但这个按钮的底层逻辑很多人没想明白它做的是阵列重建也就是从阵列里其他健康的盘读取数据重新同步到被标记异常的那块盘上。问题在于这个同步过程要整盘读取所有数据块耗时很长。以4TB的SHR阵列为例重建速度大概在每小时300到500GB之间意味着整个过程可能要好几个小时甚至十几个小时。如果问题盘本身有坏道或连接隐患同步到一半可能再次掉线导致阵列二次损伤甚至让原本能救的数据彻底没救。更要命的是如果故障根源是文件系统逻辑损坏点“修复”根本没有意义——它重建的是阵列里的数据块但文件系统的索引结构还是乱的修完该损毁还是损毁。所以我的建议是在看到红色告警后先花半小时做诊断不要急着点任何按钮。顺序应该是判断根因 → 尽量导出数据 → 再决定是修复文件系统还是重建阵列。2.2 先把数据导出来只读模式下抢救文件数据安全的第一原则永远是“在还能读的时候把关键数据复制出来”。这次虽然卷已经卸载但根据我的判断是逻辑损坏所以理论上还有抢救空间。如果你的卷还能挂载哪怕状态是“只读”第一时间打开File Station把重要目录比如照片、文档、代码仓库、数据库备份拷到外接USB硬盘、其他NAS或电脑上。这一步不用追求全量备份优先把不可再生的数据救出来就行。如果卷已经无法挂载可以尝试命令行只读挂载sudo mkdir /mnt/rescue sudo mount -o ro /dev/md2 /mnt/rescue注意这里的-o ro是只读挂载目的是在文件系统已经很脆弱的情况下避免任何写入操作造成二次损坏。如果挂载成功然后用rsync把数据往外拷sudo rsync -avP /mnt/rescue/ /volumeUSB1/usbshare/backup/如果连只读挂载都失败群晖里还可以试试通过“存储管理器”重新挂载卷或者把硬盘拆下来接到Linux电脑上用LiveCD启动后用同样的mdadm和mount流程去读取。这一步对新手有门槛但逻辑是一样的。2.3 确认必要的命令和工具准备动手前先确认群晖的SSH功能是开着的控制面板 → 终端机和SNMP → 启用SSH功能。然后用管理员账号登录ssh admin你的NAS_IP登录后先确认几个工具都在which smartctl fsck mdadm群晖系统默认自带smartctl、fsck、mdadm大多数版本都能直接用。如果没有smartctl可以先在套件中心装一个“硬盘信息”之类的套件或者通过synopkg install按需补上。还需要了解一个知识点群晖的md设备节点有固定规律。md0通常是系统分区DSM引导相关md1是swap交换分区md2及以后才是存储空间对应的设备节点。这是整个修复过程的定位基础后面会用到。3. 修复实操从SSH到文件系统恢复的完整过程3.1 查看阵列状态md0、md1、md2分别是什么登录SSH后第一步是确认阵列状态。执行cat /proc/mdstat输出会显示当前所有md设备及其状态。比如正常情况下会看到类似Personalities : [raid1] [raid6] [raid5] [raid4] [raidF1] md2 : active raid1 sda3[0] sdb3[1] 7814035456 blocks super 1.2 [2/2] [UU] md1 : active raid1 sda2[0] sdb2[1] 2097144 blocks super 1.2 [2/2] [UU] md0 : active raid1 sda1[0] sdb1[1] 2490176 blocks super 1.2 [2/2] [UU]这个例子里的md2是存储空间类型是raid1也就是SHR的基础形态之一两块盘都在线[UU]说明阵列层面没有掉盘。再执行sudo mdadm --detail /dev/md2可以看到更详细的阵列成员、同步状态等信息。如果这里显示的成员盘数量不对或者某块盘的状态是“faulty”或“removed”那就是阵列层面出问题了。我这次看到两块盘都在[UU]状态基本可以确定阵列是健康的问题集中在文件系统上。3.2 卸载存储空间并执行文件系统检查确认阵列健康后就该处理文件系统了。先把卷卸载避免修复过程中有进程持续写入sudo umount /volume2如果提示target is busy说明有程序还在占用这个卷。可以用lsof | grep /volume2查到占用进程先停掉再卸载。如果不确定都有谁在占用也可以用sudo fuser -km /volume2强制终止占用该卷的进程。注意这会把相关服务停掉但修复之后可以手动再启动。卸载完成后执行文件系统检查。我的存储空间文件系统是ext4所以用的是sudo fsck -y /dev/md2fsck检查ext4文件系统时会先重放journal日志然后检查inode、块、目录结构。加上-y参数的含义是对所有交互式问题自动回答yes省得修复过程中一页页按y。但这里有个实操细节值得多说一句如果你的盘上数据极其重要、丢失无法接受我建议先不加-y跑一次看它会报什么错。有些文件系统错误存在“修复方向”的选择自动修复并不总是最优解。实际执行时输出会是一大段一大段的报错和修复记录类似于e2fsck 1.44.1 (24-Mar-2018) /dev/md2: recovering journal /dev/md2 contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes ... /dev/md2: Unattached inode 26893456 /dev/md2: /lostfound: Found a deleted inode referenced ...这中间可能会看到大量inode、block相关的报错很多都是断电源头杀我的正常操作。重点看最后的统计信息如果结尾出现/dev/md2: ***** FILE SYSTEM WAS MODIFIED *****说明修复生效了如果出现ERROR: Filesystem errors remain说明问题比想象中复杂需要进一步处理。注意如果你的存储空间文件系统是btrfs千万不要用fsck去处理。btrfs的检查修复需要使用btrfs工具而且btrfs在挂载状态下的检查修复有额外风险。群晖较新版本默认推荐btrfs这种情况我建议优先走群晖GUI的“存储管理器”重新挂载方案或者把盘接到其他Linux机器上用btrfs-progs的btrfs check --repair谨慎操作。自己拿不准的时候优先导数据比硬修复更安全。3.3 重新挂载并检查数据完整性fsck跑完如果输出正常接下来就是把卷挂回去。可以直接执行sudo mount -a或者回到群晖GUI的存储管理器里选择对应存储空间执行“动作”→“挂载”。挂载后先用df -h确认卷已经在线容量显示正常Filesystem Size Used Avail Use% Mounted on /dev/md2 3.6T 1.8T 1.7T 52% /volume2然后进目录抽查一下文件ls /volume2这一步不能省。我会随手打开几个关键目录确认目录结构还在再随机打开几个文件确认能正常读取。如果一切都正常回到存储管理器存储空间状态应该已经从红色“已损毁”变成绿色“正常”。这次实际遇到的报错属实有点多fsck修了大半个小时但结果还算不错卷数据基本完整只有几个无关紧要的临时文件丢了在/lostfound里还能看到一部分。整体来说属于不幸中的万幸。3.4 如果fsck解决不了按阵列重建存储池上面说的是逻辑损坏的修复路径。但如果你判断下来是阵列层面问题比如存储池显示“堪用”某块盘掉了那流程就不太一样。场景A掉线但盘没坏。这种情况往往出现在异常重启或SATA线接触不好之后盘本身SMART正常。进入存储管理器找到已经“未激活”或“可卸载”的硬盘尝试重新挂载。如果群晖识别回来了直接对存储池执行“修复”触发阵列重同步。重同步期间NAS性能会下降温度会升高期间绝对不要关机、不要拔盘耐心等它跑完。场景B盘有坏道必须换盘。如果SMART指标恶化不要有任何侥幸心理。准备好一块容量不小于原盘的新盘插入NAS后在存储管理器里执行“更换硬盘”操作系统会从阵列的其他成员盘重建数据到新盘。这个过程同样很慢4TB盘通常要跑一个晚上。场景C阵列掉盘数量超过冗余上限。比如RAID5掉了两块盘SHR掉了两块盘这种损失就无法用阵列自身恢复了只能靠备份恢复数据。此时切忌对阵列做任何写操作把盘拆下来交给数据恢复专业机构处理反而更有机会。4. 常见问题排查与避坑心得4.1 一张表看清常见的“损毁”情况把“存储空间损毁”这个帽子下的常见情况总结成一张表方便你对照现象可能原因处理建议存储空间损毁存储池正常文件系统逻辑损坏fsck修复ext4或谨慎处理btrfs存储空间损毁存储池“堪用”某块盘掉线/被踢出检查硬盘重挂并触发阵列修复存储池显示“已损毁”掉盘数量超过阵列冗余换盘或从备份恢复SMART重映射扇区数持续增长硬盘物理损坏前兆立即备份并更换硬盘UDMA_CRC_Error_Count增长SATA线/接口接触不良换线、换槽位观察是否继续涨断电重启后出现ext4-fs error文件系统未安全卸载卸载后fsck修复后重启这张表不是万能药但能帮你在看到红色告警时快速归类至少知道该往哪个方向排查。4.2 黑群晖用户更容易踩的坑盘序与SATA控制器有相当一部分群晖用户是自组硬件跑的DSM系统这类环境出问题的概率往往比白群晖更高原因大多集中在两处。一个是盘序错乱。有些主板在重启后会把SATA盘的识别顺序打乱原本的/dev/sda变成/dev/sdb群晖在启动检测时就会误判阵列成员状态把健康的盘当成异常盘踢出阵列于是好好的存储池就“损毁”了。遇到这种情况先别急着换盘检查一下SATA控制器是不是设成了AHCI模式而不是IDE模式有条件的话把引导用的U盘和额外移动硬盘拔掉减少盘序变化的干扰。确认盘序问题之后重新扫描硬盘往往就能恢复正常。另一个是供电不足。自组NAS最容易被忽略的就是电源功率多块机械硬盘同时启动的瞬间电流非常大如果电源额定功率不够硬盘会瞬间掉电然后被系统标记为掉线。这种情况的典型特征是重启后某块盘时好时坏SMART查不出问题但掉盘事件反复发生。处理思路很直接换一个额定功率更充裕的品牌电源或者调整硬盘的错峰启动策略。4.3 修复完成后的加固建议这次故障的直接诱因是断电所以修复之后我做了一轮系统加固也建议你参考一下。第一开启SMART定期测试。群晖存储管理器里可以对每块硬盘设置S.M.A.R.T.测试计划我习惯设成每月一次快速测试、每季度一次完整测试。技术指标再好也扛不住定期体检。第二把通知推到手机上。群晖的“警报设置”里可以配置邮件和推送SMART异常、掉盘、温度过高都会第一时间发消息。这次凌晨那封告警邮件就是救了我一把的信号灯。第三有条件就上UPS。这次故障的直接原因就是断电如果家里供电不稳定或者有突然跳闸的风险一台几百块的UPS能避免太多麻烦。群晖支持UPS联动断电后可以自动进入安全关机流程从根上杜绝“非正常断电损毁文件系统”这一类问题。第四开启快照功能。如果你用的是btrfs文件系统记得开启共享文件夹快照。快照本质上是文件系统级别的时光机哪怕下次真的又损毁了也能快速回滚到最近一个健康状态比从头跑一次fsck要高效得多。第五重要数据多重备份。这一点是老生常谈但还是要说NAS不等于备份。重要数据至少再留一份冷备或云备硬盘是消耗品阵列也不是保险箱。另外修复完成之后我还做了一件事把所有关键数据再跑了一次完整校验确定没有静默损坏。具体做法是备份完做一个散列校验把源目录和备份目录的校验值对比一遍。这一步虽然耗时但能让人真正安心。这次修复用的时间不算长从接到告警到把卷恢复挂载大概折腾了四个小时。相比第一次遇到存储空间损毁时的手忙脚乱这次最大的收获是意识到存储空间损毁这个提示只要不涉及物理坏盘大部分时候都是可逆的。正是这个认知让我在处理问题时没有慌一步步按“判断—备份—修复—加固”的顺序来。最后再分享一个小技巧如果你也遇到了这个红色告警第一件事不是登录DSM而是先去翻一下系统日志和SMART信息。磨刀不误砍柴工先花半小时把根因搞清楚比急着点任何“修复”按钮都更安全。