Upgrading from 4.5.11 to 5.0.18 - what gets modified?

[su_A_ve]

We are running about 12,000 accounts on two servers. We will be attempting to upgrade them to the latest 5.0.18, but trying to minimize restore times in the event of a failed upgrade.

One node which typically backs up in about 8hrs currently occupies about 400GB - this nodes runs everything. The other one, is much faster and with about half the storage, only takes 2 hours for backups. This node is an LDAP replica and runs everything except the logger.

Even though /opt/zimbra resides on a SAN, snapshots are not an option at this point due to license issues. I know I could take an LVM snapshot, but since I cannot quickly revert it back, it does us no good.

So, my question is, what changes on an upgrade? Other than the binary bits, do the stores get modified during the upgrade? DATA STORE, INDEX STORE, MESSAGE STORE ?

Thank you.

[veronica]

STORE and INDEX are not modified at all. What gets modified is LDAP schema changes and on mailstore front MYSQL tables addition/modifications etc. So basically the DB partition of mailstore.

[veronica]

Also don't panic if upgrade takes some hours. upgrading from 4.5.x to 5.0.16 will surely require long upgrade times for each mailstore, say 3-5 hours.

[su_A_ve]

We had a problem last time when we upgraded from 4.5.10 to 4.5.11 on one of the nodes.

The bulk from what I can see is in the actual STORE (/opt/zimbra/store). So if these are not touched, restoring the rest would be much faster.

This is important to know, to plan out the outage window. Also, I imagine that I have to upgrade the node that has the master ldap first, and then upgrade the 2nd node. I don't think I can upgrade both at the same time.

Thanks for the input...

[veronica]

Upgrade process dictates to upgrade Master LDAP and later Mailstore. Better follow the procedure

[su_A_ve]

Thanks - I'm currently making a 'hot backup' via rsync with the hopes on doing a quick sync prior to the upgrade. This is based on the wiki instructions suggested by support at Ajcody-Notes-Server-Move - Zimbra :: Wiki

However, it's taking FOREVER. The problem is with 'building file list' - The smaller node took 14 hours for the initial rsync, and 2 hours for a subsequent run, but mostly it's due to buidling it's file list. I'm currently rsynching everything except /opt/zimbra/backup.

We are not concern on disk failure, but on how fast to recover from a bad upgrade if it goes well beyond our outage window.

What if I bypass synching /opt/zimbra/store ? Then my process on rollback would be:

unmount /opt/zimbra (this to avoid the partition from being deleted)
uninstall zimbra 5.0.x
install zimbra 4.5.x
mount /opt/zimbra
rsync back with --delete but excluding store

Would this work? I'll give it a run on our test box in the mean time...