[SOLVED] Migration Script

[Sir Bob]

Hello,

After surfing through the forums for quite some time while fighting with our migration, we finally came up with a process that allowed us to migrate our Zimbra. The attached script does the vast majority of the work for us (see attached), and may help others with this process. We were migrating Zimbra 5.0.4 from OpenSuse 10.2 to CentOS 5.3, but it should not matter what O/S is involved.

We took the approach of just moving the data opposed to the entire /opt/zimbra directory. On our system, authentication is internal so no need to worry about AD. For you, build yourself a server, install a clean version of Zimbra (same version), but do not use the -s switch on installation. Server hostname and network settings are all the same as the initial one. If you take the approach we did with rsyncing the backup to a separate disk and mounting it on the server, ensure that you re-rsync the backup each time you try using the --delete option. This was one thing we overlooked and caused many heartaches over several days.

I would be interested to find out if someone else can use this and what success / problems they had with it. You will have to edit the script a bit to reflect your situation, but this is mostly for where your backups are stored and what password you are using. Notes are included with the script, giving a brief description of everything and a "play-by-play" on what is going on as it runs. To begin with, you may want to break the script into three or four parts so if something does not work at the beginning, you will not go through the entire process to find this out later.

Please comment back here with stories.

Sir Bob

[gurubaysoft]

hi
can you be little more elaborate in explaining what is sdb1 drive and how to take the backup from the source step by step please.

[Sir Bob]

Hello,

For our backups, we rsync the entire /opt/zimbra directory. In our test box, we added a second drive. This new drive was recognized by CentOS as sdb1. So, we created a new directory (mkdir /mnt/test) then mounted /dev/sdb1 to /mnt/test (mount /dev/sdb1 /mnt/test). In our case, the sdb1 acts as our backup. Once it was mounted, we rsynced the /opt/zimbra backup to /mnt/test (rsync -avH xxx.xxx.xxx.xxx:/opt/zimbra/ /mnt/test/. This was done for a few reasons:

1. The test box for the Zimbra installation must have the same hostname and IP as the production server. As you can't have two servers with the same IP and hostname on a network, we started with a free IP on the test box, rsynced the data over then changed the IP and hostname after disconnecting it from the network. We also installed Bind (DNS) on the test server as well for the installation of Zimbra.

2. As, in our case, we are dealing with approx 230 GB of data, rsyncing this takes a bit of time so not to bog down the network with this data transfer during the day, the backup data is rsynced to the spare drive at night (after the backup is done - takes about 4-5 hours), then we can do what we need during the day. Once you do the initial rsync of backups to /dev/sdb1, rsyncing this again (for testing purposes) is quick as, with rsync, only the files that changed are transferred. This is where I say use the --delete option.

Once, you have the backup rsynced to the new drive (sdb1) in the test box, from here, you do the clean install of Zimbra, turn off all services for Zimbra (service zimbra stop or su to zimbra then zmcontrol stop) then run the script (after editing it for where ever you put the data you intend to use) and at the end of the script, you should have a clean install of Zimbra with all your data.

Now, having said all this, once you start this process (assuming this will be the end and the server you are building will become the production server), you have to power off the production server so no new email gets processed or rsync your backup at night to the test box, then turn Zimbra off on the production server, and do a quick rsync from the server itself to grab any emails that came in after the backup was done. Either way, you will have some down time for the production server, but how much will be dependent upon how much data you are dealing with and how you approach the data transfer (see point 2).

Sir Bob

[gurubaysoft]

thanks for the useful info. i will try this out and share my experience