群晖NAS数据恢复实战：Ubuntu下用mdadm和LVM抢救数据

简介面向群晖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/sda1EFI系统分区厂商用来引导的FAT文件系统/dev/sda2DSM系统分区装了操作系统内核和套件/dev/sda3数据分区占了整块盘绝大部分空间我们的用户数据全在这里/dev/sda4交换分区Linux swap这里最关键的是第三个分区。单盘Basic卷的场景下用户数据就直接放在这个分区上多盘RAID场景下这块盘的第3分区只是阵列里的一个成员盘和另外几块盘的第3分区一起组成一个md设备。所以“恢复数据”本质上是两件事把RAID重新组装起来再把文件系统挂载上。1.2 SHR与RAID在底层就是mdadm提到群晖很多人会想到SHRSynology 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 恢复前先做这几件事在没有开始敲任何命令之前有几步准备工作很有必要能避免二次损坏记住原NAS的盘位顺序拍照记录。虽然md超级块会记录阵列信息但盘序信息在多盘丢失时还是有用的。断开原NAS的电源避免它反复尝试启动把数据写坏。有条件可以先对每块盘做整盘镜像尤其如果你担心盘本身有坏道。dd或者ddrescue都可以镜像后再在镜像上操作。准备一台至少有两个空闲SATA接口的机器多盘阵列需要装好Ubuntu 18系统并确保能联网安装工具。2. Ubuntu环境准备与硬盘识别2.1 这次要用到的工具就这几样Ubuntu 18默认装在机器上缺少的只是几个存储管理工具。一条命令装齐sudo apt update sudo apt install -y mdadm lvm2 btrfs-progs xfsprogsmdadm管理软件RAIDlvm2是卷管理工具群晖的大多数阵列都会包一层LVMbtrfs-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 -aypvscan是扫描物理卷群晖的卷组名通常是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直接挂载sda3sudo mount -o ro /dev/sda3 /mnt/syno这种方式反而更简单很多4盘位NAS用户其实开了多个Basic卷单盘插到Ubuntu上一样能直接读。4. 恢复过程中最容易踩的坑4.1 问题排查速查表我在实际恢复里遇到过的典型问题整理成了一张表基本能覆盖大部分情况现象原因处理方式mdadm: No arrays found in config file没在mdadm.conf里注册自动扫描未发现手动指定成员盘assemble--examine认不到分区该分区可能是Basic卷没建RAID直接尝试挂载sda3mount报wrong fs type没激活LVM或文件系统类型不对先vgscan/vgchange再mount用blkid确认类型lvscan看不到逻辑卷卷组未激活vgchange -ay手动激活btrfs挂载报错btrfs-progs版本过旧升级工具包后重跑btrfs device scan文件系统提示dirty上次异常断电先以只读挂载必要时才做只读检查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输出都截个图或保存成文本。下次如果又遇到类似问题这些记录比任何教程都管用。希望这篇文章能帮你把群晖里的数据顺利接回家。本文还有配套的精品资源点击获取