Upgrading from latest ZCS 6.0.15 (x86) to 7.0.14 (x64) - Error

[MGSteve]

I'm getting an error when trying to do the restore on the new server box.



I'm using 1.2.3 of the suite on both servers.

Any help would be appreciated, I need to get it moved this weekend!

Contents of logs:

restore log:

2012-03-17 04:11:28,944 INFO begin restoreFromExternalBackup[3af7bf73-50bf-429e-b46a-b027fcedf516] ExternalRestore begin restoreFromExternalBackup
2012-03-17 04:11:29,14 INFO Restoring server layout[3af7bf73-50bf-429e-b46a-b027fcedf516] ExternalRestore Restoring server layout

zimbra log

Mar 17 04:11:28 mail postfix/smtpd[27403]: connect from mail.ukwebsystems.co.uk[109.108.139.38]
Mar 17 04:11:28 mail postfix/smtpd[27403]: DE11F490964: client=mail.ukwebsystems.co.uk[109.108.139.38]
Mar 17 04:11:28 mail postfix/cleanup[27404]: DE11F490964: message-id=<999921676.39.1331957488363.JavaMail.root@mail. ukwebsystems.co.uk>
Mar 17 04:11:28 mail postfix/qmgr[5761]: DE11F490964: from=<admin@mail.ukwebsystems.co.uk>, size=840, nrcpt=1 (queue active)
Mar 17 04:11:28 mail postfix/smtpd[27403]: disconnect from mail.ukwebsystems.co.uk[109.108.139.38]
Mar 17 04:11:28 mail amavis[5493]: (05493-07) ESMTP::10024 /opt/zimbra/data/amavisd/tmp/amavis-20120309T040100-05493: <admin@mail.ukwebsystems.co.uk> -> <admin@mail.u$
Mar 17 04:11:29 mail amavis[5493]: (05493-07) Checking: gGhMS4Gi+D1A MYNETS [109.108.139.38] <admin@mail.ukwebsystems.co.uk> -> <admin@mail.ukwebsystems.co.uk>
Mar 17 04:11:29 mail slapd[2706]: slap_queue_csn: queing 0x436ab4c0 20120317041129.371835Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_queue_csn: queing 0x412444c0 20120317041129.427853Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_graduate_commit_csn: removing 0x12f9f260 20120317041129.371835Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_graduate_commit_csn: removing 0x15363a40 20120317041129.427853Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_queue_csn: queing 0x42eaa4c0 20120317041129.615767Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_graduate_commit_csn: removing 0x15362540 20120317041129.615767Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_queue_csn: queing 0x436ab4c0 20120317041129.620939Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_graduate_commit_csn: removing 0x153ec4b0 20120317041129.620939Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_queue_csn: queing 0x426a94c0 20120317041129.802855Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_queue_csn: queing 0x42eaa4c0 20120317041129.808250Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_graduate_commit_csn: removing 0x130bee10 20120317041129.802855Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_graduate_commit_csn: removing 0x15bbea20 20120317041129.808250Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_queue_csn: queing 0x436ab4c0 20120317041129.916730Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_graduate_commit_csn: removing 0x130bf590 20120317041129.916730Z#000000#000#000000
Mar 17 04:11:29 mail slapd[2706]: slap_queue_csn: queing 0x412444c0 20120317041129.952885Z#000000#000#000000

[MGSteve]

One thing I have noticed, the old server setup was a bit screwed, in so much that the domain was mail.ukwebsystems.co.uk (same the new server), but the zimbra box was setup as delenn.ukwebsystems.co.uk

Is that likely to cause an issue? It appears the domains restored correctly, but nothing else.

[Cine]

Hello MGSteve!

Looks like there is some problem in one of the Zimbra's config (the different name shouldn't be an issue)

First of all, can you please update both servers to the latest Zextras Suite and retry?

Have a nice day,
Cine

[MGSteve]

How easy is it to wipe data out of a Zimbra installation? Reason I ask is that if I try and restore a backup now, I obviously can't take the existing mailserver offline because its during the day & in use. However, I obviously need to test this problem. If I restore onto the new server successfully, won't I then need to delete the existing accounts, domains etc.. out of the zimbra setup in order to restore the backup during the night?

[MGSteve]

I think I've answered my own question with regards to wiping the installation - Bulk Provisioning - Zimbra :: Wiki

Also, I updated as you suggested to the latest version of ZeXtras 1.2.4 and the Migration tool 1.2.4 and re-ran the export and its all working fine - hopefully it will do the same again later on

[MGSteve]

I think I've answered my own question with regards to wiping the installation - Bulk Provisioning - Zimbra :: Wiki

Actually, to follow up on that link - the script doesn't work.

I've amended it below for anyone who needs to remove all accounts, lists and domains from the server. I added the latter is as by default it only deleted accounts and lists.

#!/bin/bash
################################################################################
#-------------------------------------------------------------------------------
# Description:
#   Script to remove all Zimbra accounts and distribution lists.
#   This may be useful for getting back to square one if you are testing bulk 
#   provisioning during a migration.
#
# See Also:
#   http://wiki.zimbra.com/index.php?title=Bulk_Create
#
# Usage:
#    su - zimbra
#    ./deprovision > deprovision.zmp
#    zmprov < deprovision.zmp
#
################################################################################

# this will be passed to grep -vE which acts as an exclude list
KEEP_ACCOUNTS='^(admin@|ham\.|spam\.|wiki@)'
# this will be passed to grep -vE which acts as an exclude list
KEEP_LISTS=''
# this will be passed to grep -vE which acts as an exclude list
KEEP_DOMAINS=''

# files to hold distlist and account lists
ACCOUNTS='accounts.zmprov'
LISTS='distlists.zmprov'
DOMAINS='domains.zmprov'

TMPA=`mktemp "$ACCOUNTS.XXXXXX"`
TMPL=`mktemp "$LISTS.XXXXXX"`
TMPD=`mktemp "$DOMAINS.XXXXXX"`

# get accounts lists
zmprov -l gaa > "$TMPA"
if [ -n "$KEEP_ACCOUNTS" ]; then
    grep -vE "$KEEP_ACCOUNTS" "$TMPA" > "$ACCOUNTS"
    rm "$TMPA"
else
    mv "$TMPA" "$ACCOUNTS"
fi

# get distribution lists
zmprov gadl > "$TMPL"
if [ -n "$KEEP_LISTS" ]; then
    grep -vE "$KEEP_LISTS" "$TMPL" > "$LISTS"
    rm "$TMPL"
else
    mv "$TMPL" "$LISTS"
fi

# get domains
zmprov gad > "$TMPD"
if [ -n "$KEEP_DOMAINS" ]; then
    grep -vE "$KEEP_LISTS" "$TMPD" > "$DOMAINS"
    rm "$TMPD"
else
    mv "$TMPD" "$DOMAINS"
fi

# remove accounts
cat "$ACCOUNTS" | while read account; do
    echo "da $account"
done

# remove lists
cat "$LISTS" | while read list; do
    echo "ddl $list"
done

# remove domains
cat "$DOMAINS" | while read domains; do
    echo "dd $domains"
done

Just for the love of god, make sure you don't run it on the wrong server! I was one key press away from doing just that! - Yikes.

[MGSteve]

Arg! - Something to point out - if a smart scan starts whilst the restore is in progress, it crashes the restore.

[Cine]

Arg! - Something to point out - if a smart scan starts whilst the restore is in progress, it crashes the restore.

Hello MGSteve!

Can you please explain this sentence?
While a restore is running every other operation should be queued, not ran along with the current operation...

Can you please post some log lines related to this or send me the import logfile via email (community@zextras.com)?


Have a nice day,
Cine

[MGSteve]

I'll dig out the logfile lines in a bit, but its either related or it was the biggest co-incidence of all time.

The timestamp of the start of the smart scan coincided with the failure time of the import.

The import did fail a 2nd time actually, even after everything was wiped out via the script above. In the end, I uninstalled Zimbra, reinstalled it and whilst I'd like to say it went fine after that I don't know as during the import I found the reason for the problem of the authentication errors I was getting in the admin website (SSH wasn't on port 22 on my server), when I fixed that I restarted zimbra and of course, that screwed the importer up.

In the end, the import had created the email accounts anyway and if anyone moans that they've lost emails, I can restore them separately from the backup. Hardly ideal, but as 90% of my clients connect via POP3 anyway, its not that much of an issue.

[Cine]

I'll dig out the logfile lines in a bit, but its either related or it was the biggest co-incidence of all time.

The timestamp of the start of the smart scan coincided with the failure time of the import.

Actually, it's working as intended... When a restore is running ZeXtras Suite queues all other operations, so as soon as the import fails the next operation in the queue starts

The import did fail a 2nd time actually, even after everything was wiped out via the script above. In the end, I uninstalled Zimbra, reinstalled it and whilst I'd like to say it went fine after that I don't know as during the import I found the reason for the problem of the authentication errors I was getting in the admin website (SSH wasn't on port 22 on my server), when I fixed that I restarted zimbra and of course, that screwed the importer up.

In the end, the import had created the email accounts anyway and if anyone moans that they've lost emails, I can restore them separately from the backup. Hardly ideal, but as 90% of my clients connect via POP3 anyway, its not that much of an issue.

Some post-migration suggestions (now that I have more informations about it)
- Don't restart Zimbra when the import is running, you'll lose the operation queue and might end up with "dirty" import metadata. If you need to stop/restart Zimbra during a restore operation, use the "Stop all operations" button in the ZeXtras Zimlet before stopping/restarting.
- If you have many customers using POP3 consider having them uncheck the "Leave a copy of the message on the server" so that already-downloaded messages will not be migrated and re-downloaded.

Have a nice day,
Cine