Once in a while, wither due to untimely reboot or due to NAS location for backups running out of space, I see severely under-sized ZIP flies which often even appear valid (no CRC error) in the ThinBackup directory. Like a series of 45Gb archives interspersed with 20-somethings.

Looking at https://github.com/jenkinsci/thin-backup-plugin/blob/master/src/main/java/org/jvnet/hudson/plugins/thinbackup/backup/DirectoriesZipper.java I think the issue is that handleFile() adds each object into zipstream separately, so after each transaction the archive is valid. However this does not guarantee that the archive is complete vs. original directory, if the compression loop got interrupted.

When I was taught to make backup scripts, the general approach was that this takes time and space and is prone to failure as an expected event, so the archive files being written were to be named as such - e.g. something.zip._WRITING_ until the logic is done and marks that by renaming it to the final name like something.zip. This allows to quickly see if some backup sessions got aborted (if fuser or file size changes over time do not point to anyone still writing there), and at least clean up space by dropping useless blobs.