Rhel5 to rhel6 upgrade options

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


Zimbra ZCS version 8 and beyond will no longer be supported on Red Hat Enterprise Linux v.5.

Click to See Our RFE Bug Requesting Further Support for RHEL5

This has caused many Zimbra customers to consider upgrading to the supported RHEL6.

Unfortunately, Red Hat does not support in-place upgrades from RHEL5 to RHEL6, and recommends a fresh install. Such an upgrade is possible, however, they are not recommended by Red Hat and result in such issues as unresponsive GUI login windows and other, possibly unknown defects.

Red Hat Upgrade Guide and Disclaimer


Therefore, we have been working with our customers on a number of possible routes to migrating a current RHEL5 ZCS instance to a new RHEL6 server.

CAUTION- When testing, make sure the new Zimbra Server cannot contact the old server over the network. The test installer can make unwanted changes to the production server's LDAP, requiring an emergency LDAP restore from backups. Use a VLAN or subnet to keep them separate while testing!


First Method- Add New Servers To Replace ZCS Services And Use "zmmboxmove"

zmmboxmove

This option would be to add servers to your ZCS environment with the intention of "turning off" the ZCS services on the old servers.

  • Add a ZCS LDAP slave running the OS and ZCS version you want. Promote the new ldap slave to become the ldap master and later decommission the older one.

Configure LDAP replication

How to Promote an LDAP Replica

  • Add new mta servers running the OS and ZCS version you want. Decommission older boxes once done.
  • Add new mailstores running the OS and ZCS version you want. Use the zmmboxmove command to move all the accounts to the new mailstores. Decommission the older mailstores once this is done.

You will need to use the new "zmdedupe' tool in ZCS 8 to address an issue with links that cause the mailstore to grow to a much larger size, see this bug for more detail:

"zmdedupe"

See here for AJ Cody's notes and a list of bugs to review for using zmmboxmove:

"zmmboxmove" Issues

Here is a bit more on the process, it's a bit dated but still applies: Zmmailboxmove Method


Disaster Recovery Method

DR Wiki Page

In this method, you would close access to the Zimbra server with a firewall rule or similar, and make a full backup. Then, copy this backup to the new server and import it using the disaster recovery wiki to guide you. The result would be a duplicate of the first server.

This route has the fewest steps and has a good chance of success the first try. However, it is also very slow and requires the most downtime (possibly a day or more).


A Modified "rsync" Method

Similar to the methods mentioned here:

In this method, however, we do not use rsync to copy all of the Zimbra files (/opt/zimbra). We have found that using these methods between RHEL5 and RHEL6 results in (currently) unknown failures due to Perl and other library incompatibilities. Therefore, a finer-grained approach is needed to copy, export and re-import only the necessary files and database information. This method has the most steps, but offers a short downtime as you can perform the initial rsyncs while the old server is still running.

Modified Rsync Method

PLEASE NOTE- We cannot guarantee that any of these methods will work exactly as described. You should ALWAYS test these first in a lab or VM environment before using in production.


If you have feedback on any of these methods, please contact me at lshaughnessy@zimbra.com and let me know what you discover.

Jump to: navigation, search