企业官网建设流程全解析

简介：这份资源面向需要在群晖NAS故障后抢救数据的运维人员与进阶用户，提供一套基于Ubuntu 18的USB外接恢复思路与配套代码。适用于非RAID配置的群晖DS设备，硬盘文件系统为EXT4或Btrfs的场景，帮助读者在NAS无法启动时仍能读取并转移重要数据。压缩包共3个文件，包含1个inscode工程配置、1个html说明页面与1个gitignore文件，整体仅6KB，轻量易取用。资源围绕挂载损坏NAS硬盘、安装依赖、使用rsync断点续传与分批传输、再以DU和DIFF校验数据一致性等关键环节展开，代码与说明可直接对照操作，降低恢复门槛。目前已有217人学习，适合希望掌握群晖数据恢复流程、需要可复用脚本与排错思路的技术人员参考。

1. Ubuntu18 挂载群晖 NAS 硬盘：为什么直接插上电脑读不出数据

群晖 NAS 用久了，最怕的不是硬盘坏，而是机器先坏。主板烧了、电源挂了、DSM 崩了进不去系统，硬盘本身却是好的——这种场景在 DIY NAS 和老旧群晖机型上太常见了。很多人第一反应是把硬盘拔下来插到 Ubuntu 电脑上，结果发现文件管理器里根本看不到盘，fdisk -l能看到设备但挂不上，于是开始慌。其实群晖用的是 Linux 的 mdadm 软 RAID 加 LVM 再加 Btrfs 或 ext4 的组合，Ubuntu18 本身完全有能力读它，只是需要手动按顺序把 RAID 阵列、LVM 卷组、逻辑卷一层层激活。这篇就是讲清楚在 Ubuntu18 上恢复群晖 NAS 数据的完整路径：从识别硬盘、组装阵列、激活 LVM，到最终挂载读取，以及哪些操作会把数据彻底搞没。适合手里有群晖硬盘、机器已经开不了机、又不想花大价钱找数据恢复的人。

2. 先搞清楚群晖硬盘的分区结构和 RAID 类型

2.1 群晖 DSM 在硬盘上到底写了什么

把群晖硬盘插到 Ubuntu 机器上，第一件事不是急着挂载，而是先看清楚分区布局。群晖每块盘的分区结构大致是这样的：前面有几个小分区，分别是 2GB 左右的系统分区（md0）、2GB 的交换分区（md1），后面才是占满剩余空间的数据分区（md2）。系统分区在每个盘上都有副本，做 RAID1；数据分区根据你当初选的 RAID 类型，可能是 RAID1、RAID5、RAID6、SHR 或者 Basic。SHR 是群晖自己的东西，底层还是 mdadm RAID 加 LVM，只是组合方式特殊。

用lsblk和fdisk -l先看设备名和分区情况：

# 查看所有块设备，确认群晖硬盘的设备名 lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT # 查看具体分区表，假设硬盘是 /dev/sdb /dev/sdc /dev/sdd /dev/sde sudo fdisk -l /dev/sdb

输出里你会看到类似/dev/sdb1、/dev/sdb2、/dev/sdb5这样的分区。群晖的分区编号有时候不连续，这是正常的，因为 DSM 用的是 GPT 分区表加自定义布局。关键要确认的是：数据分区通常是最大的那个，文件系统类型显示为linux_raid_member，说明它是 RAID 成员盘。

注意：这一步只读不写，不要对硬盘做任何格式化或分区操作。一旦写入，RAID 元数据可能被覆盖，恢复难度直接翻倍。

2.2 判断你的群晖用的是哪种 RAID 和文件系统

群晖的数据分区底层是 mdadm RAID，上面可能直接是 ext4，也可能再套一层 LVM 然后是 Btrfs。判断方法很简单，先看 RAID 成员：

# 扫描所有 RAID 成员盘，不组装，只看信息 sudo mdadm --examine /dev/sdb5 sudo mdadm --examine /dev/sdc5 sudo mdadm --examine /dev/sdd5

输出里重点看几个字段：Raid Level告诉你这是 RAID1 还是 RAID5，Array UUID确认这几块盘是不是同一个阵列，Device Role告诉你每块盘在阵列里的位置。如果Raid Level显示raid5，那至少需要三块盘才能组装；raid1两块就行；raid6至少四块。

如果mdadm --examine的输出里看到Member Device或者Container之类的字段，说明上面还有 LVM。这时候先别急着组装，把信息记下来，后面按顺序来。

常见组合我列个表，方便对照：

SHR 的情况稍微复杂一点，它可能把不同容量的盘组合成多个 RAID 再套 LVM，但恢复思路是一样的：先组 RAID，再激活 LVM，最后挂载。

3. 在 Ubuntu18 上组装 RAID 并激活 LVM 的完整命令

