Moving Zimbra to New Server Hardware
This page describes another rsync method. Zimbra has a wiki full of examples but most have a list of associated issues or trade offs including this that is very similar to what I describe here. Some didn’t work and after painful trial and error, I have come to this simplified version. If you are looking for a method that uses import/export with minimal loss of data, that link appears pretty good as is this link or this link. From my perspective, until Zimbra repairs the REST interface, most of these import/export methods have a high probability of losing data as reported by this long standing bug. The Zextras tool and other IMAP import tools will force your mobile users to delete or update their mobile profiles and to rsync their data. This session from the Zeta Alliance sums up the problem very well around 18:05. The rsync methods do not have this problem.
I have the commercial version of Zimbra and do not generally use its restore from backup capabilities as it has some oddities and takes longer than what I show here. This method described will work with both the open source and commercial versions of Zimbra. The procedure has few commands and does not require looking at a long shell scrIPt to validate. This can run hot without the need to stop Zimbra on your production server and efficiently handles the large 80GB LDAP sparse file. To give you some real world numbers, we have about 100GB of data that makes up our Zimbra production instance and after the initial rsync – subsequent rsync’s take about 60 seconds or less. If we were going to production with this new server, I would shutdown the production server and do one last rsync to capture the latest LDAP database, etc.
You can test the new server with these hot images without shutting down the production Zimbra to work out your process such as an upgrade with this method. We use Linode or Digital Ocean for our test instances. Recently, we paid Digital Ocean 6 cents to rent a properly sized SSD droplet for a few hours to verify a new software upgrade before experimenting on our production server.
Assumptions
- You are running the same operating system and version on both the existing and new Zimbra server
- You don’t want your users to have to reset their mobile profiles and rsync their folders
- You want the fastest method with the least amount of downtime for your users
Summary of Steps
- Verify both servers are at the same OS and patch level. (i.e. yum update)
- Verify that Zimbra is working on the production/existing server before proceeding
- On existing host, lock out the new servers access via firewall (safety step)
- On new host, simulate hostnames by updating /etc/hosts
- On new host, update /etc/resolv.conf to 127.0.0.1 and run DNS server to pretend production server names are the new host
- On new host, install Zimbra software (install.sh -s)
- On existing host, push Zimbra software and all datas via rsync (see below for command)
- On new host, install Zimbra software (install.sh)
- On new host, update new IP address
- Test against new host
- Optional: upgrade or test new Zimbra release
Note: we push from the production/existing Zimbra host because we don’t want the new host to have any interaction with the production/existing host should you forget a step and not update /etc/hosts, etc. It might try and connect to zmhostname for LDAP for example during an upgrade. Having a firewall rule on your production host blocking this new host is a safeguard.
Detailed Steps
Modify /etc/hosts on the new host so that the name of the production server is represented in this new server. In some cases, this can be multiple entries. You must have zmhostname in your /etc/hosts. Run split brain DNS and set the /etc/resolv.conf to 127.0.0.1. Install operating specific software required for a normal Zimbra installation if this is your first time on this hardware. Finally, set the hostname to be exactly the same but that step is optional. I tend to set my shell prompt to remind me that I am on the new host.
As an example, if zmhostname returns mail.example.net then make sure you have an entry like this in your /etc/hosts file with the new servers IP address:
#/etc/hosts
X.X.X.X mail.example.net mail
If you have others server aliases and you want to test those also, add them. For example:
X.X.X.X mail.example.org mail
X.X.X.X mail.example.com mail
Note: After everything is completed, you test it by doing the same trick on your desktop. Add an entry in /etc/hosts so you can verify the new server. Modify /etc/nsswitch.conf if you desktop doesn’t look at files before doing DNS lookups.
Step 1: On new machine install just the Zimbra software
% wget https://files.Zimbra.com/downloads/8.7.11_GA/zcs-NETWORK-8.7.11_GA_1854.RHEL6_64.20170531151956.tgz % tar zxvf zcs-NETWORK-8.7.11_GA_1854.RHEL6_64.20170531151956.tgz % cd zcs-NETWORK-8.7.11_GA_1854.RHEL6_64.20170531151956 # ./install.sh -s --skIP-activation-check
At this point, you new server should be far enough along to proceed to the next step.
Step 2: On production or existing machine run the following commands. This will push your Zimbra files over.
#!/bin/sh #Note: you must change BackupServer to your environment. # 80GB sparse file so we handle differently cd tar cvzSpf data.mdb.tar.gz data.mdb # backup /opt/Zimbra including this sparse LDAP tar file just created but ignore the actual sparse file rsync --progress --delete --archive --verbose --hard-links --exclude=zimbra/dat a/ldap/mdb/db/data\.mdb --exclude=Zimbra/backup /opt/Zimbra <strong>BackupServer</strong>:/opt/ exit
Step 3: On New server – Extract LDAP database before proceeding
#!/bin/sh # # Assumes: LDAP has tar image of sparse file from Step 2 # echo echo 'Unpacking LDAP stuff' cd /opt/zimbra/data/ldap/mdb/db /bin/rm -f data.mdb tar xvzSpf data.mdb.tar.gz chown zimbra:zimbra data.mdb echo echo 'fixing permissions' cd /opt/Zimbra /opt/Zimbra/libexec/zmfixperms -extended chown -R Zimbra:Zimbra /opt/Zimbra/.ssh
Step 4: At this point, you have a broken Zimbra instance but the next step will repair it. The problem is permissions, etc and other unknowns. Also note, you could bypass this step and bring up Zimbra via vmcontrol start. Generally, it is simpler to just do the following to make sure everything is fixed and updated as the install script is pretty robust and can fix many things.
% cd zcs-NETWORK-8.7.11_GA_1854.RHEL6_64.20170531151956 # ./install.sh --skip-activation-check
Almost there… fix the ip addresses. Replace X.X.X.X with new servers ip address
% zmprov -l ms `zmhostname` ZimbraMtaMyNetworks '127.0.0.0/8 X.X.X.X/32' % postfix reload Note: look for other locations of this ip address that needs to be changed. # vi /opt/Zimbra/conf/opendkim-localnets.conf # vi /opt/Zimbra/conf/amavisd.conf # vi /opt/Zimbra/data/spamassassin/localrules/sauser.cf
You can repeat this as often as required and test the server prior to a full production cutover.
Note about upgrades & new releases
Once you upgrade, you can’t roll back the version of Zimbra to a previous release without repeating all these steps. For example, if we moved to 8.8.6 but want to go back to 8.7.11, you should do the command below first to rollback. For a 100% repeatable process, I mention it here. If this was going to become the new production server, I would absolutely do the following procedure before beginning my steps again.
% cd zcs-NETWORK-8.8.6_GA_XXXXX # ./install.sh -u
After this has been done, you can repeat starting with Step 1 above.
I Can Help
If you need help, I am available for consultation. If you ask on the zimbra user forums, I will try to help for free but sometimes it’s better to talk to someone on the phone to better understand what the process is or if if your process is sound. I am user JDunphy on the zimbra user forums.
