当前位置：

社区首页

电脑数码

电脑整机

台式机

零刻/Beelink

文章详情

群晖DS220+换零刻ME Pro：2.8TB数据，靠一条命令全部救回！

说明：纯个人实操记录，2.8TB数据100%恢复，附踩坑实录和完整命令

1 前言

我的群晖DS220+是2023年8月买的，到今年6月正好用了快三年。两块8TB HGST+WDC硬盘基本够用，在群晖DS220+上都是独立使用，也没有组raid，用的是单盘模式，文件系统用的是Btrfs，家庭照片、工作文档、冷备份什么的都在里面。

本来只是想升级一下硬件——零刻ME Pro N95（准系统），自己拿家里闲置的笔记本电脑以旧换新，下来才不到一千多，3+2盘位，系统可以用最近比较火的飞牛fnOS，想着老群晖性能确实不够用了，就换了。换前也查了资料，老群晖的硬盘可以直接插到安装了飞牛fnOS的零刻ME Pro N95上使用，无非就是2个NAS之间倒一下数据。

结果谁能想到，本来以为就是个普通的数据迁移，硬生生变成了一场数据救援。中间还赶上家里停电，差点把我整疯了。最后不仅数据全回来了，还把我以为早就丢了的老备份一起救了出来，总共恢复了2.8TB。整个过程太紧张刺激并具有启发性，为了避免后续有同样换机的朋友少走弯路，我就写出来给大家分享参考避避坑。

2 升级背景与设备选型

2.1 原有设备情况

先说一下老设备的配置：

群晖这三年用着一直挺稳的，没出过什么幺蛾子。DSM的功能完整性和稳定性确实没得说，飞牛跟它比还有差距。但几个问题越用越难受：

性能瓶颈：J4025处理器，跑个Docker容器、AI照片识别不行。
内存太小：DS220+只有2GB内存，虽然加了16GB到18GB，但是CPU性能不行，跑多点Docker就吃紧。
网口太慢：只有千兆网口，内网拷大文件速度上不去，虽然后期加装了USB转2.5G网卡，但是毕竟现在新机器都带2.5G/5G甚至10G了。
想折腾新系统：飞牛fnOS宣传的比较广（个人使用免费，虽然不是开源），UI风格跟群晖挺像的，上手快，想试试看国产系统的体验。

2.2 新设备选择

零刻ME Pro我之前专门写过一篇开箱评测，感兴趣的可以去看看：

外观、拆机、都有，这里就不重复说了。

没选贵的，就挑了性价比最高的组合：

我的想法很简单：家用NAS没必要买太贵的品牌机，x86架构+足够盘位+大内存，飞牛这种个人免费系统完全够用，省下来的钱给系统加内存加硬盘更好。如果对零刻ME Pro感兴趣可以看我的这篇购买推荐文章

3 迁移前准备

3.1 硬盘结构摸底

拆硬盘之前，我先SSH登群晖DS220+摸了下底层结构，免得踩坑。建议大家迁移之前也做这一步，心里有底：

# 查看磁盘分区 lsblk # 查看LVM信息 pvs && vgs && lvs # 查看RAID状态 cat /proc/mdstat

几个关键信息记下来：

群晖用mdadm做了软RAID
上面套了LVM逻辑卷管理
文件系统是群晖修改过的Btrfs——后面所有的坑全在这
主卷路径：/dev/vg1/volume_1

3.2 数据目录梳理

群晖里需要迁移的部分核心数据我提前理了一下：

这部分数据都在我的HGST 8TB盘上，WDC 8TB的盘上基本没啥数据，这也成了后面用命令恢复数据的目标盘。最后实际恢复了2.82TB——多出来的都是群晖系统目录里的老备份，我之前以为早就丢了的，也算意外收获。

4 迁移过程：从稳得一批到心态崩盘

本来以为就是简单的拷数据→装系统→拷回去，谁知道中间出了一连串幺蛾子，整整折腾了两天。

4.1 第一阶段：FastCopy网络中转拷贝

因为担心直接挂载翻车，我先把群晖DS220+上这部分556GB核心数据通过SMB共享拷到电脑上。用的是FastCopy v5.11.3，比Windows自带复制快至少3倍，还支持断点续传。

================================================= FastCopy(ver5.11.3) start at 2026/06/05 10:30:18 192.168.68.2hgst_8tb_backupcold_backup_2025 G:HGST_8TB_BACKUP 移动（全覆盖） ------------------------------------------------

拷了3小时42分钟，556GB数据校验100%正确。数据拷贝完成后，心里稍微踏实了一下，这样就算8TB盘挂载到飞牛fnOS无法识别和有效解决数据迁移问题等，没办法把盘重新格式化，我大不了再用fastcopy拷贝回去。

4.2 第二阶段：拆机装系统 + 挂载翻车

