企业官网建设流程全解析

简介：面向群晖NAS非RAID硬盘损坏场景，这份代码包以Ubuntu 18系统为操作环境，为开发、运维人员提供一套可参照的数据恢复方案。内容围绕外接硬盘挂载、安装必要依赖、使用rsync断点续传与分批拷贝、以及通过DU与DIFF命令校验数据完整性等核心环节，适合已掌握基础Linux命令、需要自行处理NAS故障恢复的读者。zip包内共含3个文件，包括一份HTML格式说明页、一个inscode代码文件以及一个Git忽略规则文件，整体仅6KB，结构精简，便于快速查看与复用。当前已有205人浏览学习，特别适用于群晖DS设备在未启用RAID冗余时，尝试直接读取EXT4或Btrfs分区数据的情况。借助这份小巧资源，读者可快速理解恢复流程的核心思路，掌握rsync应对中断与损坏文件的处理技巧，并在实际操作中有效降低二次数据丢失的风险。 如果你的群晖NAS突然开不了机，DSM系统分区报错，或者你只是想把旧机器里的数据盘拆出来，放到一台普通电脑上把资料抢救出来——这套Ubuntu 18下的恢复流程，基本是我接手这类问题时的标准动作。

这里说的“代码”，并不是什么神奇的数据恢复软件，而是一串在Ubuntu终端里执行的命令。群晖的硬盘本身是Linux文件系统格式，Windows插上去认不到，但只要用对Linux下的底层工具（mdadm、lvm2、btrfs-progs），完全可以手动把群晖的存储结构组装起来，再把里面的数据一点点拷出来。整个过程不需要额外购买恢复服务，一台装了Ubuntu 18的普通主机就能搞定。

我下面会按照实际操作的顺序，从群晖的数据排布原理讲到最后的文件导出，把这套流程完整走一遍。适合遇到NAS故障需要自救的人，也适合从来没碰过Linux存储命令、但想搞清楚原理的新手。

1. 恢复前先把群晖的数据排布搞清楚

1.1 群晖的数据其实就躺在四个分区里

群晖的数据盘拿下来接到任何一台Linux设备上，都会显示出一块标准GPT布局的硬盘。用fdisk看，最典型的是四个分区：

• /dev/sda1：EFI系统分区，厂商用来引导的，FAT文件系统
• /dev/sda2：DSM系统分区，装了操作系统内核和套件
• /dev/sda3：数据分区，占了整块盘绝大部分空间，我们的用户数据全在这里
• /dev/sda4：交换分区，Linux swap

这里最关键的是第三个分区。单盘Basic卷的场景下，用户数据就直接放在这个分区上；多盘RAID场景下，这块盘的第3分区只是阵列里的一个成员盘，和另外几块盘的第3分区一起组成一个md设备。所以“恢复数据”本质上是两件事：把RAID重新组装起来，再把文件系统挂载上。

1.2 SHR与RAID在底层就是mdadm

提到群晖，很多人会想到SHR（Synology Hybrid RAID）。其实SHR这套东西在底层并没有脱离Linux标准体系——它用的就是内核里的md模块，也就是mdadm工具管理的软件RAID。SHR-1相当于RAID 5或子设备的动态负载均衡，SHR-2相当于RAID 6，只是群晖在磁盘容量分配上做了自己的调度算法，让不同容量的盘都能用起来。

这意味着什么？意味着你完全可以用Ubuntu自带的mdadm去识别和重组群晖的阵列。群晖在创建阵列时，会往每个成员盘上写入md超级块（metadata），版本是1.1。超级块里记录了这个阵列是RAID几、有几个成员、成员ID是多少、阵列UUID是多少。只要这些信息还在，Linux的mdadm就能把它们重新组合成一个/dev/md设备。这就是整套恢复方案的底层依据。

1.3 恢复前先做这几件事

在没有开始敲任何命令之前，有几步准备工作很有必要，能避免二次损坏：

1. 记住原NAS的盘位顺序，拍照记录。虽然md超级块会记录阵列信息，但盘序信息在多盘丢失时还是有用的。
2. 断开原NAS的电源，避免它反复尝试启动把数据写坏。
3. 有条件可以先对每块盘做整盘镜像，尤其如果你担心盘本身有坏道。dd或者ddrescue都可以，镜像后再在镜像上操作。
4. 准备一台至少有两个空闲SATA接口的机器（多盘阵列需要），装好Ubuntu 18系统，并确保能联网安装工具。

2. Ubuntu环境准备与硬盘识别

