This guide will help you to perform a migration using Zextras Backup, since the old Zextras Migration Tool is no longer available.
- 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 and Briefcases
- 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
Depending on the number of mailstore in the source and in the destination infrastrucutre , 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 process in 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 migration
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.
Make sure to have an amount of free disk space comparable 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
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 source is up and running. Considering the structure of zextras backup, tools like Rsync allow to transfer 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 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.
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.
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
zmdbintegrityreport – This one is used to check the integrity of the Zimbra database.
After these two tests, we will proceed repairing any errors we found and then we suggest to run a reindex of all mailboxes.
Zextras Backup Setup
First of all make sure that Zextras backup is active on source system.
On 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 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 impove the export performance and lower the impact on the performances of the running system.
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/).
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.
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 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 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
It’s now time to import all the data we exported to the destination server. Target server is up and running and backup is active with the realtime scanner disabled.
For 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 mailflow to the new server. Now destination server can receive mail and let users login 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>
concurrent_accountsparameter 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 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
Now that 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
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 firstname.lastname@example.org -n [resourcename]
It is highly suggested to run a Volume Deduplication using Zextras 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.
- 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