-
This guide describes how to perform an Incremental Migration using Backup NG.
-
It’s specifically designed for the migration of a production environment, minimizing the downtime and aiming to be transparent for the users.
-
If correctly planned and executed, your mail system won’t suffer any downtime, and the impact on the users will be close to zero.
-
-
The source server of the migration requires either the Zextras Suite or Zimbra Suite Plus.
-
This guide applies for migrations from any Zimbra version supported by either of those to Zimbra 8.8.
-
-
All the CLI commands in this Guide must be executed as the Zimbra user unless otherwise specified.
-
Email and email folders
-
Contacts and address books
-
Appointments and calendars
-
Tasks and task lists
-
Files and briefcases
-
Share informations
-
User preferences
-
User settings
-
Class of Service settings
-
Domain settings
-
Server settings (migrated for reference but not restored)
-
Global settings (migrated for reference but not restored)
-
Customizations (Postfix, Jetty, etc…).
-
Items moved or deleted during the process will not be moved or deleted on the destination server.
-
Preferences (e.g. passwords) changed during the process will be reset upon each import.
|
Warning
|
The incremental migration is not designed to set up a server-to-server mirroring. Using multiple imports to create a mirrored copy of the source server won’t create a mirrored copy at all, since no deletions are performed by the import process. |
Data from the source server is obtained through either Zextras Suite or Zimbra Suite Plus.
-
Zextras Suite can be obtained on the Zextras Website at https://www.zextras.com
-
Zimbra Suite Plus can be obtained on the Zimbra website at https://www.zimbra.com
Once you obtain either Zextras Suite or Zimbra Suite Plus, follow this installation process:
-
Copy the package to your server, in a directory owned by the root user.
-
Unpack the package using
tar zxf. -
Enter the newly created directory called either
zextras_suite-[version]orzimbra_suite_plus-[version]. -
As root, run the installation script
./install.sh all. -
Follow the installation wizard, accepting the software EULA and installing both the Core and the Zimlet component.
-
Once the installation is complete, proceed with the Guide.
|
Warning
|
Installing Zimbra Suite Plus or Zextras Suite requires a mailboxd service restart, which will be performed during the installation. |
-
Source server: Any Zimbra server can be the source of your migration, provided that it’s running Backup NG or Zimbra Suite Plus.
-
Destination server: Any Zimbra server can be the destination of your migration, provided that it’s running Backup NG.
-
Source server: If Backup NG is not currently enabled on the source server, make sure you have an amount of free disk space comparable to the size of the
/opt/zimbra/store/folder (the exported data is compressed through the gzip algorithm, and all zimbra items are deduplicated, usually reducing the size of exported to the 70% of the original size). -
Destination server: Make sure you have an amount of free space greater than the size of the
/opt/zimbra/store/and of theexportfolders on the source server combined.
While you can choose to transfer the data in any way, rsync is our method of choice as it’s a good compromise between speed and convenience.
The main data transfer is executed while the source server is still active and functional. However, since the transfer is performed via the network, carefully plan your transfer in advance so that you’ll have transferred all of your data before migrating.
Anything spanning from remote mount to physical move of the drive is ok, as long as it suits your needs.
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. --Tanenbaum, Andrew S. (1996). Computer Networks. New Jersey: Prentice-Hall. p. 83. ISBN 0-13-349945-6.
To avoid any possible data-related issues, run the following checks on the source server:
-
zmblobchk: Checks the consistency between Zimbra’s metadata and BLOBs.
-
zmdbintegrityreport: Checks the integrity of the Zimbra’s database.
Repair any error found as described in Zimbra’s official documentation.
Running a reindex of all mailboxes is also suggested.
Disable the Real Time Scanner on both servers:
zxsuite backup setProperty ZxBackup_RealTimeScanner false
|
Warning
|
A dedicated device for the data export is strongly recommended to improve the export performance and to lower the impact on the performance of the running system. |
Any device must be mounted on the /opt/zimbra/backup/ path, and the
Zimbra user must have r/w permissions on it.
Run a SmartScan on the source server:
zxsuite backup doSmartScan
All of your data will be exported to the default backup path (/opt/zimbra/backup/ng/).
You can also choose to only migrate one or more domains instead of all of them. To do so, run the following command instead of the SmartScan:
zxsuite backup doExport /path/to/export/folder/ domains yourdomain.com,yourdomain2.com[..]
Mind that if you start with the SmartScan method, you’ll have to carry
on the migration with such method. If you start with the Single
Domains method ,you’ll have to carry on the migration with this one. The
two methods cannot be mixed.
|
Warning
|
When you move the exported data to the destination server, make sure that the destination folder is not Backup NG’s backup path on the destination server, to avoid any issues if you already use Backup NG or plan to do so on the destination server. |
(You can skip this step if you choose to transfer your data by other means than rsync.)
Using rsync, copy the data contained in /opt/zimbra/backup/ng/ to a directory in the destination server (make sure the Zimbra user has r/w permissions on the folder). Use a terminal multiplexer like screen or tmux. This process command might need A LOT of time depending on network speed and amount of data involved.
[run this command as Root] rsync -avH /opt/zimbra/backup/ng/ root@desinationserver:/path/for/the/data/
While the suggested method is great for high-bandwidth situations, the first synchronization can involve a lot of data. If you feel that the rsync method is too slow, you might consider a physical move of the device (or the proper disk file if running on a virtual environment).
After moving the disk, you can remotely mount it back to the source
server (e.g. via SSHFS), as the additional synchronizations needed for
the migration will involve much less data. In this case, be sure to
remount the device on the source server as /opt/zimbra/backup/ng/
with all due permissions.
Import all exported data to the destination server:
zxsuite backup doExternalRestore /path/for/the/data/
Now sit back and relax while Network NG imports your data on the destination server.
''Warning: Do not edit or delete the backup path after this step.''
If you are to migrate a very large infrastructure where an export/import lasts for hours or even days, there is an alternative way to handle the migration from this point forward.
Instead of importing all of your data to the destination server, you can
run a Provisioning Only import that will only create domains, Classes
of Service and accounts on the destination server, skipping all mailbox
contents.
zxsuite backup doExternalRestore /path/for/the/data/ provisioning_only TRUE
After doing this, switch the mailflow to the new server and, when the
switch is completed, start the real import.
zxsuite backup doExternalRestore /path/for/the/data/
This way, your users will now connect to the new server where new emails will be delivered while old emails are being restored.
This approach has it’s pros and cons, namely:
Pros
-
Since items are only imported once and never modified or deleted afterwards, using this method will result in less discrepancies than the
standardincremental migration. -
This is the option that has less impact on the source server (e.g. good if you are in a hurry to decommission it).
Cons
-
Depending on the timing of the operation, this method has a higher impact on your users due to the fact that items are restored WHILE they work on their mailbox.
-
Since the import is done on a running system, you might notice some slowdowns.
Right now, the vast majority of the data has already been imported to the destination server. The source server is still active and functional, and you are ready to perform the actual migration.
Before switching the mail flow, ALWAYS make sure that the new server is ready to become active (check your firewall, your DNS settings, your security systems etc.).
This is it, the migration moment has come! At the end of this step the destination server will be active and functional.
-
Repeat step 3, step 4 and step 5 (only new data will be exported and synchronized).
-
Switch the mail flow to the new server.
-
Once NO MORE EMAILS arrive to the source server, repeat step 3, step 4 and step 5.
The Destination server is now active and functional.
Run the following command to check for shares inconsistencies:
zxsuite backup doCheckShares
Should this command report any inconsistency, use the following command to parse the import mapfile used as the first argument and fix any broken shares.
zxsuite backup doFixShares
Mapfiles can be found in the backup path of the destination server as
map_[source_serverID].
Delete any imported GalSync accounts from the Zimbra Administration Console, then if needed, create new GalSync accounts on all the imported domains and re-sync all the GalSync accounts with the following command:
zmgsautil forceSync -a [email protected] -n [resourcename]
Running a Volume Deduplication using HSM NG is highly suggested after a migration.
Yes. It can be either a trial License or a purchased one.
Everything except for the server configuration. This includes:
-
User data
-
User preferences
-
Classes of Service configuration
-
Domain configurations
Again, anything that suits your needs is ok. You just need to be very sure about what your needs are.
Do you need to move the data very fast? Physically moving an USB disk between your servers might not be a good idea.
Do you need to move the data in a very reliable way? Mounting the export folder via SSHFS to the destination server might not be a good idea if your internet connection is sloppy.