Kerio has a Knowledge Base article that tells you how to move your Connect server to another machine. You should follow that article if you are changing operating systems, but if you are simply transferring from one Linux server to another as I helped a customer do this past weekend, you may want to use this "rsync" method instead.
One particular advantage of using rsync is that you can transfer most of the data without shutting down your existing server. If you have a large mail store as this customer did, that's very helpful as you can transfer most of the data days before you make the actual switch and therefore reduce down time to a very few minutes.
You also don't need to be concerned about file locking interfering with anything - some file transfer programs lock the files they are reading to protect against change during the copy, but rsync does not. While that locking can be desirable in other situations, it's most definitely not wanted here. We want to leave the current server running while we transfer data; locking would interfere.
When we are ready to make our final transfers, we'll shut down the Connect server and that will ensure that nothing changes during our final transfer, but for our initial work, we just want to get the bulk of data on to the new server. If something changes or gets deleted during that time, it won't matter because it will be fixed by our final rsync.
Why is that so? Because rsync actually does checksums on file data (on blocks within the file, actually, not on the whole file) and will only transfer data that doesn't match. So if something did change during our live transfer, it will get "fixed" at the end when we are shut down. If the blocks of a file all match, nothing gets transferred, so we won't be duplicating any effort. That's why the final transfer is so fast - it only needs to transfer new and modified files.
Mac OS X also has rsync and you can obtain it for Windows. Be wary of file locking possibilities with any other Mac or Windows utility you may find.
Transferring with rsync
I started by transferring everything. In this case, the Store was in /opt/kerio/mailserver/store, so I did this:
rsync -av kerio root@newserver:/opt
I had previously enabled root use of ssh - that's not normally something I allow, but on this new machine I would until we finish the transfer. The "-av" is verbose and "archive", which is explained in the rsync man page:
The files are transferred in "archive" mode, which ensures that
symbolic links, devices, attributes, permissions, ownerships,
etc. are preserved in the transfer. Additionally, compression will
be used to reduce the size of data portions of the transfer.
If the Store had been located elsewhere, I would have had to do that separately, of course.
That was on Thursday. I left that running and checked on it Friday morning. It had finished, so I immediately did:
rsync -av --delete store root@newserver:/opt/kerio/mailserver
Note the addition of "--delete". That will delete anything over at the new server that no longer exists here. That ran for a few minutes and finished. I checkled back late Friday afternoon and ran that again to pick up Friday's activity.
If you transfer data to a trial version, you will be able to check accuracy, but make sure it is a registered trial orit won't read any messages prior to the installation date.
We planned the final transfer for Saturday AM. My customer said he'd be on site about 7:30 to handle physical shutdown and change of IP address. When he called to say he was ready, I sshed to his old system, stopped Connect ("/etc/init.d/kerio-connect stop") and then did an rsync similar to my first, but with --delete :
rsync -av --delete kerio root@newserver:/opt
That took about a minute or two. Then, to finish up, I sshed to the new machine and actually installed Kerio Connect. This created the init.d scripts and now the system was running and ready to use. We checked a few accounts and then changed IP addresses - using a new address for the old server and then applying its former address to the new.
That was it. Total down time was less than ten minutes. If we had used the backup/restore method, he would have been down for hours.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Anthony Lawrence
Find me on Google+
© 2013-07-03 Anthony Lawrence