企业官网建设流程全解析

简介：这份资源面向需要在群晖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 盘长这样：

• 分区 1：Linux raid autodetect，约 2.4GB，放的是 DSM 系统分区，所有盘互为 RAID1 镜像。
• 分区 2：Linux raid autodetect，约 2GB，交换分区，也是 RAID1。
• 分区 3：Linux raid autodetect，剩余全部空间，数据分区，按你选的 RAID 类型组阵列。

关键点：分区 1 和 2 在所有盘上都是一样的，只有分区 3 才承载你的数据。所以恢复数据时，我们只关心分区 3 组成的那个 md 设备。

先确认盘被系统认到了：

# 查看所有块设备，确认群晖盘是否被识别 lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT # 如果盘没显示，检查是不是被别的控制器挡住了 lsscsi

lsblk的输出里，你会看到类似sdb、sdc、sdd、sde这样的设备，每个下面挂着sdb1、sdb2、sdb3。如果 FSTYPE 列显示linux_raid_member，说明分区类型正确。

2.2 判断是 RAID1、RAID5 还是 SHR

这一步决定了后面组装阵列的命令。群晖的 SHR（Synology Hybrid RAID）底层其实也是 mdadm，只是元数据里多了一层标记。判断方法：

# 查看每个分区的 RAID 元数据 mdadm --examine /dev/sdb3 mdadm --examine /dev/sdc3

输出里重点看几个字段：

• Level：raid1 表示镜像，raid5 表示带校验的条带。
• Devices：阵列里成员盘的数量。
• Array UUID：同一个阵列的 UUID 必须一致。
• State：clean 或 active，如果是 clean 说明阵列是正常关闭的。

如果Level显示raid5，但Devices是 4，而你只插了 3 块盘，那阵列是降级状态，能读但没冗余。如果Level显示raid1，那最简单，单块盘就能直接读。

提示：SHR 在mdadm --examine里可能显示为 raid5 或 raid1，具体取决于你当初建了几个盘。SHR-1 在 3 盘以上时底层是 raid5，2 盘时是 raid1。

3. 在 Ubuntu18 上组装 mdadm 阵列并挂载 LVM

3.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 -ay

vgchange -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只读挂载。这是血泪经验：只读挂载能防止任何意外写入，比如系统自动生成lost+found或者你手滑删了东西。确认数据没问题之后，再决定要不要重新挂载为读写。

挂上后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/sdd3

4.2 现象：vgchange -ay执行后lvs还是空的

原因：LVM 的元数据可能因为群晖的版本差异没有被正确识别，或者卷组处于 exported 状态。

解决：强制导入卷组：

# 查看卷组状态 sudo vgdisplay # 如果显示 exported，导入它 sudo vgimport vg1000 # 再激活 sudo vgchange -ay vg1000

4.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/lv

4.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 激活步骤记在一个文本文件里，和硬盘放在一起。下次再遇到同样的情况，不用重新查资料，直接照着敲就行。这个习惯帮我省过好几次事。

希望帮到你。

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