我如何在 AI 帮助下， 7 天带着 35TB 数据逃离某联系统

引言

时光荏苒，距离我写出《双十一买的 DX4600 Pro ，玩了两个星期，系统基本被我摸明白了，非常逆天》、《深入解析某联云 DX4600 Pro UGOS 系统(1)》、《深入解析某联云 DX4600 Pro UGOS 系统 (2)》、《深入浅出玩转某联 UGOS (上)》、《深入浅出玩转某联 UGOS (下)》这些文章已经过去了将近 3 年的时间，严格来说是练习时长 2 年半。这一坤年以来随着我对自动化体系的逐步建设成熟，加上客户群（同学朋友）的逐渐固定，这台 NAS 基本变成了一台跑着 Jellyfin 生态链的服务器，一开始兴致勃勃给家里人开启的相册同步也随着家长的设备换成鸿蒙慢慢被放弃（旧的 OpenWRT 的*联私有云 APP 不支持鸿蒙系统）。

因为这个系统实在是太*圾了，槽点太多了，导致我这几年每天晚上睡觉之前都在懊悔，为什么买了个这个东西，跟他过日子仅仅 2 年就像已经过了倦怠期的老夫老妻，每天路过客厅看着这么一块玩意儿在那里自己轰隆隆炒豆子摇摇头探个气，继续过自己的日子。

我的正经职业是 DBA ，做了 2 年的 PG 内核，现在在做一款分布式的数据库。因为从小就兴趣使然爱玩电子产品，于是到现在我在做一些客户 POC 的时候甚至能帮他们做服务器硬件选型。我自认为对企业级的存储服务器也有一定的了解，最近一年往购物车里攒了一大堆硬件。小海豚的 SSD 、24TB 的硬盘、U2+SATA 的背板、3U9 盘位机架、万兆网卡……一个伟大的全小区最强 TrueNAS ZFS 混合存储 NAS 已经跃然纸上，只要等我攒购钱、只要等我装修的时候做个机柜、只要等我先把车子买了、只要等我们 Jellyfin 影视资源占满现在的存储空间……

这些全没有等来，但 AI 时代突然来了。我眼睁睁看着一条 ECC 内存从 1500 变成 5100 ，一块 HC550 从 2400 变成 7200 ，更离谱的是小海豚大普微恺侠这些这些企业级 U2 直接从 4 位数变成 5 位数……工资的涨幅要跟上电子存储的涨幅简直是痴人说梦。

我在 24 年底就买了台 Mac Mini ，当时就在做了大量的调研之后决定趁着国补先屯一台万兆网口准备给以后用，这台机器买来在我房间甚至放了半年都没开过机，因为完全没有用，真正让它开机上场还是因为UGOS 这个系统对 aria2 的 docker 适配有问题，所以单部署了个 aria2 当下载器来用。说实话，M4 的性能跟 NAS 的这颗 N6005 做对比，简直就是像现代军队攻打原始部落，制式武器对付刀剑棍棒，完全没有任何可比性，连 arm 弱势的外围 IO 也是被薄纱。

说回近期，Jellyfin 一直是我很喜欢的一个活跃的开源项目，当年刚安装的时候还是 10.3.x ，现在都 10.11.11 了。可最近我（和使用我服务器看片的朋友）总觉得性能越来越差，尤其是 10.11.x 开始，Jellyfin 在后台扫描更新媒体库的时候，基本上卡得没法用。Jellyfin 社区的兄弟们似乎在 SQLite 之上写了一些性能很差的 SQL 。我认为这样下去不是办法，既然没精力研究开源社区代码，就只能提升自己的硬件性能，大力出奇迹了。

于是，一个在 AI 浪潮下迫不得已的 Plan B 诞生：逃离原生家庭UGOS ，重装系统，把 Jellyfin 迁到 M4 上去。

在开始之前，先做一个省流：

本次系统迁移和重装存在一定支出，需要一台 Mac ，网络设备花费 360 元、存储空间租赁花费 1540 元、耗时自然天 5 天

但我认为这一切都是值得的。

数据中转

要重装 NAS 最头疼的第一件事肯定是数据往哪里转存。我的机器当年花了大手笔，可不是什么 4*4T 红盘那种家庭娱乐配置。彼时存储空间用量已经达到了 34TB 的超高水位。

