Strange output from Zimbra self-backup

[mrios]

My self backup seemed to run fine this morning...with one exception noted in the email'd output:
========================================

ERRORS

username@zimbra-domain.anl.gov: link(/opt/zimbra/backup/sessions/full-20101206.080006.671/accounts/ab8/978/ab897865-4eb3-4395-b61f-33568ca381df/blobs/1/8/f8lh5osm4GwcuKzkEbRHHADSTm8=33664-50688.msg1, /opt/zimbra/backup/tmp/full-20101213.080007.969/accounts/ab8/978/ab897865-4eb3-4395-b61f-33568ca381df/blobs/1/8/f8lh5osm4GwcuKzkEbRHHADSTm8=33664-50688.msg1): File exists
java.io.IOException: link(/opt/zimbra/backup/sessions/full-20101206.080006.671/accounts/ab8/978/ab897865-4eb3-4395-b61f-33568ca381df/blobs/1/8/f8lh5osm4GwcuKzkEbRHHADSTm8=33664-50688.msg1, /opt/zimbra/backup/tmp/full-20101213.080007.969/accounts/ab8/978/ab897865-4eb3-4395-b61f-33568ca381df/blobs/1/8/f8lh5osm4GwcuKzkEbRHHADSTm8=33664-50688.msg1): File exists
at com.zimbra.znative.IO.link0(Native Method)
at com.zimbra.znative.IO.link(IO.java:78)
at com.zimbra.common.io.AsyncFileCopier$WorkerThread. link(AsyncFileCopier.java:173)
at com.zimbra.common.io.AsyncFileCopier$WorkerThread. run(AsyncFileCopier.java:121)

========================================

Can anyone shed any light on what this means and what action(s) I might need to take?

Ubuntu Hardy 64-bit
Release 6.0.8_GA_2661.UBUNTU8_64 UBUNTU8_64 NETWORK edition.
(patches applied)

Thanks!
mike r.

[iway]

We had the same error on 6.0.9 some weeks ago. Zimbra support said it was temporary and a new backup should fix the problem. Hope this helps for you:

[[[[
My initial guess is this similar to the scenario in bug 49717. I'd have to run some tests to make sure, but consider the scenario in comment #4 of bug 49717, except the backup is running in noZip mode. Copied from the bug:

<quote>
Now for the explanation of how the same blob can be added twice, consider this
scenario:

1. Full backup of a mailbox starts.
2. Mailbox is locked to prevent changes and the current change id is noted.
3. Mailbox is unlocked.
4. Blobs are backed up with mailbox unlocked.
5. Let's pick a blob that's backed up early in this stage. Call it blob X.
6. User makes a change to item X, for example marking a message read.
7. Blob backup finishes after a while.
8. Mailbox is locked to prevent further changes.
9. Blobs are backed up for all items changed since the change id in step 2.
Notice this will include blob X. The change was in the metadata only and so the blob file didn't change. But the backup code doesn't know the nature of the change and must add the blob to backup again.
</quote>

When backup is running in zip mode, adding the same blob the second time works. But in noZip mode, combined with hard linking to blobs from last week's backup, the second backup of the blob becomes link call with pre-existing destination, which fails. Backup will have to check for this condition and ignore the expected error. (Or check for existence of destination path before every single link call, which is more expensive.)

This is not a regression. Chances are, it'll work if they just run backup again. They can work around the issue by running in zip mode, but they probably hhave a reason for choosing the noZip mode.
]]]]