2.1 这次要用到的工具就这几样

Ubuntu 18默认装在机器上，缺少的只是几个存储管理工具。一条命令装齐：

sudo apt update sudo apt install -y mdadm lvm2 btrfs-progs xfsprogs

mdadm管理软件RAID；lvm2是卷管理工具，群晖的大多数阵列都会包一层LVM；btrfs-progs用来处理新版本DSM默认的btrfs文件系统；xfsprogs备上，万一遇到老版本用的XFS（不常见，但磁盘格式化选项里可以选）。Ubuntu 18仓库里全都有，装完用mdadm --version确认一下版本，4.1版本对群晖的metadata 1.1支持很成熟。

2.2 用lsblk看清楚每块盘的归处

把群晖的硬盘插到Ubuntu机器的SATA口，开机进入系统，先用lsblk确认一下盘符：

lsblk

输出大概是这样的：

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 2.4G 0 part ├─sda2 8:2 0 2.4G 0 part ├─sda3 8:3 0 455.9G 0 part └─sda4 8:4 0 5.1G 0 part sdb 8:16 0 3.7T 0 disk ├─sdb1 8:17 0 2.4G 0 part ├─sdb2 8:18 0 2.4G 0 part ├─sdb3 8:19 0 3.6T 0 part └─sdb4 8:20 0 5.1G 0 part

两块群晖盘都插上后，能看到完全相同的分区结构。sda3和sdb3就是我们要关心的RAID成员分区。注意，Ubuntu系统本身也有自己的盘，千万不要把系统盘和数据盘搞混，最好用容量和分区结构双重确认。

2.3 用mdadm检查阵列还在不在

这一步能看出分区上有没有md超级块：

sudo mdadm --examine /dev/sda3 /dev/sdb3

如果输出里有类似这样的内容，说明这个分区确实是软件RAID的成员：

/dev/sda3: Magic : a92b4efc Version : 1.1 Feature Map : 0x0 Array UUID : 3f1f6a4c:f2e0b7d9:1c4a6e8b:9d2a5c7e Name : NAS:1 Creation Time : Thu Jul 13 22:15:42 2022 Raid Level : raid1 Raid Devices : 2

看到Magic a92b4efc是关键，这是Linux md超级块的魔数，表示这块分区确实是一个软件RAID的成员。Raid Level提示了阵列拓扑，Raid Devices是成员数量。两个分区的Array UUID必须一致，才说明它们是同一个阵列的成员，这一步是后续手工装配的重要依据。

如果只有一块盘，mdadm会提示它是degraded状态，也可以识别。如果--examine直接说没有RAID信息，那很可能这是一个单盘Basic卷，不需要重组RAID，直接把文件系统挂载到sda3上即可。

3. 主菜：用mdadm重组RAID并挂载群晖卷

3.1 先试自动装配，运气好一步到位

最简单的路径，是让mdadm自动扫描并装配：

sudo mdadm --assemble --scan

如果运气够好，mdadm会自动把所有成员盘拼成一个md设备。完成后用cat /proc/mdstat查看阵列状态：

Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [raid0] [raid10] md127 : active raid1 sda3[0] sdb3[1] 3906889536 blocks super 1.1 [2/2] [UU]

看到[UU]表示两个成员都上线，阵列状态是健康的。md设备名通常是md127，出现在/dev下。到这里，最困难的一步已经过了。

3.2 手动装配：盘序乱了靠UUID说话

自动装配失败时，一般报错是mdadm: No arrays found in config file or automatically，意思是它没有自动识别到数组。原因可能是盘序变了，或者mdadm.conf里没有注册。没关系，我们可以手动把成员盘喂给它：

sudo mdadm --stop /dev/md127 sudo mdadm --assemble /dev/md127 /dev/sda3 /dev/sdb3

这个过程中，mdadm仍然会通过超级块里的Array UUID去校验，所以成员盘顺序不要求严格一致，它会自己排好。比如两块盘插反了，也不影响，mdadm看到同一个UUID就会把它们归到同一个阵列里。

如果这里报错说只有部分成员，而你又确认所有盘都已接入，可以尝试强制装配：

sudo mdadm --assemble --force /dev/md127 /dev/sda3 /dev/sdb3

注意，--force在缺失一块盘的情况下会强制降级装配，这通常没问题。但如果你怀疑某个盘可能损坏，最好先看dmesg有没有磁盘I/O错误，再决定是否强制。多盘RAID5/RAID6的场景尤其要注意这一点，强制装配前最好确认没有盘离线。