3.1 安装必要工具并扫描所有阵列

Ubuntu18 默认可能没装 mdadm 和 lvm2，先补上：

sudo apt update sudo apt install mdadm lvm2 -y

装完之后，先让系统自动扫描一下现有的 RAID 阵列：

# 扫描所有块设备上的 RAID 元数据 sudo mdadm --assemble --scan --verbose

这个命令会尝试自动组装所有能识别的阵列。如果成功，你会看到/dev/md0、/dev/md1、/dev/md2这样的设备出现。但自动组装有时候会失败，尤其是 SHR 或者阵列顺序乱了的情况，所以更稳妥的方式是手动指定成员盘组装。

手动组装数据阵列，假设数据分区是/dev/sdb5、/dev/sdc5、/dev/sdd5，RAID5：

# 手动组装 RAID5，指定三块成员盘 sudo mdadm --assemble /dev/md2 /dev/sdb5 /dev/sdc5 /dev/sdd5 # 查看组装结果 cat /proc/mdstat

/proc/mdstat里会显示阵列状态，[UUU]表示三块盘都在线，[U_U]表示有一块盘掉了。如果显示active且没有degraded，说明组装成功。

注意：如果mdadm --assemble报错说device or resource busy，可能是 Ubuntu 自动挂载了某个分区，先umount掉再试。如果报no such device，检查设备名有没有写错。

3.2 激活 LVM 并找到数据逻辑卷

RAID 组装好之后，如果群晖用了 LVM，/dev/md2上面不会直接是文件系统，而是 PV（物理卷）。用pvs、vgs、lvs三层查看：

# 扫描物理卷 sudo pvs # 扫描卷组 sudo vgs # 扫描逻辑卷 sudo lvs

如果pvs能看到/dev/md2，但vgs是空的，说明卷组还没激活：

# 激活所有卷组 sudo vgchange -ay # 再次查看逻辑卷 sudo lvs

这时候应该能看到类似vg1/lv或者volume_1/volume_1这样的逻辑卷。群晖的卷组名通常是vg1或者volume_1，逻辑卷名一般是lv或者volume_1。记下逻辑卷的路径，比如/dev/vg1/lv，下一步挂载要用。

如果pvs里根本看不到/dev/md2，说明 RAID 没组装成功，回到上一步检查mdadm --examine的输出，确认成员盘有没有漏掉或者顺序错了。

3.3 挂载逻辑卷并验证数据完整性

找到逻辑卷之后，先别急着挂载，用blkid确认文件系统类型：

# 查看逻辑卷的文件系统类型 sudo blkid /dev/vg1/lv

输出里TYPE="ext4"或者TYPE="btrfs"。如果是 ext4，直接挂载；如果是 Btrfs，Ubuntu18 默认支持，但建议装一下btrfs-progs：

# 安装 Btrfs 工具 sudo apt install btrfs-progs -y # 创建挂载点 sudo mkdir -p /mnt/synology # 挂载 ext4 逻辑卷 sudo mount -o ro /dev/vg1/lv /mnt/synology # 如果是 Btrfs，挂载命令一样，但建议加恢复选项 sudo mount -o ro,recovery /dev/vg1/lv /mnt/synology

注意这里用了-o ro，只读挂载。这是血泪经验：恢复数据的时候，第一遍一定要只读挂载，确认数据完整之后再考虑读写。只读挂载不会修改文件系统，即使有问题也不会让情况变得更糟。

挂载成功后，ls /mnt/synology应该能看到群晖的共享文件夹，比如homes、photo、video这些。如果看到的是空目录或者报input/output error，可能是文件系统有损坏，需要先修复。

4. 恢复过程中最容易翻车的五个坑

4.1 坑一：Ubuntu 自动挂载了 RAID 成员盘导致阵列无法组装

现象：执行mdadm --assemble时报device or resource busy，或者/proc/mdstat里阵列状态是inactive。

原因：Ubuntu 桌面版会自动挂载它能识别的文件系统。群晖的每个 RAID 成员盘上都有系统分区，Ubuntu 可能把这些分区挂到了/media下面，导致 mdadm 无法独占设备。

解决：先卸载所有自动挂载的分区：

# 查看当前挂载了哪些群晖相关的分区 mount | grep sd # 逐个卸载，假设是 /dev/sdb1 /dev/sdc1 等 sudo umount /dev/sdb1 sudo umount /dev/sdc1 # 再重新组装 RAID sudo mdadm --assemble /dev/md2 /dev/sdb5 /dev/sdc5 /dev/sdd5

如果umount报target is busy，用lsof看看谁在占用，或者直接sudo umount -l强制卸载。

4.2 坑二：SHR 阵列直接按 RAID5 组装导致失败

