zmztozmig: sharing, feedback and help

[bhwong]

Hi,

We have complete our Zimbra to Zimbra migration over the weekend and we would like to share our experience and how we resolve the varies problems we encounter. WE also like to feedback on the varies issues we think can improve the migration process as well as seeking for advise if there are already solutions we are not aware of. So here it goes:

1. On the source Zimbra, we export all the accounts into csv file. We remove the accounts that are not require in the migration and amend them into 3 columns: email, display name, password - so that we can import this csv file into destination Zimbra

2. Next, we amend our MX record to point to our destination Zimbra public IP. Since the MX record take up to 4 hours to take effect, we remove the source Zimbra on the next day to ensure that we receive all emails. This is because during the MX record updating, incoming emails will get delivered to either Zimbra servers, depending on whether our MX record got updated at their side when they send out their emails.

3. To speed up the migration process, we move the source Zimbra server to the same physical location of our destination Zimbra server so that the transfer occur within the 100Mb network instead of over the internet connection with upload speed of only 768kb.

4. We have about 80GB of data to migrate to our destination Zimbra that has about 100GB of free space. About 5 hours after we run the zmztozmig script, we received email alert that our destination Zimbra storage is 87% full. We quickly activate HSM to move newly import accounts content over 6 month old to our secondary storage to prevent our primary storage from getting filled up.

Q: Is there a way to pause the importing script to clear our primary storage? We use Fortigate traffic shaping to slow down the network port used for importing. Unfortunate this cause a few accounts to fail in importing due to Fortigate stupid implementation of dropping packets to meet the restricted bandwidth instead of slowing down the bandwidth.

5. We have to keep rerun HSM as our primary storage hit over 95% during the importing process. We notice that the redo.log files are actually the main reason why our primary storage is insufficient despite there is 20GB spare buffer to migrate the accounts.

6. We have no choice but to remove these log files which result in receiving an email alert that our backup has fail. We proceed to do a full backup instead since incremental backup is useless without the redo.log

Q: Can we safety remove all incremental backups and tick auto-group?

7. We also realize that the migrated emails are marked as unread and outlook will download all the duplicates again. Tick download email from now is helpful but this mean the weekend emails will not get downloaded.

Q: Is there a way to download email from 2-3 days ago instead of from now?

We have to manually import aliases, distribution lists and re-share our folders and email rules. Document didn't work immediately but works the next day. Need time to reindex the broken links?

[stiller]

We have also found that we manually needed to set email rules, shares and external accounts. Is there any way to get these in the tar formatter?

We don't always have root access to the source host, so we can't do LDAP to LDAP.