Results 1 to 2 of 2

Thread: Strange output from Zimbra self-backup

  1. #1
    Join Date
    May 2009
    Rep Power

    Question Strange output from Zimbra self-backup

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

    ERRORS 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 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$WorkerThread. link(
    at$WorkerThread. run(


    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)

    mike r.

  2. #2
    Join Date
    May 2008
    Rep Power


    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:

    Now for the explanation of how the same blob can be added twice, consider this

    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.

    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.

Similar Threads

  1. Replies: 9
    Last Post: 03-01-2008, 07:21 PM
  2. /tmp filling
    By Nutz in forum Administrators
    Replies: 8
    Last Post: 02-22-2008, 01:00 AM
  3. Big Fubar on 5 FOSS GA Upgrade
    By uxbod in forum Administrators
    Replies: 24
    Last Post: 01-21-2008, 02:37 AM
  4. Fedora Core 3, Clean Install - Not working!
    By pcjackson in forum Installation
    Replies: 17
    Last Post: 03-05-2006, 06:38 PM
  5. Mail logs
    By Rick Baker in forum Installation
    Replies: 8
    Last Post: 01-17-2006, 03:33 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts