Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: upgrade to 4.0.3 just trashed my install (without a backup)

  1. #11
    Join Date
    Aug 2006
    Somerset, UK
    Rep Power


    Here is a brief synopsis of the problem.

    System: FC4
    Previous install: zcs-4.0.2_GA_362.FC4.tgz
    This upgrade: zcs-4.0.3_GA_406.FC4.tgz

    My system state is that I have a failed install due to a zimbra-core rpm being broken (most probably due to tar -zxvf). The initial upgrade has failed as the 'rpm' failed after the rpm md5sum did not equate true.

    I subsequently (because the real error rpm was not sent to the term) re-tried the install. I simply re-ran, accepted the prompts to install and make changes. Installer then deleted /opt/zimbra and I lost my entire installation. This I believe is very wrong.

    ####### My fix #########

    The problem as I see it is that the installer does checks to see what is installed based soley on rpm (or dpkg/conary) and the results of this alone dictate if this is a new install or upgrade.

    The files involved are in the zimbra tarball and can be found at:

    zcs/util/ details the three following variables:


    which contain the packages which the package manager will query to determine if zimbra is installed and ultimately if it should delete /opt/zimbra .

    I strongly believe that this decision should have a safety net as in the case of a failed upgrade, the packages have most likely been removed fooling the installer to think a new install is being deployed. This is what happened to me and is wrong behaviour.

    I think that as a minumum, the installer should check for the existence of a message store and possible any other directory found within a normal zimbra install. For the purpose of testing, I used the /opt/zimbra/{bin,store} to test for existence and added the following block of code into:


    Using diff:

    > echo ""
    > echo "Checking for existing message store..."
    > INSTALLSTORE="store bin"
    > for i in $INSTALLSTORE; do
    > echo -n " $i..."
    > if [ -d "/opt/zimbra/$i" ]; then
    > echo "FOUND $i"
    > INSTALLED="yes"
    > fi
    > done

    This simply performs the required check and sets the $INSTALLED variable so that the installer correctly detects the existence of a possible install, albeit a rudimentary check. Improvements could be to check for database files and messages etc.

    The above type check along with a 'do you really want to delete the /opt/zimbra/ directory?' prompt would probably solve the main issue.

    ####### How to recover from backup ########

    I created a mirror install of FC4 on a VMWare instance, confgured the installation of the OS to suit zimbra and rsync'd over a cold backup of my currently running restored (albeit missing 3 months email) live zimbra server. So, for purposes of testing, I am running the installer on a different machine/hardware albeit with same hostname (differing IP).

    When I ran my tweaked installer, it correctly detected the installation and allowed me to start the services after the installer had completed. The final installation however had not retained my settings for https and different https port numbers. This was the only issue.

    Instead, in the case of a failed upgrade, I found it better to start afresh.

    * Backup if not already done so *

    Backup your (you should already have anyway) /opt/zimbra somewhere safe (not inside /opt/zimbra/). Once you are sure you have a good cold backup, remove zimbra via:

    % ./ -u

    then, carry out a fresh install (*same version* as cold backup) whereby configuration of admin password etc is obligatory albeit needless as we will delete the /opt/zimbra once installation is complete.

    After a completed install, move /opt/zimbra out of the way *after* first stopping any zimbra services.

    Then, install your backup. You should now be able to start your services and test things are working. If everything is ok, re-attempt to upgrade after fixing whatever broke the original upgrade (bad md5sums etc).

    Hopefully this will be enough to stop this happening again (even if it saves one install).

    I must admit thouh, I feel a whole lot better knowing I understand the backup/restore process so this whole saga was not for nothing. Just hope my users understand though...
    Last edited by DGS_David; 10-21-2006 at 01:14 PM.

  2. #12
    Join Date
    Jul 2006
    Rep Power


    I've filed a bugzilla report on your behalf to track this issue.

  3. #13
    Join Date
    Oct 2006
    Rep Power


    I am looking into moving my trusted QmailToaster install over to Zimbra. I am testing testing Zimbra on CentOS4.4, but after going through the install and encountering some problems, and then encountering this thread, I am wondering if this is even something to consider.

    The problem is not 'why did the upgrade fail', or 'why did /opt/zimbra get deleted'. The real question is 'Why is there user data stored in /opt/zimbra?' The opt directory is storage for large static application and support data. Not user data. Please consult

  4. #14
    Join Date
    Aug 2005
    Rep Power

    Default /var/mail/...

    Just to make sure, you'd prefer /var/mail or some variant under /var?
    Bugzilla - Wiki - Downloads - Before posting... Search!

  5. #15
    dijichi2 is offline OpenSource Builder & Moderator
    Join Date
    Oct 2005
    Rep Power


    isn't /var/opt or /var/lib the usual place for this sort of data?

    i use /srv/zimbra but i'm not sure if thats technically correct

  6. #16
    Join Date
    Nov 2005
    Rep Power


    fyi: Bug 12525 - "move zcs data from /opt/zimbra/ to /var/opt/zimbra/ to conform to Filesystem Hierarchy Standard"

  7. #17
    Join Date
    Aug 2006
    Rep Power

    Default Same

    I have had 2 or 3 upgrades fail the first one I tried to do it again and it erased every thing, the other times I restored from backup and fixed what was wrong then tried again, this was my fault not Zimbras.

    I would like it to back up before it starts to upgrade if it fails it should just put every thing back and print out an error. This would save a lot problems with failed upgrades. I also think it would be easy to put into the installer. Give an option in the beginning to skip this step for those that don't want to wait for the files to copy.

Similar Threads

  1. Upgrade 3.1.3 to 4.0.3 -FAILED
    By rrojas in forum Installation
    Replies: 4
    Last Post: 05-28-2007, 09:05 AM
  2. Upgrade from 3.1.3 to 4.0.3
    By rrojas in forum Installation
    Replies: 4
    Last Post: 05-22-2007, 08:45 AM
  3. Backup directory deleted during upgrade!
    By dlochart in forum Installation
    Replies: 2
    Last Post: 02-25-2007, 06:38 AM
  4. 4.0.3 -> 4.5.1 upgrade
    By Storm16 in forum Installation
    Replies: 1
    Last Post: 02-11-2007, 08:44 PM
  5. Upgrade to 4.0.3 on Suse 9.3
    By winne27 in forum Migration
    Replies: 3
    Last Post: 10-27-2006, 10:30 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts