简介这份资源面向需要在群晖NAS故障后抢救数据的运维人员与Linux用户提供一套基于Ubuntu 18的USB外接硬盘恢复思路与配套代码。内容围绕EXT4/Btrfs文件系统识别、硬盘接入与挂载、依赖安装、rsync断点续传与损坏文件处理、分批传输策略以及用DU和DIFF命令校验新旧数据一致性等关键环节展开适用于非RAID配置的群晖DS设备。压缩包共3个文件包含1个inscode工程配置、1个html页面和1个gitignore忽略规则文件整体仅6KB轻量易取用。目前已有219人学习关注。读者可借助其中的脚本与页面快速理解恢复流程的工程化组织方式掌握数据比对与完整性验证的排错思路降低NAS故障带来的数据丢失风险。1. 群晖盘插进 Ubuntu18 那一刻我才发现事情没那么简单群晖 NAS 用久了最怕的不是硬盘坏而是机器先坏。我遇到过好几次主板点不亮、电源烧了、DSM 系统崩了进不去但硬盘本身是好的。这时候最直接的想法就是——把盘拆下来插到一台 Ubuntu 18.04 的机器上把数据拷出来。听起来简单做起来全是坑。这个标题讲的就是这件事在 Ubuntu 18.04 环境下恢复群晖 NAS 硬盘里的数据。核心难点在于群晖用的是 Linux 的 mdadm 软 RAID 加 LVM 逻辑卷再加上它自己的 ext4 文件系统普通 Windows 机器根本认不出来。Ubuntu 18.04 的好处是内核版本4.15对 mdadm 和 LVM 支持很稳而且 apt 源里工具齐全不用编译内核模块。适合谁看手里有群晖设备、硬盘没物理损坏、但机器暂时用不了的人。也适合那些想提前演练一遍恢复流程、免得真出事时手忙脚乱的人。下面我按实际操作的顺序把每一步的命令、参数和判断依据都写清楚。2. 先搞清楚群晖盘的分区结构和 RAID 类型2.1 群晖 DSM 在硬盘上到底写了什么群晖每块盘的分区布局是固定的。用fdisk -l或parted看典型的一块 4TB 盘长这样分区 1Linux raid autodetect约 2.4GB放的是 DSM 系统分区所有盘互为 RAID1 镜像。分区 2Linux raid autodetect约 2GB交换分区也是 RAID1。分区 3Linux raid autodetect剩余全部空间数据分区按你选的 RAID 类型组阵列。关键点分区 1 和 2 在所有盘上都是一样的只有分区 3 才承载你的数据。所以恢复数据时我们只关心分区 3 组成的那个 md 设备。先确认盘被系统认到了# 查看所有块设备确认群晖盘是否被识别 lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT # 如果盘没显示检查是不是被别的控制器挡住了 lsscsilsblk的输出里你会看到类似sdb、sdc、sdd、sde这样的设备每个下面挂着sdb1、sdb2、sdb3。如果 FSTYPE 列显示linux_raid_member说明分区类型正确。2.2 判断是 RAID1、RAID5 还是 SHR这一步决定了后面组装阵列的命令。群晖的 SHRSynology Hybrid RAID底层其实也是 mdadm只是元数据里多了一层标记。判断方法# 查看每个分区的 RAID 元数据 mdadm --examine /dev/sdb3 mdadm --examine /dev/sdc3输出里重点看几个字段Levelraid1 表示镜像raid5 表示带校验的条带。Devices阵列里成员盘的数量。Array UUID同一个阵列的 UUID 必须一致。Stateclean 或 active如果是 clean 说明阵列是正常关闭的。如果Level显示raid5但Devices是 4而你只插了 3 块盘那阵列是降级状态能读但没冗余。如果Level显示raid1那最简单单块盘就能直接读。提示SHR 在mdadm --examine里可能显示为 raid5 或 raid1具体取决于你当初建了几个盘。SHR-1 在 3 盘以上时底层是 raid52 盘时是 raid1。3. 在 Ubuntu18 上组装 mdadm 阵列并挂载 LVM3.1 安装工具并扫描现有阵列Ubuntu 18.04 默认可能没装 mdadm 和 lvm2先补上sudo apt update sudo apt install -y mdadm lvm2装完后先让 mdadm 自动扫描所有盘上的 RAID 元数据# 扫描但不要自动组装先看看有哪些阵列 sudo mdadm --assemble --scan --no-degraded--no-degraded的意思是如果阵列不完整缺盘先别组装。这是为了防止误操作把降级阵列强行拉起来导致数据错乱。如果输出提示找到了阵列但没组装说明阵列是完整的可以去掉这个参数再跑一次。3.2 手动组装阵列的完整命令自动扫描有时候认不全尤其是 SHR 或者盘顺序乱了的情况。我一般手动指定成员盘# 假设数据分区是 sdb3、sdc3、sdd3组成一个 raid5 sudo mdadm --assemble /dev/md0 /dev/sdb3 /dev/sdc3 /dev/sdd3 # 查看组装结果 cat /proc/mdstat/proc/mdstat里会显示md0 : active raid5 sdb3[0] sdc3[1] sdd3[2]后面跟一个[UUU]三个 U 表示三块盘都在线。如果是[UU_]说明有一块盘没认到阵列降级。如果mdadm --assemble报错说no valid superblock别慌先确认你指定的分区对不对。群晖的数据分区永远是分区 3不是整块盘。用mdadm --examine逐个确认每个分区。3.3 激活 LVM 并找到逻辑卷群晖在 md 设备之上又套了一层 LVM。组装好 md0 之后LVM 不会自动激活需要手动扫# 扫描物理卷 sudo pvscan # 扫描卷组 sudo vgscan # 激活所有卷组 sudo vgchange -ayvgchange -ay执行后用lvs看逻辑卷sudo lvs输出里你会看到类似vg1000/lv这样的名字vg1000是群晖默认的卷组名lv是逻辑卷名。这个逻辑卷就是你的数据所在。3.4 挂载逻辑卷并验证数据挂载之前先确认文件系统类型sudo blkid /dev/vg1000/lv大概率是ext4。然后建个挂载点挂上去sudo mkdir -p /mnt/synology sudo mount -o ro /dev/vg1000/lv /mnt/synology一定要加-o ro只读挂载。这是血泪经验只读挂载能防止任何意外写入比如系统自动生成lostfound或者你手滑删了东西。确认数据没问题之后再决定要不要重新挂载为读写。挂上后ls /mnt/synology应该能看到你的共享文件夹比如home、homes、photo之类的。4. 避坑恢复群晖数据时最容易翻车的 5 个地方4.1 现象mdadm 组装时报 “Device or resource busy”原因Ubuntu 桌面版会自动挂载它认识的块设备哪怕分区类型是linux_raid_member有时候 udisks2 也会去碰一下导致设备被占用。解决先卸载所有相关挂载点再停掉自动挂载服务# 查看谁占用了设备 sudo lsof /dev/sdb3 # 如果被 udisks2 占了临时停掉 sudo systemctl stop udisks2 # 再重新组装 sudo mdadm --assemble /dev/md0 /dev/sdb3 /dev/sdc3 /dev/sdd34.2 现象vgchange -ay执行后lvs还是空的原因LVM 的元数据可能因为群晖的版本差异没有被正确识别或者卷组处于 exported 状态。解决强制导入卷组# 查看卷组状态 sudo vgdisplay # 如果显示 exported导入它 sudo vgimport vg1000 # 再激活 sudo vgchange -ay vg10004.3 现象挂载时提示 “wrong fs type, bad option, bad superblock”原因你挂的可能不是数据卷而是群晖的系统分区或者交换分区。群晖的系统分区是 ext4但里面是 DSM 的系统文件不是你的数据。解决确认逻辑卷大小。数据卷通常是 TB 级别系统卷只有 2GB 左右。用lvs看LSize列挂那个大的。4.4 现象RAID5 缺一块盘强行组装后数据全是乱码原因RAID5 在缺盘时虽然能降级运行但如果缺的那块盘上有最新的写入数据校验重建会失败读出来的文件可能损坏。解决能凑齐所有盘就凑齐。如果实在少一块组装后先fsck -n只读检查文件系统确认没大问题再挂载。挂载后优先拷贝最重要的数据不要试图在降级阵列上做任何写操作。# 只读检查文件系统 sudo fsck -n /dev/vg1000/lv4.5 现象拷贝数据时速度极慢只有几 MB/s原因Ubuntu 默认的 IO 调度器或者 mdadm 的条带大小和群晖原厂设置不匹配导致大量随机读写。解决临时调整调度器为none或mq-deadline并确认条带对齐# 查看当前调度器 cat /sys/block/md0/queue/scheduler # 临时改成 none echo none | sudo tee /sys/block/md0/queue/scheduler另外拷贝时用rsync加--progress看进度别用文件管理器拖拽那个更慢。5. 把数据安全拷出来之后我习惯多做一步验证数据能挂载、能浏览不代表拷出来就一定能用。我一般会做三层验证确保万无一失。第一层文件数量比对。在源目录和目标目录分别统计文件数# 统计源目录文件数只读挂载点 find /mnt/synology -type f | wc -l # 统计目标目录文件数 find /mnt/backup -type f | wc -l两个数字应该完全一致。如果目标少了说明有文件没拷过去可能是权限问题或者文件名编码问题。第二层抽样校验大文件。挑几个最大的文件用md5sum比对# 源文件 md5sum /mnt/synology/video/bigfile.mkv # 目标文件 md5sum /mnt/backup/video/bigfile.mkv哈希值一样才算真正拷成功。我遇到过 rsync 显示完成但文件截断的情况就是靠这步发现的。第三层检查特殊文件名。群晖上可能有中文名、空格、特殊符号的文件在 Linux 下拷贝时容易出问题。用find列出所有非 ASCII 文件名确认都拷过来了# 找出所有包含非 ASCII 字符的文件 find /mnt/synology -type f | grep -P [^\x00-\x7F]如果目标目录里这些文件都在那基本就稳了。最后说个我自己的习惯恢复完之后我会把整个 mdadm 的组装命令和 LVM 激活步骤记在一个文本文件里和硬盘放在一起。下次再遇到同样的情况不用重新查资料直接照着敲就行。这个习惯帮我省过好几次事。希望帮到你。本文还有配套的精品资源点击获取