1Panel V1 升 V2：命令行迁移能省事的部分，和它救不了的部分

我的服务器面板是 1Panel V1 装上就没动过，直到 V2 的应用商店里我开始找不到想要的镜像，才想着该升了。问题是我那台机器上有七个站、四个数据库和一堆定时任务，进 Web 界面点「升级」这个动作我一直不太敢按 —— 怕它中途卡住，怕恢复不了。

后来翻到官方有个命令行迁移工具 1panel-migrator，说是专门给 V1 转 V2 用的。我先在测试机上跑了一遍，才敢在生产机上动手。这篇把过程和我踩到的东西写下来，包括几个官方文档里写得比较轻描淡写的地方。

先确认它管不管你要做的事

这个工具的名字容易让人误会。它只解决跨大版本的问题：

V1.10.29-lts 及以上 → V2 最新稳定版，这是它的主场
V2.0.1 → V2.0.2 这种内部小版本，别用它，回面板点升级更稳
V1.10.29-lts 以下的版本，得先通过 V1 面板升级到支持版本，工具会直接报 Current version v1.9.0 is not supported for migration

还有一点得说清楚：它只认 1Panel。别的面板想迁过来，工具帮不上忙。

门槛和备份，别省

动之前的检查清单我列在这里，因为这几步省了，后面就是拿生产环境赌运气：

1
1panel version   # 确认 ≥ v1.10.29-lts

备份对象	怎么做	丢了会怎样
服务器快照	云控制台	回滚的唯一快速通道
面板数据	V1 面板的备份功能	站点、数据库、配置全在里面
网站文件	`/data/wwwroot` 手动打包	静态资源与上传内容
数据库	`mysqldump` 或面板导出	应用数据

磁盘还要留 5GB 以上临时空间，架构只支持 amd64 和 arm64。我的测试机是 ARM 的，一开始下载错了包，--version 直接报格式错误，换成 -arm64 版本才对。

三步走，顺序不能乱

1
cd /tmp
2
wget https://gitee.com/fit2cloud-feizhiyun/1panel-migrator/releases/download/v2.0.6/1panel-migrator-linux-amd64
3
chmod +x 1panel-migrator-linux-amd64
4
sudo mv 1panel-migrator-linux-amd64 /usr/local/bin/1panel-migrator
5
1panel-migrator --version

第一步 sudo 1panel-migrator upgrade core，它会停掉当前的 V1 服务、开始数据迁移，中间要你输 y 确认。第二步 sudo 1panel-migrator upgrade website，处理 OpenResty 和网站配置文件。

中间那条界线很重要：必须等 core 完全跑完、没有报错，再执行 website。我第一次跑的时候看它输出停了十几秒，以为卡死了，直接 Ctrl + C，结果只能从快照重来。给点耐心，别抢在它前面。

真要串起来跑，脚本大概是这个样子：

1
#!/bin/bash
2
set -e
3
cd /tmp
4
wget -q https://gitee.com/fit2cloud-feizhiyun/1panel-migrator/releases/download/v2.0.6/1panel-migrator-linux-amd64
5
chmod +x 1panel-migrator-linux-amd64
6
sudo mv 1panel-migrator-linux-amd64 /usr/local/bin/1panel-migrator
7

8
sudo 1panel-migrator upgrade core
9
sleep 30
10
sudo 1panel-migrator upgrade website

set -e 是必须的。中途任何一步返回非零就停下，不要带着半迁移的状态往下走。

命令跑完之后，才是真的开始

这一段是我觉得官方文档写得太含蓄的地方。工具只负责把数据搬过去，搬完之后有几样东西是不会跟着过来的：

数据项	迁移后状态	怎么办
许可证信息	被清除，变社区版	重新授权
备份记录	不保留	重建备份计划，并手动跑一次验证
快照记录	不保留	重建快照策略
计划任务	任务配置保留，执行记录丢失	逐个确认触发时间还对

最麻烦的是 PHP。V2 重构了 PHP 环境的管理方式，升级完成后原有 PHP 环境会被移除，所有 PHP 站会短暂变成「静态网站」模式 —— 页面还在，跑 PHP 的部分全挂。这时候得进 V2 面板新建 PHP 运行环境，再把每个站切回 PHP 模式。

我那次有四个站是 PHP 的，逐个切完大概花了二十分钟。如果你是 WordPress、Typecho 这类重 PHP 的站多，动手前先把每个站用的 PHP 版本记下来，别到 V2 里再猜。

四类报错，和它们真正的意思

1
Error: Current version v1.9.0 is not supported for migration

版本不够。先用 V1 面板升到 v1.10.29-lts 以上，别想着跳过。

1
Error: failed to pull image xxx: timeout

拉镜像超时。配个加速器再试：

1
sudo tee /etc/docker/daemon.json <<-'EOF'
2
{
3
  "registry-mirrors": ["https://docker.1panel.live"]
4
}
5
EOF
6
sudo systemctl restart docker

1
Error: permission denied

忘了 sudo，或者 /usr/local/bin 不可写。顺便确认 Docker 服务是活的。

1
Error: no space left on device

临时空间不够。清 /tmp，再用 df -h /opt/1panel 看真实数据目录 —— 很多人卡在这里是因为 /opt 和 / 不是同一个分区。

我的实际选择：迁完，重装

说个可能不太讨喜的结论。我第一次是老老实实按迁移流程走的，跑完进 V2 面板，站点能开，数据库连得上，但老配置留下的东西太杂 —— 自定义的 Nginx 片段、几个废弃的证书续签任务、V1 时期的插件残留。

想了一晚上，最后还是做了个更彻底的决定：先跑迁移工具保住数据，然后重装系统装干净的 V2。Debian 13 装上，bash -c "$(curl -sSL https://resource.fit2cloud.com/1panel/package/v2/quick_start.sh)"，再按迁移出来的站点清单一个个重建。

多花了一个半小时，换来一个我知道每一处配置为什么存在的面板。如果你的 V1 配置本来就比较乱，这个选择可能比「迁过去就完事」更划算。

验收清单

不管走哪条路，升级完这几项要过一遍：

V2 面板能正常访问，端口和 V1 不冲突
每个站点都能开，PHP 站确认已切回 PHP 模式
数据库连接正常，应用能读写
计划任务列表在，触发时间对
文件属主和权限没被改掉
证书自动续签能跑通

监控上，systemctl status 1panel-core、df -h、free -m 这三条留一天，观察够 24–48 小时再拆掉旧快照。

最后

迁移工具这类东西，省的是敲命令的时间，省不了「重新理解自己机器」的时间。我那次真正的收获不是省下的一小时，而是重装时逼着自己把七个站逐个过了一遍 —— 发现有两个站早就没人访问，还有三个的证书是手动续的，一直靠运气没过期。

工具能搬走数据，搬不走这些。

1Panel V1 升 V2：命令行迁移能省事的部分，和它救不了的部分