简介这份资源面向需要在群晖NAS故障后抢救数据的运维人员与进阶用户提供一套基于Ubuntu 18的USB外接恢复思路与配套代码。适用于非RAID配置的群晖DS设备硬盘文件系统为EXT4或Btrfs的场景属于偏实操的中高阶技能内容。压缩包共3个文件包含1个inscode工程配置、1个html页面与1个gitignore忽略规则文件整体仅6KB轻量易取便于直接查看与二次整理。资源围绕接入硬盘、安装依赖、查看硬盘信息、挂载损坏NAS硬盘等环节展开并重点给出rsync断点续传与损坏文件处理、分批传输策略以及用DU和DIFF命令校验新旧数据一致性的完整方案可帮助读者建立从挂载到校验的排错路径。目前已有217人学习适合希望掌握Linux环境下NAS数据恢复流程的技术人员参考。1. Ubuntu 18 挂载群晖 NAS 硬盘为什么我放弃了数据恢复软件群晖 NAS 用久了总会遇到一个尴尬局面机器主板挂了、电源烧了或者 DSM 系统本身起不来但硬盘里的数据是完好的。这时候大多数人的第一反应是找一款数据恢复软件或者把盘插到 Windows 上用 DiskGenius 扫。我踩过这个坑——群晖的硬盘用的是 Linux 的 ext4 或 Btrfs 文件系统而且多盘位机型默认走的是 Synology Hybrid RAIDSHR或 mdadm 软 RAIDWindows 根本认不出来那些面向 U 盘数据恢复、手机数据恢复的工具在这里基本派不上用场。真正靠谱的思路是找一台 Ubuntu 18 的机器把群晖硬盘直接挂上去用 Linux 原生命令读取。Ubuntu 18.04 自带 mdadm、lvm2 和 btrfs-progs对群晖的存储结构兼容性最好这也是很多数据恢复从业者在处理群晖 NAS 时首选它的原因。这篇笔记面向的是手里有群晖硬盘、想自己动手把数据拷出来的开发者和运维从识别 RAID 结构一路讲到挂载、拷贝和权限修复中间该避的坑我都标出来了。2. 群晖存储结构拆解先搞清楚你的盘是什么布局2.1 单盘、SHR、RAID1、RAID5 的识别逻辑群晖的存储底层其实不神秘。单盘 Basic 模式就是一块盘上直接建 ext4 或 Btrfs 文件系统SHR 和传统 RAID 则是在物理盘之上叠了一层 mdadm 软 RAID再往上可能还有 LVM。你要做的第一件事不是急着 mount而是先看清楚分区表和 RAID 成员关系。把硬盘通过 SATA 转 USB 底座或者直接接主板 SATA 口开机进 Ubuntu 18。先看内核有没有认到盘# 查看所有块设备确认群晖硬盘是否被识别 lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT # 查看分区表群晖每块盘通常有 3 个分区 # sda1 是 DSM 系统分区sda2 是交换分区sda5 才是数据分区 sudo fdisk -l /dev/sda群晖每块数据盘的标准分区布局是分区 1约 2.4G放 DSM 系统分区 2约 2G是 swap分区 5 才是真正的数据区。如果你看到的是 sda5、sdb5、sdc5 这种结构说明这是多盘 RAID 布局。单盘 Basic 模式下直接对 sda5 操作就行多盘的话sda5、sdb5 这些分区会作为 mdadm 的成员盘组成一个 md 设备。# 扫描所有 RAID 阵列这一步能看出群晖用了什么 RAID 级别 sudo mdadm --examine /dev/sda5 sudo mdadm --examine /dev/sdb5 # 查看系统当前识别到的 md 设备 cat /proc/mdstatmdadm --examine的输出里重点看几个字段Raid Level告诉你这是 raid1 还是 raid5Array UUID确认几块盘属于同一个阵列Device Role标明每块盘在阵列里的序号。如果几块盘的 Array UUID 一致就可以尝试组装。2.2 组装 mdadm 阵列与激活 LVM确认 UUID 一致后用 assemble 模式把阵列拼起来。这里有个细节群晖的 RAID 元数据版本通常是 0.90 或 1.2Ubuntu 18 的 mdadm 都能识别但设备名不一定是 md0可能是 md127这是正常现象。# 自动扫描并组装所有可识别的 RAID 阵列 sudo mdadm --assemble --scan # 如果自动扫描失败手动指定成员盘组装 # --run 参数用于强制启动降级阵列缺盘时用 sudo mdadm --assemble /dev/md0 /dev/sda5 /dev/sdb5 --run # 再次确认阵列状态degraded 表示有盘缺失但可读 cat /proc/mdstat组装成功后/proc/mdstat里会显示md0 : active raid1 sda5[0] sdb5[1]。如果显示degraded说明有盘没接上或者已经损坏但只要 RAID1 或 RAID5 的冗余还在数据依然能读。接下来看 LVM。群晖在 RAID 之上通常还会建一个 Volume Group卷组里面再划分 Logical Volume逻辑卷。SHR 模式尤其依赖 LVM。# 扫描 LVM 卷组和逻辑卷 sudo vgscan sudo vgchange -ay # 查看逻辑卷列表找到容量最大的那个就是数据卷 sudo lvdisplayvgchange -ay是激活卷组的关键命令不执行这一步/dev/mapper/下面不会出现逻辑卷设备。激活后你会看到类似/dev/mapper/vg1-lv的设备这才是最终要挂载的目标。如果是 Btrfs 文件系统逻辑卷下面还可能有一个 Btrfs 子卷结构需要用btrfs subvolume list进一步查看。3. 挂载与数据拷贝ext4 和 Btrfs 的不同处理方式3.1 ext4 文件系统的挂载与只读保护搞清楚存储结构之后挂载本身不复杂但有一个原则必须遵守永远以只读方式挂载。数据恢复场景下任何写操作都可能破坏文件系统元数据让原本能读的数据彻底报废。这是血泪经验我见过有人直接mount可写模式结果 ext4 日志回放把目录结构改乱了。# 创建挂载点 sudo mkdir -p /mnt/synology # 只读挂载 ext4 逻辑卷 sudo mount -o ro /dev/mapper/vg1-lv /mnt/synology # 如果挂载报错尝试指定文件系统类型并跳过日志回放 sudo mount -t ext4 -o ro,noload /dev/mapper/vg1-lv /mnt/synology # 确认挂载成功查看数据目录 ls -la /mnt/synology-o ro是只读挂载noload参数告诉内核不要回放 ext4 日志。什么时候需要noload当文件系统被标记为 dirty比如 NAS 突然断电正常挂载会触发日志回放这个过程会写盘。加noload可以跳过回放直接读代价是可能看到一些不一致的目录项但至少不会二次破坏。如果逻辑卷本身没问题但挂载时报wrong fs type或者bad superblock先别慌。用file -s /dev/mapper/vg1-lv确认文件系统类型有时候群晖用的是 Btrfs 而不是 ext4命令要对症下药。3.2 Btrfs 子卷挂载与数据导出群晖较新的机型默认用 Btrfs挂载方式和 ext4 不同。Btrfs 的逻辑卷挂载后你看到的可能是一个包含多个子卷的根真正的数据在或data这类子卷里。# 先挂载 Btrfs 顶层 sudo mount -o ro /dev/mapper/vg1-lv /mnt/synology # 查看子卷列表 sudo btrfs subvolume list /mnt/synology # 如果数据在某个子卷里单独挂载该子卷 sudo mount -o ro,subvoldata /dev/mapper/vg1-lv /mnt/synology_dataBtrfs 有个好处是支持btrfs restore命令即使文件系统损坏到无法挂载也能直接从设备上提取文件# 不挂载直接从 Btrfs 设备恢复文件到指定目录 sudo btrfs restore -v /dev/mapper/vg1-lv /mnt/recovery_target # 只恢复特定目录 sudo btrfs restore -v -i /path/in/nas /dev/mapper/vg1-lv /mnt/recovery_targetbtrfs restore是只读操作不会修改源设备适合文件系统有损坏的场景。-v输出详细日志-i可以过滤只恢复某个子目录。恢复速度比挂载拷贝慢但胜在安全。数据拷出来的时候如果文件量大用rsync比cp靠谱支持断点续传和校验# 递归拷贝并保留权限、时间戳显示进度 sudo rsync -avP --progress /mnt/synology/ /mnt/backup_disk/ # 拷贝完成后校验文件数量是否一致 find /mnt/synology -type f | wc -l find /mnt/backup_disk -type f | wc -l-a保留权限和时间戳-v详细输出-P等于--partial --progress支持断点续传。群晖的共享文件夹权限体系比较复杂拷到本地后可能会遇到权限混乱的问题这个后面避坑章节会讲。4. 避坑与排查群晖数据恢复中最容易翻车的五个点4.1 现象mdadm assemble 报 “no such device” 或阵列起不来原因通常有三种一是硬盘没全部接上RAID5 缺两块以上就无法组装二是群晖的 RAID 元数据版本较老Ubuntu 18 的 mdadm 默认不自动扫描三是硬盘本身有坏道读取元数据失败。解决办法先确认所有成员盘都接好了用mdadm --examine逐块检查能否读出元数据。如果元数据能读但 assemble 失败手动指定--force参数强制组装。如果是坏道问题用ddrescue先把盘做成镜像再操作别直接在原盘上折腾。# 强制组装降级阵列适用于缺盘场景 sudo mdadm --assemble /dev/md0 /dev/sda5 /dev/sdb5 --force --run # 如果元数据版本问题指定元数据版本 sudo mdadm --assemble /dev/md0 /dev/sda5 /dev/sdb5 --metadata0.904.2 现象挂载成功但目录是空的或者只有 之类的子卷名这是 Btrfs 的典型表现。群晖的 Btrfs 数据卷顶层不是直接放用户数据而是通过子卷组织。你挂载顶层看到的是子卷列表不是实际文件。解决办法用btrfs subvolume list列出所有子卷找到名字类似、data、synology的子卷用subvol参数重新挂载。群晖的共享文件夹通常对应一个子卷名字可能经过编码需要逐个试。4.3 现象拷贝出来的文件权限全是 1000 或者 nobody群晖 DSM 里用户的 UID/GID 和 Ubuntu 默认用户不一致。群晖第一个用户的 UID 通常是 1024而 Ubuntu 第一个用户是 1000。直接 rsync 拷贝后权限映射会错乱。解决办法拷贝时用--numeric-ids保留数字 ID或者拷贝完成后用chown批量修正。如果只是要读数据内容权限问题可以先放一边数据本身是完好的。# 保留数字 UID/GID 拷贝 sudo rsync -avP --numeric-ids /mnt/synology/ /mnt/backup_disk/ # 拷贝后批量修正属主 sudo chown -R 1000:1000 /mnt/backup_disk/4.4 现象mount 报 “Structure needs cleaning” 或 “bad superblock”ext4 文件系统元数据损坏的典型报错。这时候千万别直接fsck修复fsck 会写盘可能让情况更糟。解决办法先用dumpe2fs查看备份超级块的位置然后用mount -o sb指定备份超级块挂载。ext4 在创建时会在多个位置保存超级块备份通常 32768 块位置有一个。# 查看备份超级块位置 sudo dumpe2fs /dev/mapper/vg1-lv | grep -i superblock # 用备份超级块挂载 sudo mount -t ext4 -o ro,sb32768 /dev/mapper/vg1-lv /mnt/synology4.5 现象RAID5 降级状态下拷贝速度极慢只有几 MB/sRAID5 在缺盘降级状态下每次读操作都要通过校验计算重建数据速度会大幅下降。如果同时还有坏道读取会反复重试速度可能掉到 1MB/s 以下。解决办法如果数据量不大耐心等。如果数据量大考虑先把每块盘用ddrescue做成镜像文件然后在镜像上组装 RAID这样避免原盘进一步恶化。镜像过程虽然也要时间但至少不会因为原盘彻底挂掉而前功尽弃。# 用 ddrescue 做磁盘镜像先镜像再操作 sudo ddrescue -d -r3 /dev/sda /mnt/images/sda.img /mnt/images/sda.log-d直接访问磁盘-r3重试 3 次log 文件记录进度支持断点续传。5. 进阶技巧从降级 RAID5 中重建数据与验证完整性RAID5 缺一块盘的时候mdadm 会以 degraded 模式启动数据能读但性能差。如果你手里有足够的盘但不确定哪块坏了可以尝试强制重组。这里有个技巧用--assume-clean参数可以让 mdadm 不进行初始同步直接按现有数据组装适合数据恢复场景。# 强制组装 RAID5假设校验块是干净的不做重建同步 sudo mdadm --assemble /dev/md0 /dev/sda5 /dev/sdb5 /dev/sdc5 --assume-clean --run--assume-clean的风险在于如果实际校验块和假设不符读出来的数据可能是错的。所以组装成功后一定要做数据校验。最简单的办法是找几个已知的大文件比如视频用md5sum对比恢复前后的哈希值。# 对恢复后的文件做哈希校验 md5sum /mnt/synology/video/test.mp4 md5sum /mnt/backup_disk/video/test.mp4 # 批量校验两个目录下同名文件的哈希 cd /mnt/synology find . -type f -exec md5sum {} \; | sort -k2 /tmp/source.md5 cd /mnt/backup_disk find . -type f -exec md5sum {} \; | sort -k2 /tmp/backup.md5 diff /tmp/source.md5 /tmp/backup.md5如果哈希不一致说明 RAID 重建过程中有数据错位。这时候可以尝试调整盘序群晖的 RAID5 盘序不一定是按 SATA 口顺序来的mdadm --examine输出里的Device Role才是正确顺序。把盘序调整后重新 assemble再校验一次。另一个验证手段是检查文件系统的一致性。ext4 可以用e2fsck -n做只读检查Btrfs 用btrfs check --readonly。这两个命令都不会写盘只报告问题。# ext4 只读检查 sudo e2fsck -n /dev/mapper/vg1-lv # Btrfs 只读检查 sudo btrfs check --readonly /dev/mapper/vg1-lv只读检查能发现目录项错误、块位图不一致等问题。如果报告大量错误说明文件系统元数据已经损坏这时候btrfs restore或ext4magic这类工具比直接挂载更有效。最后说一个习惯从那以后我每次处理群晖数据恢复都强制先对原盘做 ddrescue 镜像所有操作都在镜像上走一遍确认流程没问题了再动原盘。这个习惯救过我至少两次——一次是镜像过程中原盘彻底不认了但镜像已经完成了 90%另一次是--assume-clean组装后数据错位好在原盘没动重新按正确盘序组了一次就对了。数据恢复这件事后悔药就是提前做镜像。希望帮到你。本文还有配套的精品资源点击获取