There can be a number of reasons for migrating from one mail server to another, the commonest being “running low on disk storage”. Other reasons may include “the need to having a failover mail server” in case of any catastrophic event that may compromise the active email server, among others.
In other words, this same technique can be used to create a clone of your currently running email server to ensure redundancy.
In order to have virtually zero down time, we will proceed as follows :
- Set the DNS TTL Entries pertinent to the mail server to the shortest possible time (Ideally this is done a day before to make sure the ttl propagates accordingly)
- Prepare a fully working new server
- Import all existing domains from the old server.
- Import all existing accounts, passwords, distribution lists, and aliases from the old server
- Move all DNS Pointers and firewall port forwards to the new server (or leave the DNS Pointers as they are, and simply swap the servers’ I.P. Addresses old to new, and new to old. (More about this later)
- Make sure that new mail is arriving on the new server.
- Make sure users are able to connect and use the new server.
- Export Mailbox data from the old server, and import it to the new while the new server is running
1. Preparing the new server
Go ahead and install zimbra on the new server. Make sure to use the same version as that on your old mail server. You can follow the guide here. You will need to setup the new mail server with the same settings as the old server, but with a different IP and domain name.
In case you have more than one domain on your old mail server, create only one main domain on the new mail server as the other domains will be imported automatically during the course of the migration.
Remember that if you intend to install a “letsencrypt” certificate later on (note that this is not covered in this blog), your server name needs to be the same as your http://webmail.domain.com name. It’s commonplace for people to use webmail.domain.com.
Warning : Most of the commands executed during export, and more importantly during import, may take hours. These should be run directly from a console session. If you have absolutely no choice but to run the commands remotely, make sure you use the “screen” command, so that if the connection gets interrupted, you can connect back to your screen, without disrupting any running scripts.
2. The exportation phase
Before we begin the exportation part, we need to make sure we have enough storage space, which can be accessed from both “old” and “new” servers. The old server may have some sufficient space enough for the exportation to be done, but in case it does not, the way to go would be to remote mount an NFS share from the new server (since the new server is technically believed to have sufficient free space), on the old server and use it as the intermediate storage.Other ways include an external usb drive, a network attached storage, etc.