• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • backup-plugin
    • None
    • Tomcat 6.0.18, running on JVM 1.5, on MacOS X, 10.5.8

      All I'm trying to do is create another Hudson instance, on another machine, and bring all the configurations from one machine to the next (as I'm going to mothball the old machine some time). So, I figured I would run "backup" to backup the configuration, and then copy that backup file to the new machine, and "restore". (If this approach is wrong, please let me know).

      I do NOT want to back up the workspaces and all the sources, just the configuration info, and all of the jobs' configurations. It shouldn't be that much, actually.

      In any case, Hudson is working really, really hard and taking a lot of time to do this task. It's been going for minutes and there is nothing in the backup folder yet.

      If you have any idea about how this might be fixed, (or what I can do differently) please let me know.

          [JENKINS-5669] Hudson backup doesn't do anything

          cahylles added a comment -

          Check the permissions on the directory you're attempting to write.

          cahylles added a comment - Check the permissions on the directory you're attempting to write.

          dan_morrow added a comment -

          I checked the permissions, and they are fine. And if they weren't, shouldn't it fail immediately instead of trying to do something for a long time with no results?

          Here's the weird part. If I run "top" I can see that java is using 90% of the processor. So, again, it looks like it's doing something, despite evidence to the contrary.

          The last line in my tomcat log file reads:
          Apr 21, 2010 9:01:11 AM org.jvnet.hudson.plugins.backup.BackupLink doLaunchBackup
          INFO: backup file name = /Users/hudson/hudsonbackup/backup_20100421_0901.tar.gz (generated from template :/Users/hudson/hudsonbackup/backup_@date@.@extension@)

          I'm doing this on a Mac (which shouldn't matter), everything else about hudson works fine. I'm using tar.gz as my compression format. No checkboxes are checked.

          Are my expectations invalid? Should it take several minutes to do this? Since I'm just backing up the configurations of the jobs, I would think that this should take less than a minute, but maybe I'm missing something.

          Again, any help would be greatly appreciated.

          dan_morrow added a comment - I checked the permissions, and they are fine. And if they weren't, shouldn't it fail immediately instead of trying to do something for a long time with no results? Here's the weird part. If I run "top" I can see that java is using 90% of the processor. So, again, it looks like it's doing something, despite evidence to the contrary. The last line in my tomcat log file reads: Apr 21, 2010 9:01:11 AM org.jvnet.hudson.plugins.backup.BackupLink doLaunchBackup INFO: backup file name = /Users/hudson/hudsonbackup/backup_20100421_0901.tar.gz (generated from template :/Users/hudson/hudsonbackup/backup_@date@.@extension@) I'm doing this on a Mac (which shouldn't matter), everything else about hudson works fine. I'm using tar.gz as my compression format. No checkboxes are checked. Are my expectations invalid? Should it take several minutes to do this? Since I'm just backing up the configurations of the jobs, I would think that this should take less than a minute, but maybe I'm missing something. Again, any help would be greatly appreciated.

          dan_morrow added a comment -

          One more comment,

          The last line in "backup.log" reads:
          Full backup file name : /Users/hudson/hudsonbackup/backup_20100421_0920.zip

          I don't know what is meant by "full backup" here, but I don't want to back up an files, just configurations.

          dan_morrow added a comment - One more comment, The last line in "backup.log" reads: Full backup file name : /Users/hudson/hudsonbackup/backup_20100421_0920.zip I don't know what is meant by "full backup" here, but I don't want to back up an files, just configurations.

          Romain Seguy added a comment -

          Does this issue still happen with recent releases of the plugin? Are you not indeed facing the issue described in JENKINS-8282? Can you make a try using ZIP?

          Romain Seguy added a comment - Does this issue still happen with recent releases of the plugin? Are you not indeed facing the issue described in JENKINS-8282 ? Can you make a try using ZIP?

          Romain Seguy added a comment -

          Unassigning myself from this plugin, no time to work in it, sorry.

          Romain Seguy added a comment - Unassigning myself from this plugin, no time to work in it, sorry.

            Unassigned Unassigned
            dan_morrow dan_morrow
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: