迁移Jenkins工作空间时，很多人会把“工作空间”和“构建历史”混在一起，觉得复制了workspace目录，旧记录也会跟着走。实际情况是，构建历史根本不在workspace下，如果你只动workspace，新环境里历史记录会全部消失。下面把保存构建记录的关键点拆开说。
完整迁移Jenkins历史构建记录，最稳妥的做法是停止服务后整体复制JENKINS_HOME。具体步骤：首先在系统管理→系统配置中确认Jenkins主目录路径；然后停止Jenkins服务（如systemctl stop jenkins）；使用rsync或tar复制整个主目录到新路径，例如rsync -avz /var/lib/jenkins/ 新服务器:/var/lib/jenkins/，注意保持目录权限和属主；最后在新服务器上启动Jenkins。若只想迁移某个任务，可只复制jobs/目录，其中builds子目录包含构建历史和构建日志，workspace子目录无关紧要。复制完成后，需修改Jenkins配置中的workspace路径或直接删除workspace让Jenkins重新检查。建议迁移后先以本地模式启动，…
在Jenkins中，历史构建记录和工作空间属于两种不同的存储路径。工作空间是每次构建拉取源码和编译产物的工作目录，默认为JENKINS_HOME/workspace；而历史构建记录则保存在JENKINS_HOME/jobs//builds/目录下，每个构建号对应一个子目录，内含build.xml、Changelog.xml等元数据文件。迁移工作空间时，如果只移动workspace目录，构建历史不会跟着走，因为Jenkins读取历史时直接访问jobs目录。因此，要保留构建记录，必须将整个JENKINS_HOME或至少jobs目录下的目标任务文件夹一同迁移，而不是单独操作工作空间。建议先查看JENKINS_HOME的实际位置（系统管理→系统配置中的“主目录”），再决定迁移范围。
要不要保留历史记录，得看场景。如果只是换构建机、代码可以重新拉取，那历史记录丢了也不影响后续构建。但如果构建记录里有审计需要的时间戳、测试报告、归档产物，或者团队习惯在旧记录里查“上次失败是因为什么”，那整段history就应该保留。所以先想清楚：这次迁移是为了清空旧环境，还是为了完整搬迁。
操作取舍：整体迁还是只迁任务目录
如果磁盘空间足够，最省事的是停止Jenkins服务后整体复制JENKINS_HOME。因为Jenkins的插件配置、用户权限、指纹文件都在这一个目录里，只搬任务目录容易漏。先到“系统管理→系统配置”里确认主目录路径，再停服务。比如用systemctl stop jenkins。然后用rsync把整个主目录推到新机器：
rsync -avz /var/lib/jenkins/ 目标主机:/var/lib/jenkins/rsync的-a参数能保留符号链接和权限，复制完检查属主。Jenkins运行用户一般是jenkins，如果复制后文件属主变成了root，会报权限错误。执行chown -R jenkins:jenkins /var/lib/jenkins。如果只想迁移某一个任务，可以只复制jobs/下的对应任务目录。其中builds子目录就是历史记录，workspace子目录没有保留价值。复制完任务目录后，任务配置里可能还记着旧的workspace路径，要么手动在配置里改，要么直接删除workspace让Jenkins重建。
整体迁移前，建议先把旧主目录里的jobs目录打一个tar包，放在其他地方。比如tar czf jobs_backup.tar.gz jobs。这样一旦新环境出现权限或路径问题，还能从备份里抽出某次构建记录，不用重头再来。
容易踩的坑：权限、符号链接和绝对路径
迁移构建记录时最容易踩的坑是权限和符号链接问题。Jenkins运行用户（通常为jenkins）需要读写构建记录目录，如果复制后属主变成了root，Jenkins会报权限不足或无法加载历史。解决方法是执行chown -R jenkins:jenkins /var/lib/jenkins/jobs//builds。另一个坑是workspace或builds目录内存在符号链接，比如为加快构建而把大文件目录链接到其他磁盘，直接打包复制后链接可能指向失效路径。检查方法：复制后进入builds目录执行ls -l，查看是否有指向不存在位置的链接；若有，需在目标环境重新创建链接。另外，如果源环境使用NFS等网络存储，构建记录中可能含绝对路径，迁移后若路径未调整，日志和归档引用会出错。建议复制后搜索build.xml中的绝对路径…
搜索时可以用grep -r "/旧路径" /var/lib/jenkins/jobs/来定位。找到后不要盲目全局替换，先看这些路径来自哪个插件。比如JACOCO插件可能把绝对路径写进报告，换了机器后那些路径需要更新，否则报告可能打不开。
迁移后确认历史记录没丢
迁移后如何确认历史构建记录真的保留成功？首先，在Jenkins任务页面左侧的“构建历史”中应能看到所有构建号。点击任意构建号，能打开构建详情页，并显示“控制台输出”和“构建时间轴”。更可靠的方法是直接检查文件系统：登录服务器，进入JENKINS_HOME/jobs//builds/，执行ls -l，确认目录下每个数字文件夹都存在且包含build.xml文件。再执行grep -l 'SUCCESS' build.xml，抽查一个早期构建的结果。此外，可以调用远程API，如http://jenkins/job//1/api/json，若返回JSON数据则说明记录可被读取。若构建记录存在但无法显示，多半是因为permalinks文件中指向的构建号在目录中不存在，此时可删除permalinks文件让Jenkins重新扫…
这里的“重新扫描”会按照builds目录下的实际构建号重建映射。如果删除permalinks后依然不显示，就要检查Jenkins日志里的路径错误。验证时最好抽查最早和中期的构建，而不仅仅是最近一次。因为新环境一般会触发新构建，新构建能生成目录，但早期的目录可能没复制全。
另外，构建记录里的archive目录常被忽略。如果任务配置里启用了“归档制品”，那么builds/<构建号>/archive/保存了可下载的产物。只复制build.xml而漏了archive，构建详情页可能还显示构建结果，但点击“已构建的工件”会报不存在。所以迁移前先看任务配置是否勾选归档，如果勾了，整个builds目录必须完整复制。
风险边界
不建议在Jenkins运行状态下直接复制构建记录。正在写入的build.xml或log文件可能只复制了一半，导致构建详情页报错。迁移前需要停掉所有构建活动，最省事是停服务。如果无法停机，至少要暂停构建队列，并等正在跑的构建结束，但构建结束后可能还会写指纹信息，依然有窗口期。
迁移工作空间和迁移构建记录是两个动作，除非你明确只想移动工作区、不要历史，否则优先整体迁移JENKINS_HOME。迁移完不要急着删旧环境，先在新环境跑一遍验证，确认构建页能打开历史记录，再清理旧数据。如果只迁移了jobs目录，插件数据不完整，某些构建记录可能无法显示，这种情况也要提前和团队讲清楚。