简介这份资源面向需要在群晖NAS故障后抢救数据的运维人员与进阶用户提供一套基于Ubuntu 18的USB外接恢复思路适用于非RAID配置的群晖DS设备硬盘。压缩包共3个文件以inscode工程配置、html说明页面和gitignore忽略规则为主整体仅6KB属于轻量级代码包便于快速查阅与二次整理。已有219人学习关注说明该场景在数据恢复领域具有实际需求。内容围绕EXT4与Btrfs文件系统的兼容性展开涵盖接入硬盘、安装依赖、查看硬盘信息、挂载损坏NAS硬盘等关键环节并重点介绍rsync断点续传与损坏文件处理能力配合分批传输策略提升效率最后通过DU与DIFF命令校验新旧数据一致性。读者可据此获得一套可复用的恢复流程框架与排错思路降低数据丢失风险。1. 从一块掉盘的群晖里把数据捞回来Ubuntu 18 挂载 Btrfs 阵列的实战路径群晖 NAS 用久了最怕的不是硬盘坏而是整机突然起不来——主板烧了、电源挂了、DSM 崩了盘还在数据却读不出来。这时候最稳的思路不是急着买新 NAS 重新插盘而是把硬盘拆下来挂到一台 Ubuntu 18 的机器上直接读。群晖的存储底层大多是 Linux 的 mdadm 软 RAID 加 Btrfs 或 ext4 文件系统Ubuntu 18 自带的内核模块基本能覆盖只要搞清楚阵列组装顺序和 LVM 那层映射数据就能原样拷出来。这套流程适合手里有闲置 x86 机器、愿意敲几行命令的运维和开发不适合指望图形界面一键搞定的人。下面把我自己拆过的一套流程完整写出来包括阵列识别、只读挂载、数据拷贝和几个容易翻车的点。2. 先认清群晖的存储栈mdadm、LVM 和 Btrfs 三层怎么叠群晖 DSM 在创建存储空间时底层并不是简单地把一块盘格式化成 Btrfs 就完事。它默认会做三件事先用 mdadm 把多块物理盘组成软 RAIDSHR 本质就是 mdadm 的线性或 RAID1/RAID5 变体再在 RAID 设备上建 LVM 卷组和逻辑卷最后在逻辑卷上格式化 Btrfs 或 ext4。所以你在 Ubuntu 上直接mount /dev/sdb1大概率会失败因为那块分区根本不是最终文件系统只是阵列的一个成员。2.1 识别每块盘的 RAID 成员身份把群晖里的盘全部接到 Ubuntu 机器上先别急着挂载用lsblk和mdadm --examine看清楚每块盘的角色。群晖的盘通常会在每个分区上写 mdadm 超级块版本一般是 1.2元数据在分区头部 4K 处。# 列出所有块设备看清盘和分区的层级 lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT # 逐块检查 mdadm 超级块确认阵列 UUID 和成员关系 sudo mdadm --examine /dev/sdb1 sudo mdadm --examine /dev/sdc1 sudo mdadm --examine /dev/sdd1mdadm --examine的输出里重点看三个字段Array UUID相同的盘属于同一个阵列Device Role告诉你这块盘在阵列里的槽位Raid Device State如果是active说明成员完整。如果某块盘显示removed或faulty那它就是掉的那块先别把它组进去否则阵列可能起不来。2.2 用 mdadm 组装只读阵列确认成员完整后用--assemble把阵列拼起来。这里有个血泪经验一定要加--readonly因为群晖的 RAID 超级块里可能记录了 bitmap 和 reshape 状态Ubuntu 内核版本和群晖不一定完全一致贸然以读写方式组装可能触发自动 reshape把原本还能读的数据搅乱。# 以只读方式组装阵列--scan 会读取所有盘的超级块自动匹配 sudo mdadm --assemble --scan --readonly # 组装成功后查看阵列状态 cat /proc/mdstat sudo mdadm --detail /dev/md0/proc/mdstat里会显示md0 : active (read-only)以及成员盘列表。如果看到inactive或者只识别到部分盘先停下来用mdadm --examine逐块核对 Array UUID 是否一致别强行--force组装那是在赌数据。2.3 激活 LVM 并找到最终逻辑卷阵列起来之后上面通常还有一层 LVM。群晖的卷组名一般是vg1或vg1000逻辑卷名类似lv或volume_1。用pvscan、vgscan、lvscan三步把 LVM 激活。# 扫描物理卷、卷组、逻辑卷 sudo pvscan sudo vgscan sudo lvscan # 如果卷组显示 inactive手动激活 sudo vgchange -ay vg1 # 再次查看逻辑卷确认设备路径 sudo lvscan激活后你会看到类似/dev/vg1/lv的逻辑卷设备。这时候再用blkid确认它的文件系统类型群晖新机型大多是 Btrfs老机型可能是 ext4。确认之后就可以挂载了。3. 挂载 Btrfs 与 ext4只读挂载、子卷识别和拷贝策略到这一步阵列和 LVM 都就绪了但挂载 Btrfs 和挂载普通 ext4 有个关键区别群晖的 Btrfs 通常带子卷结构顶层卷挂上去可能只看到一个空目录或者之类的子卷名真正的数据在子卷里。另外群晖还会在 Btrfs 里启用压缩和 quotaUbuntu 18 的内核默认支持但挂载参数要写对。3.1 只读挂载并列出子卷先以只读方式挂载顶层然后用btrfs subvolume list看子卷布局。只读挂载的好处是任何操作都不会写回原盘避免误删或元数据污染。# 创建挂载点 sudo mkdir -p /mnt/synology # 只读挂载 Btrfs 顶层卷 sudo mount -o ro /dev/vg1/lv /mnt/synology # 列出所有子卷找到数据所在的子卷 ID 和路径 sudo btrfs subvolume list /mnt/synology输出里会看到类似ID 257 gen 12345 top level 5 path 和ID 258 ... path /volume1这样的行。群晖的数据一般在或者/volume1子卷下。如果顶层挂载后ls看不到数据就说明数据在子卷里需要单独挂子卷。3.2 挂载子卷并验证数据完整性找到数据子卷后可以用subvol或subvolid参数直接挂载子卷也可以先挂顶层再 bind mount。我一般直接用 subvolid路径更明确。# 卸载顶层 sudo umount /mnt/synology # 按子卷 ID 挂载数据子卷只读 sudo mount -o ro,subvolid258 /dev/vg1/lv /mnt/synology # 查看数据目录结构 ls -la /mnt/synology # 检查 Btrfs 文件系统健康状态 sudo btrfs filesystem df /mnt/synology sudo btrfs device stats /mnt/synologybtrfs device stats会显示每块盘的读写错误计数。如果read_errors或corruption_errors不为零说明某块盘有坏道拷贝数据时可能遇到 I/O 错误。这时候不要慌Btrfs 的 RAID1 或 RAID5 有冗余单块盘坏道不一定导致数据丢失但拷贝时要加-i忽略错误或者用ddrescue逐块抢救。3.3 用 rsync 把数据拷到安全位置挂载成功后拷贝数据建议用rsync而不是cp因为 rsync 支持断点续传、校验和、排除规则遇到坏道还能跳过继续。目标盘最好是一块独立的、容量足够的 ext4 或 XFS 盘别往同一组阵列里写。# 挂载目标盘 sudo mkdir -p /mnt/backup sudo mount /dev/sde1 /mnt/backup # 用 rsync 拷贝-a 保留权限-H 保留硬链接-v 显示进度 # --ignore-errors 遇到坏道跳过--partial 保留部分文件便于续传 sudo rsync -aHv --ignore-errors --partial /mnt/synology/ /mnt/backup/synology_data/ # 拷贝完成后校验文件数量 find /mnt/synology -type f | wc -l find /mnt/backup/synology_data -type f | wc -l-aHv里-a是归档模式保留权限、时间戳、符号链接-H保留硬链接群晖的 Btrfs 快照和某些备份目录会用到硬链接不加这个参数会重复拷贝导致容量爆炸。--ignore-errors在遇到坏道时继续而不是中断但拷完后要检查 rsync 日志里哪些文件被跳过单独用ddrescue处理。4. 避坑与排查阵列起不来、子卷挂不上、拷贝中断怎么办这套流程听起来顺但实际操作里翻车点不少。下面五条是我自己踩过或者见别人踩过的按「现象 → 原因 → 解决」写清楚。4.1 现象mdadm --assemble --scan后/proc/mdstat显示 inactive原因通常是成员盘数量不够或者超级块里的阵列状态是clean但degradedUbuntu 的 mdadm 默认不会自动启动降级阵列。另一个可能是群晖用了非标准 chunk size 或 metadata 版本Ubuntu 的 mdadm 版本不认。解决先用mdadm --examine确认所有盘的 Array UUID 一致然后手动指定成员盘组装加--force但保持--readonly。如果还是不行检查 Ubuntu 的 mdadm 版本群晖 DSM 6.x 之后常用 metadata 1.2Ubuntu 18 自带的 mdadm 3.3 是支持的但如果是 DSM 7.x 的某些新格式可能需要升级 mdadm 到 4.x。# 手动指定成员盘组装只读强制 sudo mdadm --assemble --readonly --force /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd14.2 现象LVM 卷组显示 inactivevgchange -ay报错原因一般是 LVM 元数据里的 PV UUID 和实际设备不匹配或者群晖在 LVM 层加了额外的标签。Ubuntu 的 LVM 默认会跳过带foreign标签的卷组。解决用pvdisplay和vgdisplay看详细状态如果 PV 显示unknown device说明 LVM 缓存的设备路径和当前不一致先pvscan --cache刷新再vgchange -ay。如果提示Cannot activate while foreign加--config参数强制激活。# 刷新 LVM 缓存 sudo pvscan --cache sudo vgscan --cache # 强制激活外来卷组 sudo vgchange -ay --config global { foreign 1 } vg14.3 现象Btrfs 挂载报wrong fs type或bad option原因是内核模块没加载或者挂载参数里写了 Ubuntu 18 不支持的选项比如compresszstd在 18.04 的 4.15 内核里默认没有 zstd 支持群晖 DSM 7 可能用了 zstd 压缩。解决先modprobe btrfs加载模块然后检查/proc/filesystems里有没有 btrfs。如果确认是压缩算法不支持挂载时加compressno或者compress-forceno跳过压缩只读模式下不写回压缩选项不影响读取。# 加载 btrfs 模块 sudo modprobe btrfs # 确认内核支持 grep btrfs /proc/filesystems # 挂载时禁用压缩 sudo mount -o ro,compressno,subvolid258 /dev/vg1/lv /mnt/synology4.4 现象rsync 拷贝到一半报Input/output error中断原因是源盘有坏道Btrfs 在读取时触发 I/O 错误rsync 默认会退出。如果阵列是 RAID5 或 RAID1单块盘坏道不一定丢数据但内核可能因为重试超时把整块盘踢出阵列。解决先用btrfs device stats确认哪块盘有错误然后用ddrescue对坏道盘做镜像再从镜像里读数据。如果阵列还在用 rsync 的--ignore-errors跳过坏文件拷完后单独处理。注意不要在有坏道的情况下对阵列做 scrub 或 balance那会加重负载。# 用 ddrescue 对坏道盘做镜像-n 跳过已拷贝部分-r 重试次数 sudo ddrescue -n -r 3 /dev/sdb /mnt/backup/sdb.img /mnt/backup/sdb.log # 从镜像里挂载阵列需要 loop 设备 sudo losetup -fP /mnt/backup/sdb.img sudo mdadm --assemble --readonly /dev/md0 /dev/loop0p14.5 现象挂载后ls看不到数据只有或/volume1目录原因是群晖的 Btrfs 用了子卷布局顶层卷不是数据根。很多人第一次挂载看到空目录就以为数据丢了其实数据在子卷里。解决用btrfs subvolume list列出所有子卷找到path里带volume1或的那个用subvolid重新挂载。如果子卷列表也看不到可能是 Btrfs 元数据损坏用btrfs rescue super-recover尝试恢复超级块。# 列出子卷 sudo btrfs subvolume list /mnt/synology # 如果子卷列表报错尝试恢复超级块 sudo btrfs rescue super-recover /dev/vg1/lv5. 进阶技巧从只读挂载到数据校验的完整闭环数据拷出来只是第一步怎么确认拷出来的和原盘一致、怎么处理群晖特有的 ACL 和快照、怎么在 Ubuntu 18 上长期维护这套恢复环境才是真正省心的地方。我一般会在拷贝完成后做三件事校验文件数量、校验关键文件哈希、把整个恢复流程脚本化。5.1 用哈希清单做端到端校验rsync 自带的-c参数可以基于校验和比对但对大容量数据太慢。更实际的做法是先在源端生成文件清单和哈希再在目标端比对。群晖的 Btrfs 支持btrfs filesystem du和btrfs subvolume find-new但最通用的还是find加sha256sum。# 在源端生成哈希清单排除快照和临时文件 cd /mnt/synology sudo find . -type f -not -path ./* -not -path ./.snapshot* -exec sha256sum {} \; /mnt/backup/source_hashes.txt # 在目标端校验 cd /mnt/backup/synology_data sha256sum -c /mnt/backup/source_hashes.txt --quiet--quiet只输出校验失败的行如果没有任何输出说明全部一致。注意群晖的和.snapshot目录是系统快照不需要拷排除掉能省不少时间。5.2 处理群晖 ACL 和特殊权限群晖的共享文件夹默认带 Windows ACLUbuntu 挂载后ls -l可能看到号表示有扩展属性。rsync 的-a会保留基本权限但 ACL 需要额外加-Axattr 加-X。如果目标盘是 ext4还要确认挂载时启用了acl和user_xattr。# 带 ACL 和 xattr 的 rsync sudo rsync -aHAXv --ignore-errors --partial /mnt/synology/ /mnt/backup/synology_data/ # 检查目标盘挂载参数是否支持 ACL mount | grep /mnt/backup如果目标盘挂载参数里没有acl重新挂载时加上sudo mount -o remount,acl /mnt/backup。ACL 在跨文件系统拷贝时经常丢如果恢复后要重新共享可能需要手动重建权限。5.3 把恢复流程写成可复用脚本这套流程步骤多每次手动敲容易漏。我习惯写一个recover_synology.sh把阵列组装、LVM 激活、子卷挂载、rsync 拷贝串起来关键步骤加set -e和日志输出。这样下次再遇到类似情况改改变量就能跑。#!/bin/bash # recover_synology.sh - 群晖数据恢复脚本 set -euo pipefail LOG/var/log/synology_recover.log exec (tee -a $LOG) 21 echo [$(date)] 开始组装阵列... sudo mdadm --assemble --scan --readonly echo [$(date)] 激活 LVM... sudo vgchange -ay vg1 echo [$(date)] 挂载 Btrfs 子卷... sudo mkdir -p /mnt/synology sudo mount -o ro,subvolid258 /dev/vg1/lv /mnt/synology echo [$(date)] 开始 rsync 拷贝... sudo rsync -aHAXv --ignore-errors --partial /mnt/synology/ /mnt/backup/synology_data/ echo [$(date)] 拷贝完成生成哈希清单... cd /mnt/backup/synology_data sudo find . -type f -exec sha256sum {} \; /mnt/backup/target_hashes.txt echo [$(date)] 全部完成请手动核对哈希清单。脚本里set -euo pipefail保证任何一步失败就停避免在阵列没起来的情况下继续挂载。日志用tee同时输出到屏幕和文件方便事后排查。最后生成的哈希清单可以跟源端比对确认数据完整。从那以后我每次做数据恢复都强制先只读挂载、再生成哈希清单、最后才拷贝绝不跳过校验这一步。希望帮到你。本文还有配套的精品资源点击获取