单机版迁移方案

本文介绍将 vika 单机版从服务器 A 迁移到全新的服务器 B。采用停机迁移：A 停止所有 vika 服务后打包，B 恢复并测试通过，再将访问入口切换到 B。迁移期间业务暂停，A 的原目录和迁移压缩包均保留作为备份。

以下以安装目录 /data/vikadata 为例，A、B 使用相同路径。B 应满足服务器配置要求，并预留压缩包、解压数据及镜像所需的磁盘空间。命令以 root 或具备相应权限的账号执行。

本流程适用于应用配置、数据和安装所需文件均位于 vikadata 目录内的单机安装包。若另有目录外的数据或外置存储，需同时确认其迁移或连接方式。

1. A 停服，打包 vikadata 并保留备份

先通知用户停机维护，暂停外部接口、同步任务等写入，然后在 A 上停止全部 vika 服务：

cd /data/vikadata
docker-compose stop -t 120
docker-compose ps -a

stop -t 120 保留原容器，并给服务最多 120 秒正常退出，便于检查停服状态和日志。也可以使用 docker-compose down -t 120，它会停止并删除容器及 Compose 网络；本方案安装目录内的 bind 挂载数据仍然保留。不要添加 -v，以免删除数据卷。无论使用哪种方式，都需确认数据库等服务正常退出后再打包。

使用 docker compose 插件的环境，将本文的 docker-compose 替换为 docker compose。

# 在 A 执行，将完整目录（包括隐藏文件和数据）打包到目录外
cd /data
tar -czpf vikadata-migration.tar.gz vikadata

# 生成校验文件，供 B 检查传输是否完整
sha256sum vikadata-migration.tar.gz > vikadata-migration.tar.gz.sha256

保留 A 上的 /data/vikadata 原目录及 vikadata-migration.tar.gz 备份，不删除、不覆盖原数据。如果已有同名迁移包，请先另存旧包或为本次备份使用不同文件名。迁移和测试期间，A 保持停服。

2. 将 tar.gz 拷贝到 B

在 B 上创建目录：

mkdir -p /data

需要将 A 上的以下两个文件完整传到 B 的 /data/：

• /data/vikadata-migration.tar.gz
• /data/vikadata-migration.tar.gz.sha256

3. B 解压到相同目录，执行安装脚本

在 B 上先检查压缩包完整性：

cd /data
sha256sum -c vikadata-migration.tar.gz.sha256

输出 OK 后继续；校验失败时重新拷贝。B 为全新服务器，解压前确认不存在已初始化的 /data/vikadata，避免混入其他数据。

# 在 B 执行，恢复后的路径与 A 相同：/data/vikadata
cd /data
tar -xzpf vikadata-migration.tar.gz
cd /data/vikadata
bash install.sh

install.sh 会安装 Docker、加载镜像等，按脚本提示完成安装；如提示输入 License，使用有效授权码。这里使用从 A 一起打包过来的安装脚本和文件。

安装结束后查看服务状态：

cd /data/vikadata
docker-compose ps -a
# 如启动异常，查看日志
docker-compose logs --tail 100

4. 打开 B，测试登录和原有数据

通过 http://B的IP 及实际配置的端口访问。若原环境依赖域名或 HTTPS，可先在测试电脑的 hosts 中将原域名指向 B，再使用原域名测试。

• 使用原账号登录，确认登录正常。
• 检查原有空间、成员、表格和记录，确认数据仍在且内容正确。
• 打开原有图片、附件并测试下载，确认文件可访问。
• 检查实际使用的功能及第三方集成是否正常。

测试通过后再切换正式入口。若登录失败或数据不完整，先检查安装日志、数据目录及配置，A 的原数据和压缩包继续保留。

5. 将 DNS 等访问入口指向 B

若原来通过域名访问，将 DNS 记录更新为 B 的 IP；如使用负载均衡、反向代理或端口转发，同时将对应后端地址切换到 B，并确认业务端口和 HTTPS 证书配置正确。

等待解析生效后，通过正式访问地址再次检查登录和数据，确认请求已到达 B，再通知用户恢复使用。迁移完成后，A 保持停服，原目录和压缩包保留备份。