这么大容量的数据，想找亲朋好友拼好盘是不现实的，传网盘也是不现实的（会直接被运营商封），我们第一步是要找能够租赁存储硬件的地方，而我们手头有的硬件形态又很大程度上影响我们要租什么。

最低成本步入万兆

最开始的事情肯定是让这台 Mac 迈入万兆。从 24 年购入至今，这台机器其实一直放在我的卧室里走 WiFi 连网，这对于后续改造服务器用途必然是不现实的，所以要把我特地加钱换的 10G 口用起来。简单搜集一些资讯之后弄了套成本很低的玩具级万兆阵容：

• 兮克 SKS3200M-4GPY2XF 轻管理交换机，4 个 2.5G 电口+2 个 SFP+10G
• 兮克 SKT-10G-30M 电口模块
• 海倍思 HDMI 4K60 欺骗器
• 若干根七类跳线

总花销 360 多点，一开始还买错了，轻管理的交换机不支持链路聚合，中途退货重买耽误了 2 天。

（但后续使用发现这么便宜的交换机有些问题，确实是玩具）

重新审视硬件

然后来看看绿联这个 DX4600 “Pro”的硬件配置吧。我们主要关注 IO 方面的：

• 前面板 USB A+C 口 10Gbps
• DDR4 内存，最高 2400MT ，单通道
• 两个挂接在 PCI-E 的 Intel I225-V 2.5Gbps 电口，UGOS 系统支持链路聚合
• 两个芯片组提供的 USB3.0 5Gbps A 口
• 两个 PCI-E 3.0 x1的 SSD 接口
• 两个 SATA 6Gbps 直连 CPU
• 两个 SATA 6Gbps 走 PCIE 交换芯片

也就是说这台机器对外输出的理论最高速度就是前置的 USB3.0 口，其次则是网线聚合。

寻求中转平台

考虑到绿联这个杀千刀的老系统是把 libc 直接抽走的 OpenWrt ，没有任何自己编译打驱动的可能性，淘宝上售卖的 USB4 的那些高速 DAS 不一定能免驱适配。大多数能直连的下位机都是 U 盘/单盘硬盘盒，达不到 35TB 容量，更关键的是上哪有得租？

如果走网线口，大存储服务器租赁价格极其高昂，成品 NAS 基本没人出租，但经过我的不懈搜索，发现把视角转向 Mac 生态有些惊人的发现。

Mac 拉拢了一批定位剪视频的生产力客群，而母带素材剪辑对应的高昂存储需求催生了一批很正规的“雷电磁盘阵列租赁”业务，只要喊容量，他们定价格，给你发台在苹果电脑即插即用的机器，这里面绝大部分是 Areca 的：

在比价和挑选发货地之后，我找了一位同城的卖家定制了 48T 的阵列。综合考虑数据量和价格，我选择租了 7 天，并且特地和卖家说我要做 Raid0 （短期存储，性能考量），租赁成本是 1540 元。

收到之后点亮发现是 3 块 16TB ，跑 BMD 的顺序读写测速能飙到 950MB+，已经是 3 块盘的极限，并且高于 NAS 整机的网络带宽，那么中转这整条链路就已经没有瓶颈了。

规划迁移方案

现在硬件阵容已经就绪，我们就要来设计软件层面的迁移方案。老的绿联系统对用户提供了这些访问数据的手段：

• WebUI / Electron 客户端（下载文件夹会自动打 zip 包）
• SMB （ OpenWRT 生态链太老，以致于系统的 smbd 不支持 multichannel ）
• FTP
• AFP
• WebDAV
• 基于 syncthing 套壳的同步功能

没有 NFS Server 功能。

那么选什么已经显而易见了：rsync。理由很简单，

其一，不需要信任/使用这个系统提供的任何方案，通过 rsync 协议读写双端都是直接进行物理 IO ，避开 CPU 瓶颈；

其二，rsync 天生具备断点续传/增量同步能力；

其三，rsync 灵活性高，可通过简单的 shell 脚本自行设计并发，还能完全抹去属主信息。

软件编译

话虽如此，rsync 在软件部署上也有一些难点。熟悉 UGOS 的朋友都知道，这个系统出厂的时候特地把公共动态库 libc 给抽走了，导致从 opkg 下载安装的程序全都无法运行。那么我们只能手动编译静态链接库的方法让 rsync 在绿联系统上跑起来。

说实话，我从来没有接触过正儿八经的 CMake 项目编写，甚至对 Linux lib 了解都不算特别深刻，换做以前搞这个事情折腾三五天都很正常，但现在有 AI 一句话就行了：