为了把群晖DS220+上的8TB硬盘数据无损迁移到飞牛fnOS上，我还专门上网查了很多类似案例。但发现要么是文章日期太老，要么是版本对不上，要么是环境不一样，跟着试了好几次都失败。最后还是自己反复摸索才找到解决方法，所以这篇也算给大家踩个坑。

群晖DS220+关机，拆出HGST 8TB硬盘，装到零刻ME Pro的3.5寸盘位。 U盘装完飞牛fnOS，初始化好飞牛系统，配好IP地址，飞牛设置了打开SSH，个人电脑SSH登进去先看磁盘能不能识别：

lsblk

df -h

ll /dev/mapper/

硬盘能认出来，我以为稳了。直接敲挂载命令：

mkdir /vol3 mount /dev/sda5 /vol3 # ❌ 失败 mount /dev/md124 /vol3 # ❌ 失败

报错：mount: /vol3: can't read superblock on /dev/mapper/vg1-volume_1

4.3 第三阶段：LVM激活 + 还是挂不上

根据lsblk的输出，能看出来sda1、sda2、sda5是群晖那边过来的盘，用mdadm做了软RAID，还做了LVM。那就先尝试激活LVM卷组试试：

# 扫描LVM卷组 vgscan # 激活卷组vg1 vgchange -ay vg1

其实这个操作完全可以不做，8TB盘一挂载就自动激活了。得到逻辑卷路径/dev/vg1/volume_1。

# 查看LVM信息 pvs

vgs

lvs

cat /proc/mdstat

这里还有个告警：WARNING: PV /dev/md124 in VG vg1 is using an old PV header, modify the VG to update. 不过不影响，先不管。

再次尝试挂载：

mount -o ro /dev/vg1/volume_1 /vol2/1000/WDC_8TB_BACKUP

还是失败，报invalid root flags和open_ctree failed。

查了一圈才搞明白：群晖DSM对原生Btrfs进行了修改，加了私有超级块标志和syno.create_time这类扩展属性，通用Linux内核根本识别不了，直接挂载必报错。常规方法已经没用了，只能上终极杀器：btrfs restore。

4.4 第四阶段：btrfs restore物理层穿透救援

btrfs restore是个只读型的高级救援工具。它最厉害的地方是绕过内核文件系统层，直接从底层物理扇区扫描Btrfs的元数据树，不管上层封了什么RAID/LVM/魔改标记，只要底层数据还在就能抠出来。

4.4.1 基础恢复命令

# 创建备份盘挂载点 mkdir -p /mnt/WDC_8TB_BACKUP # 挂载新系统的备份盘 mount /dev/mapper/trim_9899da4d_6592_4841_9465_4bfdbeab70e9-0 /mnt/WDC_8TB_BACKUP # 开始恢复（自动覆盖已存在文件） yes a | btrfs restore -v -i -x -S -o /dev/vg1/volume_1 /mnt/WDC_8TB_BACKUP

恢复了750GB的时候，家里突然停电了……

4.4.2 暴击：突发停电，断点续传难题

来电后重启我人都傻了——btrfs restore原生不支持断点续传，重跑的话会覆盖已经恢复的750GB数据，相当于大半天白跑。

坐在那冷静了五分钟，突然想到：btrfs restore遇到已存在的文件会问是否覆盖？[y/N]，我用yes n自动给它答N不就行了？试了一下，居然真的可以：

nohup sh -c 'yes n | btrfs restore -v -i -x -S /dev/vg1/volume_1 /mnt/WDC_8TB_BACKUP 2>&1' > /mnt/WDC_8TB_BACKUP/restore_progress.log 2>&1 &

这行命令的解释：
yes n：遇到已存在文件自动输入n，直接跳过750GB已传数据，不用重跑
nohup ... &：扔后台跑，关电脑拔网线都不影响
-x：忽略群晖的专属扩展属性，避免Operation not supported报错中断

4.4.3 监控进度

# 看进程还在不在 ps -ef | grep btrfs # 实时看日志 tail -n 50 /mnt/WDC_8TB_BACKUP/restore_progress.log # 看已经恢复了多大 du -sh /mnt/WDC_8TB_BACKUP

说个经验：增量续传的盲扫阶段，日志可能十几分钟不滚动，别以为卡死了。看CPU占用率，如果硬盘在疯狂寻道就说明还在跑，保持耐心。

4.5 第五阶段：打通飞牛网页端"盲区"

恢复完发现命令行能看到文件，飞牛网页端死活不显示。查了下是飞牛的安全机制：只有共享文件夹内的文件才会在网页端显示，而且恢复的数据所有者是root，普通用户没权限。

改一下就行：

