论坛

+1

您好，两位的状况看起来表面相似（进度条都卡在 76%），但根因不太一样，分开讲：

通用情况 — Clone 流程的 stage 3 (volume copy Job) 悄悄失败了。我们直接连目标服务器看 PVC 内容，只有服务首次启动产生的初始化数据，没有从来源 rsync 过来。对应的 backup/copy Job 也已经 GC 掉，没有残留。Dashboard 进度条停在 76% 是 UX bug，我们会内部追查。

@button (Linode Osaka 1C 2GB)

根因： 目标服务器规格太小。1C 2GB 扣掉 k3s 系统组件之后可用内存大约只有 800MB，volume copy 的 rsync 进程一启动就会被 OOM。

建议：

1. Dashboard → Servers → 这台 Linode → Server Upgrade，升到至少 2C 4GB。
2. 升完之后，先把失败的 n8n-hidae 项目删掉（残留的 namespace 跟 PVC 不会自动清，会占用内存让下次重试更容易失败）。
3. 从源 n8n 项目重新触发 Clone。

@saurlax (Aliyun Beijing 2C 4GB)

您的根因比较可能是 GFW 干扰，不是规格问题：

• 来源是 sha1（上海共享集群），目标是阿里云北京 — 两端都在大陆境内，中间没有跨墙。 • 但 Zeabur 的 clone 流程会经过一些控制面 / staging endpoint，部分节点目前是放在境外的。任何一段过墙的 TCP 连接都会被 GFW 在连接中途静默 reset，backup Job 因此中断，而且重试也不一定会复现。 • 您的目标机 4GB 内存 + PVC 数据量都很正常，没有踩到资源上限。

建议路径（任选）：

1. 手动搬数据（最稳） — 跟 mariadb 用 port forwarding 的概念一样：在来源服务开 port forwarding，从本机跑 mongodump/pg_dump/mysqldump（看您是哪种 DB）pipe 到目标。完全不走 Zeabur clone，跨境问题直接绕过去。
2. 保留项目在 sha1 共享集群不搬 — 如果不一定要搬到专用服务器，共享集群本身运作正常。
3. 如果一定要走 clone，我们会在内部排查跨境 endpoint 的问题，但这个修起来不会很快，不建议您等。

两位重新跑之前麻烦先删掉现在那个失败的目标项目清干净残留，不然下次重试会叠加。重跑后如果还卡，各自贴一下重试的时间点，我们即时去抓 Job 失败原因。

升级后已解决，谢谢。

@button 太好了，感谢您反馈结果。

@saurlax 我已经看到了您的其他几则帖子，会直接在那边回复。这串讨论先关闭，以免信息混在一起。