32位Jenkins 2.227升级64位2.235.3后数据丢失求助

问题背景 #

当前环境与已执行操作：

• 原32位Jenkins版本：2.227，安装路径C:\Program Files (x86)\Jenkins
• 目标64位版本：2.235.3，安装路径C:\Program Files\Jenkins
  已完成步骤：

1. 安全关闭Jenkins并禁用Windows服务（启动类型设为禁用）
2. 备份整个C:\Program Files (x86)\Jenkins文件夹
3. 下载对应版本的64位Windows安装包
4. 执行安装程序完成64位版本安装
5. 复制旧安装目录下的*.xml文件及fingerprints/、nodes/、userContent/、jobs/、plugins/、secrets/目录到新安装路径
6. 复制Java 11 JDK到C:\Program Files
7. 修改jenkins.xml和config.xml中的JDK版本为Java 11
8. 修改config.xml中的Jenkins版本为2.235.3

问题现象：启动64位Jenkins后进入初始设置界面，完成设置后无任何历史构建数据，如同全新安装。

可能遗漏的关键操作 #

1. 未确认JENKINS_HOME真实路径
   Windows下Jenkins的核心配置、构建数据、插件数据默认存储在JENKINS_HOME目录，而非安装目录。你可能误将安装目录的文件当作核心数据复制，但实际数据可能在C:\Users\<你的用户名>\.jenkins或旧jenkins.xml中-DJENKINS_HOME=xxx参数指定的路径。需先定位原32位Jenkins的真实JENKINS_HOME，再迁移该目录的完整内容。

2. 安装64位版本时未指定JENKINS_HOME
   运行64位安装程序时，若未手动指定JENKINS_HOME为原数据目录，安装程序会自动创建新的空目录，导致启动时加载全新配置。

3. 文件复制权限不足
   复制文件到C:\Program Files\Jenkins时，可能因Windows权限限制导致部分配置文件未被正确覆盖，或Jenkins服务账户（通常为Local System）无读取权限。需确保新目录下所有复制文件拥有服务账户的读写权限。

4. 不必要的config.xml版本修改
   手动修改config.xml中的Jenkins版本号会干扰系统自动升级逻辑，Jenkins启动时会自行检测版本并完成适配，无需手动修改该字段。

32位转64位Jenkins标准升级步骤 #

1. 备份完整核心数据

   • 安全关闭Jenkins服务，禁用服务启动类型
   • 查看旧jenkins.xml的<arguments>标签，找到-DJENKINS_HOME=xxx参数，定位真实核心数据目录，备份整个目录
   • 备份原安装目录下的jenkins.xml（用于参考JVM参数、服务配置）

2. 配置64位Java环境

   • 使用官方安装程序安装Java 11 64位JDK，确保环境变量配置正确，路径例如C:\Program Files\Java\jdk-11.x.x
   • 避免直接复制JDK目录，防止环境变量、注册表配置缺失

3. 安装64位Jenkins

   • 下载对应版本的64位Windows安装包
   • 运行安装程序时：
     • 指定JDK路径为Java 11 64位的安装目录
     • 手动设置JENKINS_HOME为备份的原核心数据目录
     • 暂不启动Jenkins服务

4. 迁移并验证配置

   • 对比新安装目录下的jenkins.xml与旧文件，确保JVM参数（如-DJENKINS_HOME、-Xmx等）配置正确，替换Java路径为64位Java 11的路径
   • 无需修改config.xml中的版本号

5. 设置目录权限

   • 右键JENKINS_HOME目录→属性→安全，添加NT AUTHORITY\SYSTEM账户并赋予完全控制权限，确保Jenkins服务可正常读写数据

6. 启动与验证

   • 启用Jenkins服务并启动
   • 访问Jenkins URL，检查原配置、构建历史、插件是否正常加载
   • 若启动失败，查看JENKINS_HOME/logs目录下的日志定位问题

内容的提问来源于stack exchange，提问作者Paradox