Zimbra NG Modules/Zimbra NG Backup/zxbackup-migration
- This guide describes how to perform an Incremental Migration using ZeXtras Backup.
- 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.
- All the CLI commands in this guide must be executed as the Zimbra user unless otherwise specified.
What will be migrated
- Emails and Email Folders.
- Contacts and Address Books.
- Appointments and Calendars.
- Tasks and Tasklists.
- Files and Briefcases.
- Share informations.
- User Preferences.
- User Settings.
- Class of Service Settings.
- Domain Settings.
What will NOT be migrated
- 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.
FAQs and Troubleshootings
Please carefully read the ZxBackup Troubleshooting and the ZxBackup FAQs pages before running an incremental migration
- The source server: any Zimbra server can be the source of your migration, as long as the running Zimbra version is 6.0.7 or higher.
- The destination server: any Zimbra server can be the destination of your migration, as long as the running Zimbra version is 6.0.7 or higher.
Be sure to have root access to both servers, and have a look at "ZxBackup: External Restore - Before you start" for some import performance tips.
- On the Source server: If ZeXtras Backup 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 algorythm, and all zimbra items are deduplicated, usually reducing the size of exported to the 70% of the original size).
- On the Destination server: Make sure you have an amount of free space greater than the size of the /opt/zimbra/store/ and of the "export" folders on the source server combined
While you can choose to transfer the data in any other 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 network, carefully plan your transfer in advance so that you'll have transfered all of your data before migrating.
Alternative Ways to transfer your data Anything spanning from remote mount to physical move of the drive is ok as long as it suits your needs.
Set the TTL value of your MX record to 300 on your "real" DNS. This will allow a fast switch between source and destination server.
Step 1: Coherency checks
In order to avoid any possible data-related issue, run the following checks on the source server:
- zmblobchk: this command checks the consistency between Zimbra's metadata and BLOBs.
- zmdbintegrityreport: this command 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.