Do you have a more detailed stack trace + the Hudson version + the backup plugin version?

Hi

Hudson ver. 1.378

Plug-in version 1.5

Unfortunately, that's all the stack trace I have. If there's a way of forcing java to give more details, please let me know.

INFO: Selected file : backup_20101001_1044.zip
Exception in thread "pool-7-thread-1" java.lang.NoClassDefFoundError: org/jvnet/hudson/plugins/backup/utils/FakeObject
at org.jvnet.hudson.plugins.backup.utils.RestoreTask.run(RestoreTask.java:127)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: org.jvnet.hudson.plugins.backup.utils.FakeObject
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 2 more

At this point it hangs. In hudson, at the bottom of /backup/backup page, you can see:

[ INFO] Making temporary directory the hudson home...
[ INFO] *****************************************
[ INFO] Reloading hudson configuration from disk.
[ INFO] *****************************************

And the spinner below is spinning indefinitely.

At this point in time, hudson home is almost entirely wiped out:
/plugins
/war
hudson.war
queue.xml

In the last case, only the files/directories listed above were left

I don't want to risk trying to restore on my company Linux machine, but I saw that the file structure in the windows backup is different to the linux backup
I'm not sure, but maybe it's somehow connected with this problem.
Let's assume that our backup configuration is without "jobs" in "Custom exclusions" and nothing in "Backup content" is checked.
So under linux in backup file we only have files from home directory.
Under windows we also have sub-directories with their sub-directories, except in /jobs where there are no sub-directories, only files (probably because the workspace in 'Backup content' was not checked).

May you do a try with 1.377 please? 1.378 is a bad release (cf. JENKINS-5977) and I'd like to ensure this has no side effect.

Got the same problem with 1.377, at least on one machine. I can do some more research after the weekend.

I think I found solution.
POM version was very old (1.318) and doReload had different definition then now (it takes no arguments now).

The backup plug-in was also deleting whole HUDSON_HOME directory (or at least whatever it could delete from it) and renaming temporary directory with backup content to HUDSON_HOME.
Since this is hudson-configuration backup (not necessarily whole HUDSON_HOME directory backup) I think better approach is to just replace files that actually are in backup archive, so I used FileUtils.copyDirectory for this.

It works fine on my windows machine now.

It's ok to commit your changes.

Isn't there any older Hudson release (I think of 1.358) to update the POM to, rather than the 1.379 one?

Code changed in hudson
User: : dienomight
Path:
trunk/hudson/plugins/backup/pom.xml
trunk/hudson/plugins/backup/src/main/java/org/jvnet/hudson/plugins/backup/utils/RestoreTask.java
http://jenkins-ci.org/commit/35842
Log:
bumping up POM version to 1.358
[FIXED JENKINS-7634]
using FileUtils.copyDirectory to copy backup files to HUDSON_HOME instead of deleting the directory and renaming temporary one