参考 https://github.com/jbruechert/rsync-static ，在 root:password@192.168.159.128 上编译出至少 openwrt 22.03 Linux kernel 5.10.120 x86_64 GNU / Linux 可用的 rsync static library 版本（不依赖 libc ），rsync 使用 tag：v3.4.4

提示词里提供的机器是一台 CentOS 8 虚拟机，根据以往的经验，只要编译环境的 Linux 内核版本比目标机器旧，那么大概率编译成品就能在新内核跑。

Codex 也是不负众望，30 分钟左右完成了任务，并在绿联系统上验证能够正常运行。

Mac 那边就更简单了，brew install rsync完事。

目录重整

三年前我在设计存储目录的时候犯了一些错误。我把各种媒体文件夹放在了世界各地，然后通过 docker 的 bind mount 把它们全部映射进来：

这种设计让我在维护 docker 目录映射时心力交瘁，并且对于读写类应用有一个弊端：Docker 不知道两个目录之间的物理位置关系，进而导致在 qBittorrent 等下载器移动某个文件到其他位置时，会进行一次原地读写。因此，这次迁移最重要的一件事情就是对媒体库目录结构进行重整。

重整本身用简单的 mv 就能完成，再让 GPT 帮我完善成一个具备 pipefail 、日志输出、函数封装、目录代建的严谨移动脚本，把所有内容都归集起来。登录 NAS 以 root 用户执行脚本：

Docker 备份

绿联系统的 docker 极其老旧，并且压根连 compose 都不支持，我的 NAS 运行到现在都是在散养十几个容器。考虑到后续 AI 辅助还原，实际上只需要把所有容器 inspect 存下来就好了，后续让 AI 自己读取 json 翻译成 compose yaml 。

if command -v docker >/dev/null 2>&1; then
  docker ps -a > "$OUT_DIR/docker/ps-a.txt" 2>&1 || true
  docker images > "$OUT_DIR/docker/images.txt" 2>&1 || true
  docker volume ls > "$OUT_DIR/docker/volumes.txt" 2>&1 || true
  docker network ls > "$OUT_DIR/docker/networks.txt" 2>&1 || true

  docker ps -a --format '{{.Names}}' > "$OUT_DIR/docker/container-names.txt" 2>/dev/null || true
  while IFS= read -r name; do
    [ -n "$name" ] || continue
    safe="$(echo "$name" | tr '/ ' '__' | tr -cd 'A-Za-z0-9_.-')"
    docker inspect "$name" > "$OUT_DIR/docker/inspect/$safe.json" 2>&1 || true
  done < "$OUT_DIR/docker/container-names.txt"

  {
    echo "# Compose reconstruction checklist"
    echo "# Review each inspect JSON for Image, Env, Cmd, HostConfig.Binds, PortBindings, RestartPolicy, NetworkMode, Privileged, Devices."
    echo
    cat "$OUT_DIR/docker/container-names.txt"
  } > "$OUT_DIR/docker/compose-candidates.txt"
fi

而这里面重点且特殊的核心业务是 Jellyfin ，我后续还会再出一篇文章单独讨论怎么将 Jellyfin 重建到 macOS 系统上。

提前演练

把 OS 切换到飞牛有一个商业成品系统做不到的优势：我可以下载 ISO 自己在虚拟机装一个系统，提前探索飞牛的目录结构，提前制定精确的回迁路径设计。只需要多分两块虚拟硬盘，就能够搞懂多存储空间的目录关系是怎么样的。

飞牛的结构相对直观：/volN/UID/是用户私人目录，/volN/@team/是团队目录，同时跨用户共享的目录在 SMB 会呈现为一个叫做“XXX 共享给我”的目录。

脚本构建

rsync 的迁出分为两个部分：发送端并发拉起若干个 rsync 进程同时向对端传送文件，以及在 macOS 上跑的 daemon ，负责接收文件直写硬盘。

这部分直接让 Codex 代劳即可：

Codex 出具的方案是维护一份 tsv ，让发端 shell 脚本自己读取 tsv 文件建立 N 并发的任务。考虑到我们先前自编译 rsync 的需求，我还额外提出了一些自定义参数，比如指定 rsync 位置之类的，Codex 最终产出的成果专业性实际上已经相对很强，我在银行里写的那些 sh 脚本很多时候不一定比它好。