3.3 LVM激活与文件系统挂载

群晖的绝大多数多盘卷，在RAID之上还套了一层LVM。RAID重组成功之后，系统里还看不到可直接挂载的文件系统，得先把LVM激活。依次执行：

sudo pvscan sudo vgscan sudo lvscan sudo vgchange -ay

pvscan是扫描物理卷，群晖的卷组名通常是synology、vg1、vg2之类；vgscan扫描卷组；lvscan能列出逻辑卷，比如/dev/synology_vg/volume_1。vgchange -ay把卷组激活，激活后系统里会生成对应的设备节点。

然后挂载：

sudo mkdir /mnt/syno sudo mount -o ro /dev/synology_vg/volume_1 /mnt/syno

挂载时加-o ro只读，这是我一直坚持的恢复原则。挂载完成后，ls /mnt/syno应该能看到熟悉的home、共享文件夹结构。

如果文件系统是btrfs，有些版本需要先跑一下设备扫描：

sudo btrfs device scan sudo mount -t btrfs /dev/synology_vg/volume_1 /mnt/syno

如果不确定文件系统类型，可以用blkid查：

blkid /dev/synology_vg/volume_1

输出里的TYPE字段会告诉你到底是btrfs还是ext4，再选择对应挂载方式。

3.4 把数据取出来才是最终目标

挂载只是第一步，最重要的是把数据复制到安全的地方。我一般用rsync，断点续传、进度可视化都方便：

sudo rsync -av --progress /mnt/syno/ /home/username/recovered_data/

如果想保留权限和符号链接，加-A -X -H参数。数据量非常大时，建议用screen或tmux跑rsync，防止终端断开会话被中断。这一步也是只读源目录、只写目标目录，不会对原盘造成任何改动。

如果整个磁盘只有一块盘且是Basic卷，不需要经过RAID和LVM，直接挂载sda3：

sudo mount -o ro /dev/sda3 /mnt/syno

这种方式反而更简单，很多4盘位NAS用户其实开了多个Basic卷，单盘插到Ubuntu上一样能直接读。

4. 恢复过程中最容易踩的坑

4.1 问题排查速查表

我在实际恢复里遇到过的典型问题，整理成了一张表，基本能覆盖大部分情况：

4.2 几个必须记住的操作原则

原则一：恢复期间原盘只读。不要贸然执行mkfs，不要顺手fsck，更不要在确认数据完整前让系统自动挂载可写，任何写操作都有风险。

原则二：不要在未确认的情况下乱顺序。虽然md超级块能纠正顺序，但如果两块盘都报相同的Array UUID，理论上顺序不重要。但如果盘太多，还是按原顺序插入最稳。多盘RAID5/RAID6尤其要小心。

原则三：数据备份优先于恢复。如果数据量大，先复制关键目录，再慢慢拷其他内容，不要总想着先把所有东西一次性备份出来。

原则四：Ubuntu 18的mdadm版本对群晖的metadata 1.1支持良好，没必要为了这次恢复去升级到22.04或换系统。换系统反而可能引入新的引导和驱动问题，多一事不如少一事。

4.3 关于恢复过程中被问得最多的几个衍生问题

经常有人问，群晖系统出过问题之后，盘里的数据是否安全，会不会带着恶意程序。这里可以明确说：在Linux环境下挂载读取，只是把文件系统暴露出来拷贝数据，不会执行NAS里的程序文件，所以风险很小。数据拷出来之后，如果打算重新放回群晖，建议先对关键目录做一次扫描再启用。

还有人问，Jellyfin替代方案、群晖升级到DSM 7甚至22.04这类问题。我的建议是，恢复完成之前不要动系统升级的念头，先把数据拿到手，这是整个流程里最耗费耐心、也最不能将就的部分。

最后说点个人体会。我做过几次群晖盘的恢复，最大的感受是：群晖的存储层没有做封闭的私有格式，SHR在底层就是标准的mdadm加上LVM，这给了普通用户一条非常实用的自救通道。整个过程真正危险的不是命令，而是冲动——急着挂载、急着写盘、急着跑fsck，往往会让原本能恢复的数据面临额外风险。如果时间充裕，先镜像再操作永远是最稳的选择。

另外一个小技巧是，恢复完成后，记得把所有关键步骤和当时的lsblk、mdadm --examine输出都截个图或保存成文本。下次如果又遇到类似问题，这些记录比任何教程都管用。希望这篇文章能帮你把群晖里的数据顺利接回家。

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