[halo-pro] 备份恢复时会将 compose.yaml 覆盖为备份时的旧版本

[junyuyuan]

前置条件

• 已经在 issues 列表中搜索了相关问题。
• 这是 Halo 项目本身存在的问题。
• 已经尝试过停用所有的插件，排除是插件导致的问题。
• 如果是插件和主题的问题，请在对应的插件和主题仓库提交。

环境信息

系统信息

• 版本: halo-pro:2
• 运行方式: Docker Compose
• 数据库: PostgreSQL

使用的哪种方式运行？

Docker Compose

详细信息

发生了什么？

Halo 的备份功能会将整个 ~/.halo2 数据目录（或挂载路径下的所有内容）打包备份。由于 compose.yaml 存放在被挂载为 /root/.halo2 的宿主机目录中，备份包内也包含了 compose.yaml。

在执行恢复操作时，备份包内的旧 compose.yaml 会覆盖宿主机上当前正在使用的 compose.yaml，导致已经手动修改过的配置（如端口、外部访问地址、密码、挂载路径等）被还原为备份时的旧版本。

预期行为： 备份和恢复应只处理 Halo 应用数据（数据库、上传文件、主题、插件等），不应包含部署配置文件（compose.yaml / docker-compose.yml）。

复现步骤

1. 使用 Docker Compose 部署 Halo，compose.yaml 存放在被挂载为 /root/.halo2 的宿主机目录中
2. 在 Console 后台执行一次完整备份
3. 修改 compose.yaml（例如修改端口或 external-url）
4. 在 Console 后台使用第 2 步的备份执行恢复
5. 观察宿主机上的 compose.yaml —— 已被还原为备份时的旧版本

相关日志输出

无报错，恢复流程正常完成，问题为静默覆盖文件。

附加信息

挂载配置示例：

volumes:
  - /volume1/docker/halo:/root/.halo2

compose.yaml 与应用数据位于同一宿主机目录，因此备份时被一并打包。

建议修复方案（供参考）：

1. 备份时在文件列表中明确排除 compose.yaml / docker-compose.yml / docker-compose.yaml；
2. 或者在文档中明确建议用户不要将 compose.yaml 存放在被挂载的数据目录内；
3. 恢复时对非 Halo 应用数据文件（如 *.yaml 部署配置）跳过覆盖或给出警告提示。

[ruibaby]

在文档中我们应该都是将 halo2 文件夹单独存放的，https://docs.halo.run/getting-started/install/docker-compose

这个问题我感觉没有太强的理由将 compose.yaml 放在排除列表中。