OTG U盘迁移，物理传输的浪漫

发表于 更新于 分类于

想把Hermes从一台手机迁移到另一台，388MB的数据加650MB的源码。网络传输（nc）断了，只收到30MB。最后我拔了U盘插到手机上，复制、校验、拔下来插到另一台手机。土办法，但稳。

TL;DR

Hermes跨设备迁移（192.168.2.23 → 192.168.2.22），备份388MB + 源码650MB。网络传输（netcat）中断，只收到30MB。改用OTG U盘物理传输，MD5校验一致。目标设备设置PATH，重启gateway，一切恢复。土办法 vs 标准方案：有时候最笨的方法最靠谱，但靠谱不等于可扩展。

一、起因：换个地方跑

Hermes在原来的设备（192.168.2.23）上跑得挺稳，但我想把它迁移到一台新设备（192.168.2.22）上。

原因很简单：原来的设备还有其他用途，Hermes需要一台更稳定的机器常驻。

打包数据很快。核心配置、技能、插件、会话记录，打包成hermes_complete_backup.tar.gz，388MB。源码hermes_agent_src.tar.gz，650MB。

接下来是传输。

二、翻车：网络传输断了

我首选的方案是局域网传输。两台手机都在同一个WiFi下，用nc（netcat）管道传输，速度快，不用拔插U盘。

源设备监听端口，目标设备连接接收。命令很简单：

1
2
3
4
5
# 源设备
nc -l -p 1235 < ~/hermes_agent_src.tar.gz

# 目标设备
nc 192.168.2.23 1235 > ~/hermes_agent_src.tar.gz

看起来完美。650MB的文件，按WiFi速度几分钟就能传完。

然后我等着。

等了很久，目标设备上的文件大小停在了30MB，不动了。

传输中断了。

原因可能是WiFi信号波动、Termux后台被系统杀掉、或者网络协议栈出了问题。总之，传了30MB就断了。

我重试了一次，还是断。

三、土办法：OTG U盘

我盯着那个停在30MB的文件，叹了口气。

然后我想起了我包里有个OTG U盘。

“还是失败，这样吧，我有个otg设备可以用，已经插到本机了。”我在会话里跟助手说。

接下来的操作，回到了20年前的计算机时代：

  1. 在源设备上找到OTG的挂载点（/mnt/media_rw/F69C43E49C439E4D）。
  2. 把650MB的源码包复制到U盘里。
  3. 拔下U盘。
  4. 走到目标设备旁边（其实就在旁边桌子上）。
  5. 把U盘插到目标设备上。
  6. 找到U盘里的文件，复制到目标设备的home目录。
  7. 校验MD5。

没有网络波动，没有后台杀进程，没有协议栈问题。物理连接，稳如老狗。

四、结果：MD5校验一致

复制完成，MD5校验：

1
2
源文件 MD5: ccae57dbacec900b2b88c2c8cb5c7a52
U盘文件 MD5: ccae57dbacec900b2b88c2c8cb5c7a52

一致。

解压，设置PATH环境变量，重启gateway。

hermes gateway restart

一切恢复。技能、配置、会话记录，全在。

五、感悟：靠谱 vs 可扩展

这次迁移让我对”土办法”有了新的认识。

在网络传输不稳定的情况下，OTG U盘物理传输虽然笨，但它是100%可靠的。只要U盘不坏，文件就不会丢。

但这也暴露了我这套架构的一个问题：全自建，无生产级兜底。

如果这是一台生产服务器，我应该有rsync增量同步、有断点续传、有自动化部署脚本。而不是靠手动打包、手动传U盘、手动设PATH。

土办法靠谱，但不代表它可扩展。

如果有一天Hermes要迁移到第三台、第四台设备，或者需要定期备份到云端，OTG U盘就不够用了。

但至少在那一刻，在这个226GB存储的Android手机上，这个土办法救了我的命。

作者：小道 · 环境：Termux on Android 13 · 2026-09-02
关联阅读：上一篇《22GB到12GB，一次手机空间大清理》 · 下一篇《在手机上跑大模型，HexaBench Lite折腾记》