# 把数据移动到共享文件夹（1000是我的用户ID） mv /vol2/@syno /vol2/1000/ mv /vol2/thumb /vol2/1000/ # 递归修改权限 chown -R username:username /mnt/WDC_8TB_BACKUP # 设置正确权限 chmod -R 755 /mnt/WDC_8TB_BACKUP

刷新网页，所有数据都出来了。连我以为早就丢了的2018年老照片备份都在！

5 恢复成果统计

等于额外捡回了2TB多的老数据，算下来也是意外惊喜。

6 踩坑记录

都是实打实踩出来的经验，有类似需求的可以参考。不过先说明一下：本文只是我个人环境下的经验总结——群晖DS220+(DSM 7.3.2-86009 Update 3)、没有组RAID的2块独立单盘、迁移到零刻ME Pro+飞牛fnOS(1.1.3105)。如果你的设备型号、RAID模式、系统版本和我不一样，操作可能会有差异，建议多查一下对应环境的资料，斟酌参考。

6.1 坑1：群晖Btrfs别直接挂载

现象：挂载报错invalid root flags/open_ctree failed

原因：群晖定制了Btrfs私有标记，通用Linux识别不了

经验：别浪费时间试各种mount参数，没用。直接上btrfs restore，绕开内核读物理扇区。

6.2 坑2：btrfs restore不支持断点续传

现象：中断后重跑会覆盖已恢复数据

解决：用yes n | btrfs restore ...自动跳过已存在文件，完美实现增量续传

6.3 坑3：突发停电风险极高

现象：大容量数据恢复中途停电，轻则重跑重则数据损坏

建议：NAS最好配个UPS，尤其是做底层操作的时候。

6.4 坑4：别信NAS网页端显示

现象：底层大文件拷贝/恢复时，网页端容量显示卡死不动，以为宕机了

真相：网页端性能不足，以df -h、ps -ef、CPU占用率和日志滚动为准

6.5 坑5：飞牛网页端权限问题

现象：命令行能看到文件，网页端不显示

原因：飞牛安全机制，只能看到共享文件夹内属于当前用户的文件

解决：移动到共享文件夹 + chown -R修改所有者

7 给值友的迁移建议

7.1 数据迁移注意事项

⚠️ 永远提前备份！永远提前备份！永远提前备份！

⚠️ 群晖硬盘别直接格式化，先试试btrfs restore，大概率能救回数据

⚠️ 大容量数据迁移前先接UPS，停电代价太高

⚠️ 迁移完成后用rsync -av --checksum校验数据完整性，别只看大小

7.2 系统切换路径

从群晖转其他系统的最佳路径：

1. 数据备份 2. 网络拷贝核心数据到中转 3. 新系统安装配置 4. 旧硬盘接入新系统 5. btrfs restore恢复全量数据（如遇挂载失败） 6. 权限配置 + 应用迁移 7. 双系统并行1个月再格式化旧盘

8 个人感受

折腾完的几点真实感受，客观说一下：

群晖的系统确实还是强：DSM的易用性、稳定性、套件生态，飞牛fnOS目前还比不了。如果对稳定性要求高、不想折腾，群晖依然是首选
但群晖的硬件真的太拉跨：同价位的x86小主机性能吊打群晖，DS220+的J4025现在看真的不够用了。想升级硬件又不想花大价钱买高端群晖的，换个小主机装飞牛是个性价比很高的选择
btrfs restore是真神器：群晖硬盘挂了、系统崩了、想换系统读不出数据，先试这个工具，别着急格式化
适合的人群：爱折腾、动手能力强、对成本敏感的用户。纯小白还是建议直接上群晖，省心
零刻ME Pro系列真不错，做工好，关键是很稳，整个数据恢复过程主机散热，运行都稳的不像话，差不多2天运行时间也检验了其品质。

后续我打算部署一些适合自己的Docker应用，还有得把UPS安排上，再遇停电也不怕了。如对零刻ME Pro系列感兴趣可以看我这篇文章

9 附录：命令速查 + FAQ

9.1 常用命令速查

# 磁盘信息 lsblk # 查看磁盘分区 fdisk -l # 查看分区表 # RAID状态 cat /proc/mdstat # 查看软RAID状态 # LVM操作 pvs && vgs && lvs # 查看LVM信息 vgscan # 扫描卷组 vgchange -ay vg1 # 激活卷组 # Btrfs救援 yes n | btrfs restore -v -i -x -S /dev/vg1/volume_1 /mnt/backup # 增量恢复 # 进度监控 ps -ef | grep btrfs # 查看恢复进程 tail -f restore.log # 实时看日志 du -sh /mnt/backup # 看已恢复大小 # 数据校验 rsync -av --checksum source/ dest/ # 校验数据完整性 find /mnt/data -type f | wc -l # 统计文件数量 # 权限修复 chown -R 用户:组 /目录 # 递归修改所有者 chmod -R 755 /目录 # 递归修改权限