Lateral migration on ZCS 4.5.3, restore from backups not happy

[mchung]

Hi all,

We would like to upgrade our ZCS, with eventual goal to go to 5.0.2. Here's our current config:

- CentOS 4.5
- ZCS 4.5.3 (NE)
- 109 of 125 boxes used, about a 120GB store


The new box has CentOS 4.6 on it, and the rest is a 'clean slate.'

Here's my current migration plan:
1. Pull backup files off live server to new server, install Zimbra 4.5.3, and restore from backup.
2. Upgrade ZCS 4.5.3 to 5.0.2
3. Upgrade CentOS 4.6 to 5.0
4. Upgrade to 64-bit CentOS

Steps 3 and 4 are kind of icing on the cake, and I have links to documentation on the 64-bit migration.

I'm stuck at step 1 now, as we have months worth of full and incremental backups (we're just using the default cron schedule), and I tried to copy over just the files related to the last backup:

- desired full backup from date 20080315
- 2 incremental backups since that date
- redologs since that date (and redo.log file)
- acct_name_id.dat and acct_session.dat
- ldap directory
- files in /opt/zimbra/backup/tmp/restore

( here are actual files transferred:
- /opt/zimbra/backup/sessions/full-20080315.080007.922 | incr-20080317.080010.574 | incr-20080318.080011.797
- /opt/zimbra/backup/acct_name_id.dat | acct_session.dat
- /opt/zimbra/backup/ldap/full-20070804.080017.776 | full-20080223.090008.735 | full-20080307.090002.792 | full-20080216.090003.467 | full-20080301.090002.569 | full-20080315.080007.922
- /opt/zimbra/redolog/redo.log | archive/* )

which I hope are the (only) files needed.


First snafu I ran into, was that we wanted these two mail servers up concurrently if possible, so I named the new server something different (ie., 'mail2.my.domain'). However, I found this doc: Network Edition Disaster Recovery - Zimbra :: Wiki
and learned that the hostname and domain have to be the same as the host from which the backup was taken. So I shut down eth0 on the new host, renamed it the same as original ('mail.my.domain') and now the restore progressed a bit further, but is now stuck here:


$ zmrestore -lb full-20080315.080007.922 -a all
[] INFO: I/O exception (org.apache.commons.httpclient.NoHttpResponseExcep tion) caught when processing

request: The server localhost failed to respond
[] INFO: Retrying request
Error occurred: Connection refused


Any ideas? Thanks!

[mmorse]

Might need a little more logs.

Ya servername changes are good to avoid - see: ZmSetServerName - Zimbra :: Wiki

4.5.3 > 5.0.2 is a big jump, I'd say stop off at 4.5.11 first.

There were lots of LDAP & Tomcat changes made after 4.5.6, and while we test everything in the 4.5.x line, just by very nature you're going to get more 4.5.10/.11 > 5.0.2 'tests'. ie: More users making that jump path because they were on 4.5.9/.10/.11 when they switched to 5.0.x

Another good article if you want to try it (though I'm sure you want to work out confidence in your backups) is here: /blog/archives/2007/10/moving_zcs_to_another_server.html
-Use the same ZCS version when doing the box or operating system change.
-Check UID/GID's.

[mmorse]

And though I've already chatted with you via PM to fix your posts that got stuck in moderation: Welcome to the forums!

[mchung]

Might need a little more logs.

Ya servername changes are good to avoid - see: ZmSetServerName - Zimbra :: Wiki

Thanks for the links, I'll check them out.

4.5.3 > 5.0.2 is a big jump, I'd say stop off at 4.5.11 first.

There were lots of LDAP & Tomcat changes made after 4.5.6, and while we test everything in the 4.5.x line, just by very nature you're going to get more 4.5.10/.11 > 5.0.2 'tests'. ie: More users making that jump path because they were on 4.5.9/.10/.11 when they switched to 5.0.x

Ok; I'd corresponded with a Zimbra support tech who ok'ed my proposed upgrade path, but I'll see if we will have time during the actual downtime to do the 2-stage upgrade. We could probably hold off on the 64-bit migration instead.

Another good article if you want to try it (though I'm sure you want to work out confidence in your backups) is here: /blog/archives/2007/10/moving_zcs_to_another_server.html
-Use the same ZCS version when doing the box or operating system change.
-Check UID/GID's.

Thanks - I have that link already, and you'll notice that they recommend pulling off the entire /opt/zimbra - for us that is 700+ GB, and in order to make the whole process take less time, I was trying to cull put the related files from just one (the latest) backup and restore from that.

So I guess my questions boil down to two:
1) I could not find in any of the documentation (user guide, 2 migration/backup-restore guides), a list of exactly which files and directories were needed for restore - does anyone have an idea of what they might be?
2) Specific to the last error in my first post above, does anyone know what connectivity issue the script is dying because of?

Thanks in advance =)

[mchung]

And though I've already chatted with you via PM to fix your posts that got stuck in moderation: Welcome to the forums!

Thanks Mike!

[mchung]

Anyone want to take a crack at this? =)

[mchung]

On a whim I ran:

> zmrestoreoffline -a name@domain.com

And it complained about not having the other alias domains, so I:

> zm prov createDomain domain2.com

etc., and tried again, and it worked! zmaccts shows the account in the listing, and it ultimately failed because "Error occurred: system failure: Redo log files out of sequence" - which is kind of expected, because of another issue, so I'm tar'ing up the latest full backup and will transfer that over for a fresh set of redologs etc. We'll see if that works.

The other issue that I mention above, is that before attempting this whole backup/migration, I played around with deleting and restoring a test account on our live server. I did a full backup of that one account, and in our backup/sessions, there was a label that was of form 'full-20080318...' and then incrementals after that. I was surprised, because then there's no way to distinguish between real full backups with everyone's data on it, versus a full backup with a subset of accounts. I had pulled the full-full backup just prior to that full backup of one account, the incrementals inbetween, and the current redo.log, which I think is what is tripping out the restore now.

I guess then a followup question would be, how do I match up the appropriate redo.log's for a particular set of full and incr backup files?