As it stands the backups which were in /opt/zimbra, or the zimbra user home directory were deleted when the installed deleted /opt/zimbra. Basically apart from the original imap server which was never decomissioned we have lost all email since we migrated to zimbra 3 months ago.
We also now need to discover why the one offsite backup which was a complete /opt/zimbra/ copy also failed to load on version 3.1.4.
What went wrong this time with the upgrade though, it looks like a download issue as running "rpm -ivh" on the zimbra-core from the command line showed that the internal md5sum was wrong. I downloaded the tarball again, both the original and new tarball have the same md5sum:
[root@gw ~]# md5sum zcs-4.0.3_GA_406.FC4.tgz
e3c4d3550679a9cdb723ea05c78b03c5 zcs-4.0.3_GA_406.FC4.tgz
[root@gw ~]# md5sum zcs-4.0.3_GA_406.FC4.tgz.1
e3c4d3550679a9cdb723ea05c78b03c5 zcs-4.0.3_GA_406.FC4.tgz.1
so whatever it was that changed must have happened in the untar I guess.
A subsequent attempt at installing from the original tarball (after re-untarring) proved successful. So I got unlucky with my first attempt...with catastrophic consequences!!!
So, the upgrade ./install.sh mechanism which removes all existing packages needs to pass any RPM error messages back to the shell to at least help debug errors.
Also, if the 'upgrade' borks - the install should *never* go ahead and simply delete the /opt/zimbra directory, not unless it has explicitly told you it is about to do that - this was a failed upgrade, not a new install for goodness sake!
Anyhow, can't take this back and 'what the hell this is open source software' and should have paid if we wanted more 'mission critical backups'. But what is to say this could not happen on a full verasion of zimbra? I only have a few users, family and friends etc, but still they are very upset they just lost all there email/contacts and schedules going back at least 3 months.  |