简介面向Synology NAS非RAID配置设备的数据恢复场景这份代码资源提供一套基于Ubuntu 18系统的硬盘救援操作方案适合具备Linux基础、需要自行处理群晖故障硬盘的运维与NAS用户。资源包内共3个文件包含可直观查看步骤的HTML说明页面、便于在线运行的InsCode配置以及用于版本管理的Git忽略规则文件压缩包仅6KB轻量易用。目前已有205人学习过该资源。内容详细覆盖EXT4/Btrfs文件系统挂载、rsync断点续传与损坏文件处理、分批传输策略以及通过DU和DIFF命令对新旧数据进行完整性校验的方法。整套流程可帮助用户在设备故障时借助USB外接方式安全读取硬盘数据降低传输中断或数据损坏带来的损失并为后续数据迁移与验证提供清晰的操作参考用户可据此快速掌握从硬盘接入到数据校验的完整恢复链路。1. 为啥群晖的硬盘插到Ubuntu上啥也看不见先说盘面结构这问题我太熟了。群晖NAS用着用着系统崩了、引导坏了、或者干脆升级变砖手头又没第二台群晖最自然的想法就是把硬盘拆出来插到一台Ubuntu 18的机器上直接把数据拷走。结果一插上去fdisk -l能看见盘但分区表怪怪的挂载时报错甚至系统里压根不显示这块盘——这不是你操作有问题是群晖的盘面结构本来就和普通Linux台式机的盘不一样。群晖底层用的是Linux但它的盘面上不是简简单单一个ext4分区。以最常见的SHRSynology Hybrid RAID和传统RAID 1/5/6为例一块数据盘的完整结构大致是这样的开头是一小段分区表通常是GPT或者一个带偏移的DOS分区表群晖在里面塞了一个类型为Linux RAID的小分区一般只有2GB左右中间那一整块大分区才是真正的数据区分区类型是Linux RAIDmdadm用来组成RAID阵列在RAID设备之上群晖会再叠一层LVM卷组名默认叫vg1000或vg1里面再分出synology这个逻辑卷最后在逻辑卷上才是实际的文件系统SHR和多数传统RAID是ext4新一点的群晖套件或Btrfs卷是Btrfs。所以你在Ubuntu里看不到数据不是数据没了而是系统不会自动把这套“分区表 - mdraid - LVM - 文件系统”的链路逐层解开。只要手动把这条链路接上数据就能原样读出来。这台机器只需要跑Ubuntu 18、装几个工具剩下的就是分层操作。我用过好几台不同版本的群晖DSM 6和DSM 7虽然在套件中心、UI上差别不小但底层这套“mdadm LVM ext4/btrfs”的结构基本没变过。也就是说下面这套方法不管你是从黑群晖还是白群晖拆下来的盘通用性都很强。2. 动手前的安全边界不是所有情况都适合走这条恢复路线先把丑话说在前面。不是每一块从群晖里拆出来的盘都适合用代码强拧有些场景你越拧越糟下手之前必须判断清楚当前属于哪种损坏等级。适合走手动恢复的典型场景群晖系统引导损坏、NAS系统无法启动、升级失败后无法进入DSM、机器硬件故障但硬盘本身没有物理坏道。这种情况下RAID阵列里的数据基本完整只是缺一个“操作系统壳”来认它手动装配完全可行。必须立刻停手的场景硬盘通电时有明显咔哒声、异响或者被摔过、进过水两块以上盘同时掉线导致RAID信息完全丢失阵列本身还在自动重建过程中就强行断电。前者说明物理层随时会报废你需要的是开盘或专业恢复而不是在Linux里敲命令后者是阵列一致性受损一旦你强制装配损坏范围可能扩大。另外有个原则性的底线从头到尾都只能以只读方式加载阵列和文件系统。也就是装配RAID时用--readonly挂载ext4时用-o ro,noatime。Btrfs挂载时也加-o ro。不要在恢复阶段对原盘做任何写入包括fsck、日志重放、碎片整理这些看似“修复”的操作。逻辑很简单——恢复的第一责任是留活路不是修好任何写操作都可能在损坏的系统状态上覆盖你仅剩的可用数据。还要提醒一个很多人忽略的点如果你手上有多块盘先记录每块盘在NAS机箱里的原位置和盘上SN这一步能省去后面阵列识别顺序的很多麻烦。然后在Ubuntu里用lsblk、blkid逐块确认不要靠猜。3. 核心恢复流程从裸盘到数据可读的完整命令路线开始之前先准备Ubuntu 18的环境。Ubuntu 18自带的软件源里就有mdadm和lvm2不需要额外加源。执行sudo apt update sudo apt install -y mdadm lvm2这两个包就是全部依赖。群晖这套结构恰好是Linux标准工具链能完整覆盖的这也是不用Windows恢复软件的原因——Windows下还得先识别Linux分区多一层麻烦。接下来按顺序操作。假设你只有一块盘设备名是/dev/sdb为例在Ubuntu里确认设备名后一步步来# 1. 查看盘的分区结构 sudo fdisk -l /dev/sdb sudo blkid /dev/sdb*我在实际恢复中经常看到blkid只报出很小的md分区主数据分区有时候不显示这正常。因为主数据分区里的md超级块是后面才有内容前面是空白的blkid不一定识别。不吓人继续往下。# 2. 查看RAID成员信息 sudo mdadm --examine /dev/sdb2这里的/dev/sdb2一般是那个大的Linux RAID分区。如果--examine能读到类似Device /dev/sdb2和Raid Device : 0的信息说明RAID元数据还在。如果提示No super block found先别急可能是分区号不对用fdisk -l看下主分区实际情况也可能群晖把分区表偏移了后面第四节说这个情况。# 3. 尝试自动装配 sudo mdadm --assemble --scan sudo mdadm --detail /dev/mdX--assemble --scan是按分区里的超级块自动组合。能成功的话会生成/dev/md0、/dev/md127之类的设备。mdadm --detail能看出阵列当前状态比如是active还是degraded。到这里RAID层已经解开了。接着处理LVM层# 4. 扫描并激活LVM sudo pvscan sudo vgscan sudo lvscan sudo vgchange -ay正常情况下你能看到vg1000被激活逻辑卷/dev/vg1000/synology出现。如果vgscan扫不到多半是RAID层还没完全ready退回到第3步看mdadm --detail的状态是否有clean。激活LVM之后文件系统就能挂载了# 5. 确认文件系统类型并只读挂载 sudo blkid /dev/vg1000/synology sudo mkdir -p /mnt/nas_recovery sudo mount -o ro,noatime /dev/vg1000/synology /mnt/nas_recovery # 如果是btrfs卷 sudo mount -o ro,noatime,subvol/ /dev/vg1000/synology /mnt/nas_recovery挂载成功后ls /mnt/nas_recovery能看到群晖系统目录结构synology、docker、appstore这些到这一步基本就回家了。数据在/mnt/nas_recovery/synology/...下面按共享文件夹存放。这整套流程看起来短但每一步都有卡壳的可能。下面把最容易翻车的三个场景单独拿出来细讲——单盘降级装配、分区表偏移、LVM扫不到都是我实际碰到过的。4. 单盘恢复场景RAID阵列只有一块盘时怎么强制装配成功很多人的“群晖恢复”其实是这种情况NAS里本来插了两块盘做了RAID 1其中一块坏了拔了或者干脆就只用一块basic卷现在想从这剩下的一块盘里读出全部数据。这时mdadm --assemble --scan经常会失败报错类似Not enough devices to start the array。这个报错不代表数据没了只说明当前活着的盘少于阵列预期数量mdadm出于安全不会自动启动阵列。行为很保守少盘时阵列默认不自动装配怕强行用不完整盘启动写入导致整个阵列崩溃。正确的做法是手动指定只读强制装配# 先确认坏盘不存在不要插着坏盘强行装配 sudo mdadm --stop /dev/md0 2/dev/null sudo mdadm --assemble --run --readonly /dev/md0 /dev/sdb2拆解一下这几个参数。--run的含义是“即便当前成员数量不足也强制把阵列跑起来”--readonly是把阵列设成只读防止任何写入。/dev/md0是自定义的设备号也可以不指定让内核自己分配。为什么要必须带上--readonly因为RAID 1在降级状态下启动时mdadm可能尝试做写位图重放或同步一旦你原盘里有未知的坏道写操作就会破坏数据。只读装配下所有成员盘都不能写入安全得多。装配好之后重复上面的pvscan和vgchange -ay步骤。RAID 1单盘降级时LVM信息其实还保留在盘上只要阵列一激活LVM立刻能被扫到。单盘装配有几种常见报错需要分辨报错信息可能原因处理思路No super block found on /dev/sdb2分区号写错或数组超块确实损坏换分区号试或mdadm --examine --scan扫全盘Not enough devices to start the array阵列在线盘数少于预期用--run --readonly强制装配device is busy之前装配残留mdadm --stop /dev/md0后重试挂载时报wrong fs typeLVM未激活或文件系统挂了重新vgchange -ayblkid确认类型还有个细节如果阵列原本是SHRSHR本质是mdadm的RAID 1或RAID 5/6组合但盘上的卷组名不一定是vg1000可能是vg1没关系lvscan能看到实际名字灵活跟进就行。这里要特别说明一个边界如果你原本是RAID 5/6阵列只剩一块盘强制装配大概率不会成功。因为mdraid对条带阵列的要求是必须有能拼出完整数据的成员数量单独一个条带盘上的数据是不完整的这种情况我只能建议找专业的文件系统恢复机构或者至少保留好这块盘的完整镜像后再尝试自己盲撸容易把残留元数据也搞坏。RAID 1/10有镜像性质单盘强制装配才有意义。5. 群晖盘面特有的坑分区表偏移、同步残留和LVM不激活5.1 分区表偏移fdisk -l看到的和实际数据盘对不上群晖盘的分区表设计有个让新手恼火的点它不一定用标准的GPT有时会留出一个很小的偏移量。比如你用fdisk -l看分区是从扇区2048开始的但用mdadm --examine去读那个分区又提示No super block found。这时候你怀疑分区号不对但/dev/sdb能看到的Linux RAID分区就那一个怎么办一个笨但有效的办法是拿mdadm直接扫整个物理盘sudo mdadm --examine /dev/sdb这会扫描盘上所有可能存在的超级块位置。如果能看到它会告诉你类似Device /dev/sdb和Raid Device : 0的信息并且下一行会提示一个Device Partition的偏移量。你只要按这个偏移量算出实际分区起始位置用parted或者fdisk补一个分区表项或者更直接一点sudo mdadm --assemble --run --readonly /dev/md0 /dev/sdb没错mdadm可以直接拿整个块设备去装配绕过分区表识别到超级块就行。这也解释了为什么有的教程里写的是/dev/sdb而不是/dev/sdb2。5.2 阵列降级后的“同步残留”装配成功但文件系统挂不上这个是真正的坑。有一次我帮朋友恢复一台DSM 6.2的机器两块盘RAID 1其中一块故障后NAS自动降级运行了几天。我用单盘强制装配mdadm --detail显示clean, degradedRAID层看起来一切正常但blkid /dev/vg1000/synology始终不出现LVM也认不到。排查很久最后发现原因故障盘被拔掉后原来RAID 1里的写意图write intent bitmap还在同步状态LVM元数据可能在某个时间点被部分更新导致vgscan扫不到卷组。解决方式比较暴力但有效# 让md数组在只读状态下先冷启动一次再停止 sudo mdadm --stop /dev/md0 sudo mdadm --assemble --run --readonly /dev/md0 /dev/sdb2 sleep 2 sudo mdadm --stop /dev/md0 # 然后再装配一次这次用可写状态激活LVM sudo mdadm --assemble --run /dev/md0 /dev/sdb2 sudo vgscan sudo vgchange -ay原理是让mdadm内部在冷启动时把超级块里的元数据重新读一遍第二次装配时就会重新注册通知LVM。你在第二次装配后即使不添加--readonly只要不主动写入文件系统风险也可控。之后vgscan大概率能扫到。做了这一步仍然扫不到LVM还可以试试直接指定物理卷sudo pvscan --cache /dev/md0 sudo pvdisplay /dev/md0如果pvdisplay能看到卷组名但vgchange -ay不激活大概是内核里旧设备号残留重启一次Ubuntu再走一遍或者用vgextend那个思路去强制导入。这个情况不多见我遇到的不超过三次。5.3 群晖的Btrfs卷挂载前还要注意subvol参数新的群晖机型或者套件升级后系统卷是Btrfs。挂载命令和ext4不一样不指定subvol的话很多根目录文件是看不到的。正确挂载命令我上面已经给了sudo mount -o ro,noatime,subvol/ /dev/vg1000/synology /mnt/nas_recovery不加subvol/有时候也能挂上但/下只有一堆数字命名的子卷用户数据藏在子卷里得手动翻。加上subvol/后就能直接看到正常的群晖目录结构。如果没加用btrfs subvolume list /mnt/nas_recovery也能列出子卷再逐个挂载——但效率太低了不如一次挂对。6. 恢复完成后的数据导出与善后别急着把盘塞回群晖数据成功挂载只是第一步怎么把数据从这块盘上安全转移出来才是整个恢复工作的收尾部分也是很多人最后翻车的地方——盘还插在恢复机上就开始乱动结果一次意外断电又摧毁了整个可读状态。我推荐的做法是无论数据量多大都在恢复机上通过rsync完整复制到另一个健康磁盘或存储设备上绝对不会边挂载边在原盘上做任何写操作。# 同步整个群晖共享文件夹到恢复目标盘 sudo rsync -avh --progress /mnt/nas_recovery/synology/ /media/backup_disk/synology/如果你想保留文件权限和时间戳-a这个参数必须带群晖共享文件夹里的ACL可能依赖这些属性。别用cp -r大数据量时错误处理不如rsync灵活。还有一个讲究的细节恢复完成后在继续操作系统之前先把mdadm的状态写进恢复机的配置里防止之后重启导致设备名漂移让你找不到刚挂载的设备。sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf sudo update-initramfs -u这一步不是必须但做一次等于给恢复环境留了个后门。如果你中途重启用mdadm能自动认出阵列省得重新手动装配。数据复制完成后还有两件事必须做第一umount文件系统vgchange -an停掉LVMmdadm --stop停掉阵列然后安全拔出硬盘第二如果这台群晖盘还打算装回NAS继续服役千万别直接插回去。因为你以非群晖方式挂载过盘面虽然底层没动但群晖自己的mdadm和LVM状态可能和你Ubuntu内的操作序列不完全匹配插回去容易提示“未初始化”或要求重新创建阵列。这时候宁可先把盘放在一边先把数据备份到安全位置再考虑是重装系统还是重新初始化。有人会问能不能不拆硬盘直接在群晖的SSH里恢复其实如果群晖系统还能启动到SSH那根本不需要走这套流程直接共享文件夹拷出来即可。但这套方法的价值在于系统彻底起不来、引导坏了的时候依然能靠一台普通的Ubuntu机器把数据捞出来不依赖任何群晖专有工具。最后再分享一条经验。这套流程我至少跑通了几十次成功率最高的版本不是最新版Ubuntu反而是Ubuntu 18。原因是Ubuntu 18自带的mdadm版本对旧格式超级块的兼容性更好而且不会自作主张去更新RAID元数据版本。你手上如果是块有年头的老群晖盘内核版本越新有时候反而越容易碰到“superblock version mismatch”之类的问题反而不如Ubuntu 18顺手。这也是我不建议拿最新的Ubuntu 24来干这件事的原因。本文还有配套的精品资源点击获取