本次迁移所使用的最终脚本套件已经开源到仓库escape-from-ugos。

应用数据打包

docker 的部分应用会创建几百万甚至上千万的 xml 或者小图像文件（比如 Photoprism 和 Jellyfin ），考虑到应用数据本身在 SSD 上，如果这样就这样移到机械阵列里去，那估计下辈子都移不完。因此对于应用类数据在撤离之前最好先打成 tar 包，等回迁后在 SSD 就地解压。

删除文件黑洞

避免类似的大量小文件影响迁移效率，不用作过多解释

find -L /mnt -type d -name "node_modules" -exec rm -rf {} +

正式迁移

所有准备工作完成，接下来就是和亲朋好友发公告，准备停服开始正式迁移。

正式迁移说白了就 3 步：

1. 停止 UGOS 上的整个 Docker 引擎，然后执行上面的“应用数据打包”环节
2. 开两个 iTerm 窗口，一个跑 rsync daemon ，另一个 ssh 到 UGOS 上执行 push 文件脚本
3. 等待

真实迁移流程验证了使用 rsync 并发推送是完全正确的，导出影视大文件时整套链路能够持续地跑满 5Gbps 带宽上限，导出小文件时最先触达瓶颈的也是 Raid5 的磁盘 IO Util ，而不是上层的任何 CPU 、网络、中转存储 IO：

在所有任务都完成后，可以重跑 1-2 次迁移脚本，以确保可能有遗漏的文件被重新增量刷回去。

就这样，我的 35TB 数据在34 小时的长征后，全部撤离了 UGOS 系统。

重装系统

时间就是金钱，确认数据迁走后立即将 NAS 关机，插上 HDMI ，接入装机 U 盘，然后进 BIOS 关 watchdog 后引导启动飞牛。

不过这里有个坑，如果你跟我一样用 Ventoy 当引导盘的话，启动飞牛 ISO 要选boot in grub mode，否则在安装完系统创建引导的时候会卡住。

数据回迁

进入飞牛系统后，把原本 4 块硬盘的 raid 分区以及之前的 SSD 空间全部直接销毁，然后重新创建存储空间，这部分操作就不过多赘述。

我的 Raid5 之魂仍旧在燃烧，所以即使是新换了系统我还是使用了 Raid5 ，毕竟理论上读性能 3 倍，机械硬盘的单盘 IO 确实不够看的。回迁之前我还额外等了这个“检查优化”一天，现在来看完全可以不用等，建完存储空间直接开始灌数据。

权限规划

因为飞牛系统的用户是真真正正的和 Linux user 挂钩，所以权限结构设计可以变得十分合理。这次在飞牛系统，我规划所有的应用服务类软件和他们相关的数据全部使用app用户，包括 Jellyfin 的媒体文件、下载器全部归属 app ，毕竟所有影视媒体对上层由平台软件提供，不直接提供文件访问。外部的机器如果需要使用 NAS 的数据，也通过 app 用户挂载 SMB/NFS 访问。

相比于迁出数据，回迁则需要慎重设计方案。因为四盘 Raid5 理论上有 3 倍读 IO ，但写始终是单盘性能。我在进行回迁的时候走了一些弯路，并且被兮克的这个便宜交换机坑了一把。

回迁方案

先说最终的回迁方案：

1. 回迁期间必须区分大文件和小文件
2. 大文件的最快方案是直接把目录拖到飞牛 Web 文件管理上传，飞牛 Web 端处理 20-30TB 完全不会出错
3. 小文件多的目录，走 NFS 挂载+rsync 上传

说一下使用这套方案的原因：

1. 飞牛 Web 虽然吞吐量最高，但上传小文件效率非常低，从 Mac 的 fsevents 统计来看，它每秒只能处理大约 4 个文件
2. 飞牛的 SMB 虽然吞吐性能已经比 UGOS 好太多，但是它默认给 SMB 加了审计，一次性走 SMB 传入大量文件，会往日志 app 里刷 10 万页的审计记录
3. 所有的文件交互方式我都测试过，最理想的依旧是 NFSv3 + 异步，没有审计，且开销最小，吞吐量不够可以靠 rsync 并发来凑，异步对 server 端机械硬盘写入也非常友好，但需要注意避免意外断电断网
4. 通过上述的方案完全不用操心任何文件权限和属主问题，网页端不谈，NFS Server 是 squash 的，挂载者视角看所有文件权限都是 777
5. 访达就不谈了，一坨屎

