How to Migrate Your Zimbra Servers Using Zextras Suite Backup | Zimbra

How to migrate Zimbra using Zextras Backup

Learn how to migrate Zimbra: Zextras Migration Tool is no longer available, this guide will help you to perform a migration using Zextras Backup.

Some Features

• It’s specifically designed for a production environment.
• It is designed to run test simulations/migrations, which by the way we suggest running

Please note that all the CLI commands in this guide must be executed logged in as the Zimbra user unless otherwise noted.

What Will be Migrated?

• Email and email folders
• Contacts and address books
• Appointments and calendars
• Tasks and task lists
• Drive Files
• Share informations
• User preferences
• User settings including password, identities and signature
• Class of Service settings
• Domain settings, including domains certificate

What Will NOT Be Migrated?

• Server configuration
• MTA / Proxy config
• Customization like banners, logos, etc
• LDAP configuration

Scenarios

Depending on the number of mail stores in the source and in the destination infrastructure several scenarios could occur:

• Starting from one server and arriving to one (The one you will find in this article)
• Starting from “n” servers and arriving to one
• Starting from one server and arriving to “n” ones
• Starting from “n” servers and arriving to “m” ones (eg. from 5 to 3)
• Migration of only one subset of domains

To describe the process in a clear way, this article will cover the first one, even if the same logic could be applied to other scenarios and will be covered in future articles.

Destination infrastructure must be installed and operating (in particular LDAP, NGINX, MTA).

Some Checks Before Starting the Migration

Servers

As we have seen above, any Zimbra server can be the source of your migration, provided that it’s running Zextras Backup or Zimbra Suite Plus and, at the same time, any Zimbra server can be the destination of your migration, as long as it’s running Zextras Backup.

Storage

Make sure to have an amount of free disk space compared to the size of the /opt/zimbra/store/ folder.

On the destination server, on the other hand, make sure you have more free space than the size of the /opt/zimbra/store/ and export folders on the source server combined. You need space for source backup, store, and destination backup. Here is an example to better explain:

If we have 100GB used by /opt/zimbra/store and 80GB of /opt/zimbra/backup/zextras on the source server , on the destination server we need at least 100GB for /opt/zimbra/store , 80GB for the source backup and additional 80GB for the new /opt/zimbra/backup/zextras

Data Transfer

The easiest method to choose for data transfer is rsync, because it’s a good balance between speed and convenience, although you can choose to do so in any other way.

Transfer can be executed while the source is up and running. Considering the structure of zextras backup, tools like Rsync allow transferring only the delta, allowing an incremental transfer that keeps the source and destination constantly updated.

The main data transfer is executed while the source server is still active and functional; anyway, since the process is performed via the network, be sure to plan your transfer in advance so that all your data have been transferred before migrating.

You can also, for sure, choose alternative ways to transfer your data.

DNS

Set the TTL value of your MX record to 300 on your real DNS. Do the same also on AName/Cname of the WebUI, if the source and the destination must use the same address. This will allow a fast switch between source and destination servers.

Coherency Checks

To avoid any possible data-related issues, it’s important to run the following checks on the source server:

zxsuite powerstore doCheckBlobs – This is going to check the congruity between Zimbra’s metadata and BLOBs

/opt/zimbra/libexec/zmdbintegrityreport -v – This one is used to check the integrity of the Zimbra database.

After these two tests, we will proceed to repair any errors we found, and then we suggest running a reindex of all mailboxes.

Zextras Suite Backup Setup

First of all, make sure that Zextras suite backup is active on the source system.

On the destination server, disable real-time scanner (since it would result in a backup of the backup we are importing and is clearly not needed):

zxsuite config server {server_name} set attribute ZxBackup_RealTimeScanner value false

Please note that it is strongly recommended to have a dedicated device for the data export. This will let you improve the export performance and lower the impact on the performance of the running system.

SmartScan

Now it’s time to run a SmartScan on the source server adding the deep option with the following command:

zxsuite backup doSmartScan start deep true

Then all your data will be exported to the default backup path (/opt/zimbra/backup/).

Data Synchronization

When you move the exported data to the destination server, make sure that the destination folder is not Zextras Backup’s backup path on the destination server to avoid any trouble if you already use Zextras Backup or plan to do so on the destination server.

With rsync, copy the data contained in the /opt/zimbra/backup/ onto a directory in the destination server (please make sure the Zimbra user has r/w permissions on that folder). It’s better to use a terminal multiplexer like screen or tmux and note that the process might need A LOT of time depending on network speed and the amount of data involved.

The following command must be executed as root (and not as Zimbra user):

rsync -avH /opt/zimbra/backup/ root@desinationserver:/path/for/the/data/

Since the source server is active and the realtime scanner enabled, more new data can be added to the backup path. Repeat this operation as many time as needed, to reduce the amount of data to be syncronized in the last step

Import

It’s now time to import all the data we exported to the destination server. The target server is up and running and backup is active with the real-time scanner disabled.

For the first run a Provisioning Only import that will only create Domains, classes of service, and accounts on the destination server, skipping all mailbox contents. This is possible through the following command:

zxsuite backup doExternalRestore /path/for/the/data/ provisioning_only TRUE

After this first step, switch the mail flow to the new server. Now destination server can receive mail and let users log in with their old credentials. In the meanwhile, old emails are being restored.

When it is completed, execute the Rsync another time, to recover the latest email added in the source server, and then will be the time to start the  import of blobs and items:

zxsuite backup doExternalRestore /path/for/the/data/ concurrent_accounts <number>

The concurrent_accounts parameter allows you to restore multiple accounts at the same time, thus greatly speeding up the restore process.

At the end of importing, it is possible to perform additional SmartScan on the source (deep attribute is no longer needed) and another rsync to copy on destination server any other emails arrived during the switch and run again the import command, which will import only the new items.

If you have little data or don’t want to run the two steps, you can switch the MX record and then run everything with just the command below:

zxsuite backup doExternalRestore /path/for/the/data/ concurrent_accounts <number>

Do not edit or delete the backup path after this step

Post-Migration Checks

Now that the migration process is completed, we are going to perform some checks to be sure that everything is working fine.

First of all, we are checking for inconsistencies with shares:

zxsuite backup doCheckShares

In case this command report any inconsistency, we can fix any broken share writing as follows:

zxsuite backup doFixShares

Mapfiles can be found in the Backup Path of the destination server as map_[source_serverID].

Galsync

First of all, delete any imported GalSync accounts from the Zimbra Administration Console and then, if needed, create new GalSync accounts on all the imported domains and resync all the GalSync accounts using the following command:

zmgsautil forceSync -a galsync.randomstring@domain.com -n [resourcename]

Last steps

It is highly suggested to run a Volume Deduplication using the Zextras Suite Powerstore module after migration.

Now that everything is completed and works fine, Initialize Zextras Backup on the new server to make sure all of your data is secure.

TIPS

• How many concurrent? It depends on your system. Our suggestion is to do a test import. It has no impact on the source and will allow you to evaluate the timing and performance of the destination. Start with a value equal to half of the available CPU cores and increase it if performance allows. (also check the disk output)
• DO NOT modify the backup “map” files. If it happens that they become corrupted, it is better to delete the data and re-import the backup, to avoid duplicate items.
• Every time you execute the import, the data of the domain and accounts are overwritten. Therefore in this phase is advisable not to make changes to the domain and do not change the preferences of users. Performing tests beforehand allows you to reduce this window of time as much as possible