Migrating 6.0.10 32 Bits to 8.0 64 Bits

[N1H1]

Hello,

We are trying to migrate to the latest version of zimbra open.
We are using Ubuntu 8.04LTS 32bits and the new server is Ubutu 12.04LTS

By using the migration tool, the backup completes successfully, backup and restore all happens without errors. But note that the size of the mailboxes on the new server take up far less. The large mailboxes, over 6 Gb observed with a size difference in origin and destination of about 150-200 Mb

Example.
Old Server mailbox: 13520 Mb
New Server mailbox: 13280 Mb

Making e-access tests, we don't see emails lost, but we dare not make the change because the new mailboxes may not have all the information.
Apparently all emails have been migrated, but the size does not match

Any way to check?

thanks

[Cine]

Hello N1H1,
welcome to the forums!

A slight difference in the size of the mailbox between the original and imported mailbox can be caused by a different number of factors (invalid items on the source mailbox which have not been imported, old revisions of Documents/Briefcase files etc...).

To verify, run the following command as the zimbra user both on the source and destination server an compare the output files (with `diff --side-by-side file1 file2` or a visual editor of your choice:

zmmailbox -z -m user@domain.com gaf > /tmp/get_all_folders.txt

This command outputs the complete folder hierarchy for the mailbox, along with the size and number of items for each folder.

If you see any differences, check both the Export and Import logs for "No such BLOB" or "Cannot access zimbra file" errors (usually caused by corrupted items in the original mailbox) . Also, check the "Import Complete" notification in order to see if any unrestorable or skipped items are reported.


Have a nice day,
Cine

[N1H1]

I am reviewing the log to find the problem and found the following:

1 - The lg of expor not show any error or warning.
2 - The import log shows several "Skipped item 399 Because It's already mapped". I guess this is why, to what it mailboxes are smaller.
3 - At the end of the log of import appears
2012-11-09 10:25:43,377 [95f39f74-5500-4b1e-8f06-27904a5fae1e] ExternalRestore WARN Unable to rename tag: com.zimbra.cs.mailbox.MailServiceException$NoSuchI temException: no such tag: 258
ExceptionId:ZxBackup Thread:1352453143377:ac18bdf5bffd96ce
Code:mail.NO_SUCH_TAG ArgitemId, IID, "258")
at com.zimbra.cs.mailbox.MailServiceException.NO_SUCH _TAG ( MailServiceException.java:283 )
at com.zimbra.cs.mailbox.MailItem.noSuchItem ( MailItem.java:1636 )
at com.zimbra.cs.mailbox.Mailbox.getItemById ( Mailbox.java:2472 )
at com.zimbra.cs.mailbox.Mailbox.getItemById ( Mailbox.java:2422 )
at com.zimbra.cs.mailbox.Mailbox.getItemById ( Mailbox.java:2413 )
at com.zimbra.cs.mailbox.Mailbox.getTagById ( Mailbox.java:3393 )
at com.zextras.proxy.ZEMailbox.getTagById ( ZEMailbox.java:361 )
at com.zextras.op.backup.ZEExternalRestoreOperation.r estoreItemsFromExternal ( ZEExternalRestoreOperation.java:767 )
at com.zextras.op.backup.ZEExternalRestoreOperation.d oOperation ( ZEExternalRestoreOperation.java:600 )
at com.zextras.op.ZEOperation.exec ( ZEOperation.java:593 )
at com.zextras.backup.ZEBackupThread.execOperation ( ZEBackupThread.java:197 )
at com.zextras.backup.ZEBackupThread.run ( ZEBackupThread.java:107 )

Not how to interpret this error.

Any idea?

[Cine]

Hello H1N1!

the "Skipped item 399 Because It's already mapped" is a warning that is cast when restoring nested folders because of the way ZeXtras Backup maps the mailbox items during the operation. It's an ignorable warning as the target item had already been restored.

Regarding the Tag error, we are aware of some issue in tag restoring... This issues will be fixed in version 1.6.3, please check if the tags for the mailbox being restored when the error is shown have been imported correctly...

About the size decrease, what was the outcome of the procedure I suggested in my previous post? Remember that when migrating from Zimbra 6 to Zimbra 8 documents get "transformed" into briefcase files and Chat logs are not imported, so a difference on that two kinds of item is perfectly normal.


Have a nice day,
Cine

[N1H1]

As a result of the time difference between the exporting and the current situation is not reliable now execute the command and comparing the results.

I will repeat the export process and then implements the command to see the number of items per mailbox.

[N1H1]

I run the command to check the number of items in the mailbox source and the mailbox restored and the result is as follows

SOURCE - RESTORED
23397 /Inbox 22804 /Inbox
9906 /Sent 9340 /Sent
--------------------------------------------------
19204 /Inbox 18532 /Inbox
11863 /Sent 10997 /Sent
--------------------------------------------------
32256 /Inbox 31470 /Inbox
7182 /Sent 6705 /Sent


There are 3 examples of restauration.

As I said above, this result can not bring myself to do the migration.

[Cine]

Hello N1H1,
thank you for the feedback on this issue...

It's really strange that items fail to be imported without any error or at least any warning in the logs, could you please check if the reported data is correct?
You can do so by exporting the same folder of a mailbox (one which number of item differs) both from the old and new server using Zimbra's "Import/Export" feature in the Preferences of the ZWC. Is the number of .eml files exported this way coherent with the output of the "zmmailbox -z-m user@domain.com gaf" commands?

If the difference is confirmed, you can use the `diff` and `ls` commands together to see what files are missing from the export (use a folder comparison utility if you are running the check on a Windows pc).

Have a nice day,
Cine
the ZeXtras Team