现象：mdadm --examine显示Raid Level是raid5，但按 RAID5 组装后/proc/mdstat显示degraded，或者根本组不起来。

原因：SHR 底层可能把不同容量的盘分成多个 RAID 区域，直接按 RAID5 组装会漏掉某些成员盘或者顺序不对。

解决：先用mdadm --examine把所有盘的Array UUID和Device Role都看一遍，确认哪些盘属于同一个阵列。SHR 的情况下，可能需要分多次组装不同的 md 设备，然后再用 LVM 把它们串起来。如果搞不定，可以用mdadm --assemble --scan让系统自动尝试，成功率比手动高。

4.3 坑三：LVM 卷组同名冲突导致激活失败

现象：vgchange -ay报错Duplicate VG name，或者激活后lvs看不到逻辑卷。

原因：Ubuntu 系统本身可能已经有一个叫vg1或者ubuntu-vg的卷组，和群晖的卷组重名了。

解决：先查看所有卷组：

sudo vgs

如果看到两个同名的，用 UUID 区分：

# 查看卷组 UUID sudo vgs -o vg_name,vg_uuid # 用 UUID 激活指定卷组 sudo vgchange -ay --select vg_uuid=你的群晖卷组UUID

或者临时把 Ubuntu 自己的卷组改名，避免冲突。

4.4 坑四：Btrfs 文件系统挂载后报 I/O 错误

现象：mount成功，但ls的时候报input/output error，或者只能看到部分目录。

原因：Btrfs 文件系统可能有元数据损坏，或者 RAID 组装不完整导致数据不一致。

解决：先用只读加恢复模式挂载：

sudo mount -o ro,recovery /dev/vg1/lv /mnt/synology

如果还是不行，用btrfs check检查：

# 只读检查，不要加 --repair sudo btrfs check --readonly /dev/vg1/lv

btrfs check的输出会告诉你哪里有问题。如果只是少量元数据损坏，可以尝试--repair，但一定要先备份重要数据。如果损坏严重，建议找专业数据恢复，不要自己反复折腾。

4.5 坑五：RAID 重建过程中断电导致数据彻底丢失

现象：组装 RAID 后系统提示resync或recovery进行中，这时候断电或者强制关机，再开机阵列直接failed。

原因：mdadm 在组装 RAID 时可能会触发重建，重建过程中写入元数据，如果中断，元数据可能不一致，导致阵列无法再次组装。

解决：组装 RAID 时加--readonly参数，避免任何写入：

sudo mdadm --assemble --readonly /dev/md2 /dev/sdb5 /dev/sdc5 /dev/sdd5

只读组装不会触发重建，也不会修改元数据，是最安全的恢复方式。如果已经触发了重建，耐心等它完成，期间不要断电。如果重建卡住，可以尝试echo idle > /sys/block/md2/md/sync_action暂停，但不要直接拔盘。

5. 用 ddrescue 做全盘镜像再恢复的稳妥做法

如果你觉得直接操作原盘风险太大，或者数据特别重要，我一般会建议先做全盘镜像，然后在镜像上做恢复。这样即使操作失误，原盘数据还在。工具用ddrescue，Ubuntu18 装一下：

sudo apt install gddrescue -y

假设群晖数据盘是/dev/sdb，准备一块容量不小于它的空盘挂到/mnt/backup，然后：

# 做全盘镜像，-n 跳过坏道快速拷贝，-r 重试次数 sudo ddrescue -n /dev/sdb /mnt/backup/synology_disk1.img /mnt/backup/disk1.log # 如果第一次有坏道，再跑一次精细拷贝 sudo ddrescue -r 3 /dev/sdb /mnt/backup/synology_disk1.img /mnt/backup/disk1.log

镜像做完之后，用losetup把镜像挂成回环设备，再按前面的步骤组装 RAID：

# 把镜像文件关联到 loop 设备 sudo losetup -fP /mnt/backup/synology_disk1.img # 查看关联结果，假设是 /dev/loop0 lsblk /dev/loop0 # 然后按前面的步骤组装 RAID，成员盘换成 /dev/loop0p5 这样的 sudo mdadm --assemble --readonly /dev/md2 /dev/loop0p5 /dev/loop1p5 /dev/loop2p5

这样做的好处是所有操作都在镜像上，原盘完全不动。坏处是需要额外的存储空间，而且速度慢一些。但对于重要数据来说，这点代价完全值得。

最后说一个我自己的习惯：每次做这种恢复，我都会在旁边开一个终端跑watch -n 2 cat /proc/mdstat，实时盯着阵列状态。一旦看到degraded或者failed，立刻停下来检查，不要心存侥幸继续操作。数据恢复这件事，慢就是快，稳就是赢。希望帮到你。

本文还有配套的精品资源，点击获取