That error happend to us some time ago, but not recently,
Last time this occured we were using Oracle JRE 1.8.0_25 as it seems..

ls -l /opt/jenkins_backup
insgesamt 229336
rw-rr- 1 tomcat tomcat 204881920 Feb 14 12:13 BACKUPSET_2015-02-13_12-00_.zip
rw-rr- 1 tomcat tomcat 4915558 Jun 30 12:01 BACKUPSET_2015-06-29_12-00_.zip
rw-rr- 1 tomcat tomcat 4952374 Jul 1 12:01 BACKUPSET_2015-06-30_12-00_.zip
rw-rr- 1 tomcat tomcat 4990141 Jul 2 12:02 BACKUPSET_2015-07-01_12-00_.zip
rw-rr- 1 tomcat tomcat 5002866 Jul 3 12:02 BACKUPSET_2015-07-02_12-00_.zip
rw-rr- 1 tomcat tomcat 5025237 Jul 5 17:33 BACKUPSET_2015-07-03_12-00_.zip
rw-rr- 1 tomcat tomcat 5027377 Jul 6 12:02 BACKUPSET_2015-07-05_12-00_.zip
drwxr-xr-x 5 tomcat tomcat 4096 Jul 6 12:01 FULL-2015-07-06_12-00

for I in $(ls /opt/jenkins_backup/*.zip); do unzip -q -t $I; done
[/opt/jenkins_backup/BACKUPSET_2015-02-13_12-00_.zip]
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /opt/jenkins_backup/BACKUPSET_2015-02-13_12-00_.zip or
/opt/jenkins_backup/BACKUPSET_2015-02-13_12-00_.zip.zip, and cannot find /opt/jenkins_backup/BACKUPSET_2015-02-13_12-00_.zip.ZIP, period.
No errors detected in compressed data of /opt/jenkins_backup/BACKUPSET_2015-06-29_12-00_.zip.
No errors detected in compressed data of /opt/jenkins_backup/BACKUPSET_2015-06-30_12-00_.zip.
No errors detected in compressed data of /opt/jenkins_backup/BACKUPSET_2015-07-01_12-00_.zip.
No errors detected in compressed data of /opt/jenkins_backup/BACKUPSET_2015-07-02_12-00_.zip.
No errors detected in compressed data of /opt/jenkins_backup/BACKUPSET_2015-07-03_12-00_.zip.
No errors detected in compressed data of /opt/jenkins_backup/BACKUPSET_2015-07-05_12-00_.zip.

Jul 06, 2015 12:01:49 PM org.jvnet.hudson.plugins.thinbackup.backup.BackupSet initializeFromZipFile
SCHWERWIEGEND: Cannot initialize BackupSet from ZIP file 'BACKUPSET_2015-02-13_12-00_.zip'.
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:220)
at java.util.zip.ZipFile.<init>(ZipFile.java:150)
at java.util.zip.ZipFile.<init>(ZipFile.java:164)
at org.jvnet.hudson.plugins.thinbackup.backup.BackupSet.initializeFromZipFile(BackupSet.java:124)
at org.jvnet.hudson.plugins.thinbackup.backup.BackupSet.initialize(BackupSet.java:93)
at org.jvnet.hudson.plugins.thinbackup.backup.BackupSet.<init>(BackupSet.java:79)
at org.jvnet.hudson.plugins.thinbackup.utils.Utils.getValidBackupSetsFromZips(Utils.java:352)
at org.jvnet.hudson.plugins.thinbackup.utils.Utils.getValidBackupSets(Utils.java:371)
at org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.removeSuperfluousBackupSets(HudsonBackup.java:397)
at org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.backup(HudsonBackup.java:154)
at org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork.backupNow(ThinBackupPeriodicWork.java:87)
at org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork.execute(ThinBackupPeriodicWork.java:68)
at org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork$1.run(AsyncPeriodicWork.java:53)
at java.lang.Thread.run(Thread.java:745)

Linking OpenJDK bug report.

I am also getting this error.
Would it be possible to have an option to ThinBackup to have it create .tar files (and possibly also .tgz) instead of .zip files?
As I understand it, .zip is less efficient than .tar because it tries to individually compress each component file before adding to the archive. Whereas .tar creates the archive, which you can then zip all at once, at the end.

is it possible that you are running out of memory? On linux the behaviour of the JVM is exactly that way you described when it allocates more memory than physical memory is available. So may be you have the do big Xmx value for your JVM and system. You could disable compressing the archives in case you do not have enouph memory, or you have the option to reduce the things you add to the backup (e.g. disable to backup the archive).

To be honest I do not work with a Amazone S3 backup so I havn't test it, but I do not think that this migde be an issue.

I had to rebuild my server over the weekend and when I restored my backups using thinBackup subsequent backups were crashing with the same issue in the zip.

This was crashing my Glassfish 4.0 server (which also had my applications running on it - so it was annoying to find it dead each morning....) I have since wiped out my backups folder and manually invoked the backup. I will see if that is now resolving the issue going forward but here it is...

#

1. A fatal error has been detected by the Java Runtime Environment:
   #
2. SIGBUS (0x7) at pc=0x00007f81fd17d982, pid=103003, tid=140195190466304
   #
3. JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13)
4. Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 compressed oops)
5. Problematic frame:
6. C [libzip.so+0x4982] newEntry+0x62
   #
7. Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
   #
8. If you would like to submit a bug report, please visit:
9. http://bugreport.sun.com/bugreport/crash.jsp
10. The crash happened outside the Java Virtual Machine in native code.
11. See problematic frame for where to report the bug.
    #

--------------- T H R E A D ---------------

Current thread (0x00007f8124054800): JavaThread "ThinBackup Worker Thread thread" daemon [_thread_in_native, id=10989, stack(0x00007f81bc76e000,0x00007f81bc86f000)]

siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x00007f81bc0d0a82

Stack: [0x00007f81bc76e000,0x00007f81bc86f000], sp=0x00007f81bc86d220, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libzip.so+0x4982] newEntry+0x62
C [libzip.so+0x4fd3] ZIP_GetNextEntry+0x53
J java.util.zip.ZipFile.getNextEntry(JI)J
J java.util.zip.ZipFile$1.nextElement()Ljava/util/zip/ZipEntry;
j org.jvnet.hudson.plugins.thinbackup.backup.BackupSet.initialize()Z+21
j org.jvnet.hudson.plugins.thinbackup.backup.BackupSet.<init>(Ljava/io/File;)V+115
j org.jvnet.hudson.plugins.thinbackup.utils.Utils.getValidBackupSetsFromZips(Ljava/io/File;)Ljava/util/List;+46
j org.jvnet.hudson.plugins.thinbackup.utils.Utils.getValidBackupSets(Ljava/io/File;)Ljava/util/List;+21
j org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.removeSuperfluousBackupSets()V+32
j org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.backup()V+218
j org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork.backupNow(Lorg/jvnet/hudson/plugins/thinbackup/ThinBackupPeriodicWork$BackupType;)V+83
j org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork.execute(Lhudson/model/TaskListener;)V+44
j org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork$1.run()V+66
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
V [libjvm.so+0x5f8465] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x365
V [libjvm.so+0x5f6ec8] JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*)+0x28
V [libjvm.so+0x5f7197] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x197
V [libjvm.so+0x5f72b7] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x47
V [libjvm.so+0x6731c5] thread_entry(JavaThread*, Thread*)+0xe5
V [libjvm.so+0x94d5ff] JavaThread::thread_main_inner()+0xdf
V [libjvm.so+0x94d705] JavaThread::run()+0xf5
V [libjvm.so+0x815538] java_start(Thread*)+0x108

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J java.util.zip.ZipFile.getNextEntry(JI)J
J java.util.zip.ZipFile$1.nextElement()Ljava/util/zip/ZipEntry;
J java.util.zip.ZipFile$1.nextElement()Ljava/lang/Object;
j org.jvnet.hudson.plugins.thinbackup.backup.BackupSet.initializeFromZipFile()Z+42
j org.jvnet.hudson.plugins.thinbackup.backup.BackupSet.initialize()Z+21
j org.jvnet.hudson.plugins.thinbackup.backup.BackupSet.<init>(Ljava/io/File;)V+115
j org.jvnet.hudson.plugins.thinbackup.utils.Utils.getValidBackupSetsFromZips(Ljava/io/File;)Ljava/util/List;+46
j org.jvnet.hudson.plugins.thinbackup.utils.Utils.getValidBackupSets(Ljava/io/File;)Ljava/util/List;+21
j org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.removeSuperfluousBackupSets()V+32
j org.jvnet.hudson.plugins.thinbackup.backup.HudsonBackup.backup()V+218
j org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork.backupNow(Lorg/jvnet/hudson/plugins/thinbackup/ThinBackupPeriodicWork$BackupType;)V+83
j org.jvnet.hudson.plugins.thinbackup.ThinBackupPeriodicWork.execute(Lhudson/model/TaskListener;)V+44
j org.jvnet.hudson.plugins.thinbackup.hudson.model.AsyncPeriodicWork$1.run()V+66
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub

thanks for the update,

• is the corrupt file a 0 byte file?

my own jenkins running on ubuntu 13.10 and jenkins 1.531 is working fine, i will try to test the system with java 1.6.x now. curretnly I cannot reproduce the problem.

Hello, sorry for the late answer.

No, the zip could not be extracted manually, I get the following error:
jenkins@build:~/Jenkins Backup$ unzip BACKUPSET_2013-10-10_03-00_.zip
Archive: BACKUPSET_2013-10-10_03-00_.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of BACKUPSET_2013-10-10_03-00_.zip or
BACKUPSET_2013-10-10_03-00_.zip.zip, and cannot find BACKUPSET_2013-10-10_03-00_.zip.ZIP, period.

The files are located on the local drive at /var/lib/jenkins/Jenkins Backup/.

Would it be possible to provide non-zipped updates?

I've installed Sun Java 7 1.7.0_45 on the server and I'll come back with results during next weeks backups.

I've uploaded the crash report to: http://pastebin.com/siQCLvwV

could you extract the zip manually? If the zip file itself is the problem please remove it. Where is the file located (network mount, local hdd, local usb mount, raid)?

duplicity copies backups to another location, is it possible that this process modifies the file, maybe something gona wrong during sync.

The problem is I handled the this case, this is why the Warning is logged, I don't know why the JVM crashes. Have you a crash dump of the JVM?

maybe upgrading the JRE to the latest 1.7.0 will help.