我使用下列命令完成小文件的导入：

sudo mount -t nfs -o vers=3,tcp,hard,async,rsize=65536,wsize=65536 192.168.1.20:/fs/1001/nfs /Volumes/nfs_Media

rsync -a --no-owner --no-group --whole-file --info=progress2 --partial --partial-dir=.rsync-partial \
/Volumes/storage/MediaLibrary/Albums/ /Volumes/nfs_Media/MediaLibrary/R18/Albums/

不过这里有个情况需要说明一下，几千上万个小文件其实没有折腾的必要，我这里说的小文件多，大约是 10 万以上量级。以下列数据为例，图库类的写真集、插画集，约 40 万文件，但只有 3TB 大小，这种情况除了 NFS 以外，谁来都迁不动。

交换机问题

再说交换机的坑点：从 SFP 口往聚合电口上传数据时，交换机会丢包，导致极限吞吐量只有 2Gbps 左右。这个丢包不会体现在交换机后台的统计数据，而是自然而然地，静悄悄地就丢掉了，只留下 iperf3 打流成绩里大量的 Retr：

更离奇的是，如果我手动把 Mac 的以太网口硬件协商速率更改成 5000Base-T ，那么这个极限值则会提升到 2.6Gbps 左右

在调整这个玩具交换机各种聚合配置后仍旧无济于事，考虑到 2.6Gbps 已经达到单盘外圈写的瓶颈，并且只有上传丢包下载没问题，我在这里也暂且接受。不过还是建议各位如果有万兆需求，买一些正儿八经的交换机。

---

最终我的所有数据回迁花费了56 小时完成。

应用恢复

就地解 tar 包：

然后把先前收集的 inspect 全部喂给 AI ，让它帮我生成 compose yaml 文件。由于这是一个极其简单的任务，让 Workbuddy 来都能顺利完成：

对于 qBittorrent 下载器等受目录变更影响较大的工具，让 K3 帮我写一个批量调用 qB 更改保存位置 API 的工具进行自动映射：

如此这般，最终一个下午完成所有 docker 服务的梳理和归位：

一不做二不休，我还趁此机会做了反代，把访问路径收束，避免公网安全问题。这不是这篇文章的重点，所以我就简单带过——测试了一些知名的反代工具，其中：

• Lucky 虽然功能性强，但基础反代的性能很差，做 librespeed 打流跑不上千兆的同时还会把 M4 的 4 个 P 核拉满
• NginxProxyManager 的反代比较僵硬，没法满足家用场景下因为没公网域名产生的一系列复杂重定向+反代需求

所以最终我选择了经典的 Nginx + AI 代我维护规则，性能灵活两手抓。

适配后感想

从完成这次惊心动魄的去 U 攻坚迁移到现在已经一个月有余，我在这里简单说下我的感受，以及推荐现存 UGOS 用户早日抛弃某联的理由：

1. 基于 OpenWRT 的 UGOS 系统的超旧版本 docker 实际上有非常严重的内存泄漏问题，经常出现容器运行半个月左右之后内存用满 OOM ，导致我要在 crontab 给一些重要容器写一个定期 docker restart ，16G 不够用还得上 8G 的 swap 才顶得住。

然而换到基于 Debian 的 FnOS 之后跑了一个月系统总内存消耗都没有高出过 5GB 。

1. UGOS 没有 NFS ，且 SMB 性能非常差——首先是它的 smbd 不支持 Multichannel ，其次多文件导入时内置的一个垃圾应用filesearch_svr会异步地开始对文件构建索引，打爆 CPU ，然后导致 SMB 写入降速。然而，数据量大到一定程度之后，它的存储空间视图根本加载不出来，等于在白吃性能。

FnOS 任何时候灌文件基本都能顶满线速，并且有开箱即用的 NFS 服务。

1. FnOS 光是正常的、符合直觉的文件权限机制就已经把 UGOS 那套反人类的系统按在地上摩擦了。

2. FnOS 内置的影视、图库、Btrfs 快照能用，但 UGOS 上面的对应套件无法用语言来形容。包括 docker 、备份能力、网盘、第三方应用等功能，能把 UGOS 拿出来跟飞牛对比属于高看它了。

3. 我认为我以前在 UGOS 上开发和折腾的经历全都是在浪费时间。

4. 朱门酒肉臭，路有冻死骨，所谓的冻死骨就指的是老*联用户、老*联 NAS 系统。