Jenkins Backup Restore: Uncertain Plugin Config Order

Goal: Verify Integrity of Restored Jenkins Data

After restoring a $JENKINS_HOME backup, the primary objective is to confirm that all job configurations, build logs, and artifacts are present and match the pre‑backup state. This involves ensuring that plugin JARs and their corresponding configuration files are correctly aligned.

Constraints and Unresolved Behavior

Restoration must use the same Jenkins core version and plugin set as the source environment to avoid binary incompatibilities. However, the documentation does not specify whether plugin configuration XML files should be copied before or after their JAR files. Restoring configs first may reference classes that are not yet loaded, leading to missing dependencies or runtime errors, while restoring JARs first might leave configuration files pointing to outdated or incompatible plugin versions.

Because this ordering can affect startup success and job functionality, it is an open decision in the current Jenkins backup strategy.

Specific Questions

1. In a typical Jenkins restore, should plugin configuration files be copied into $JENKINS_HOME before the matching plugin JARs, or vice versa, to minimize load errors?
2. What evidence or test results would demonstrate that one ordering consistently yields a fully functional Jenkins instance across multiple plugin versions?
3. Is there any Jenkins core or plugin feature that can enforce or validate the correct sequencing automatically during a restore?