Transferring a Kerio Connect Server with rsync

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:

cd /opt
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:

cd /opt/kerio/mailserver
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 :

cd /opt
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.

11 comments

Fri Mar 8 11:42:24 2013: 11942   BrianD




Were running Kerio connect on OSX client and the mailstore is 250GB+
Is it possible with osx / unix and kerio to rsync the whole /opt/kerio folder live whilst connect is running ? Only reason i ask is because kerios own backup takes about 8 hours to complete and I'm frightened it would take that long to restore if the S$*t hit the fan and a restore was needed. Live rsync to cold hardware would be the most obvious case but im scared to damage the current indexes/stores if i try !






Fri Mar 8 11:50:25 2013: 11943   TonyLawrence




Well, yes, but as explained above, you'll need to do another rsync with the server off to fix any files that changed during the initial.



Fri Mar 8 12:47:19 2013: 11944   BrianD




Thanks tony, as you have first hand experience i wonder if i could ask you one more small question .. as the kerio connect store and everything thats really required sit in /opt/kerio would it be possible to just rsync that whole folder to an empty harddrive, if disaster strikes one could format a new hard drive, install and license kerio and then create an admin account, log out and then copy over the whole /opt/kerio folder ? this would cut out really backing stuff that not necessary if your in 'recovery' mode ? this could mean hourly backups as opposed to 4 hours or daily when users arent on using the system .. im really looking at fastest recovery and I'm just not confident in the kerio recover ( have read alot horror stories on the readerboards)



Fri Mar 8 12:49:15 2013: 11945   TonyLawrence




Just to explain more:

If you are going to try to back up live with rsync, you can do that, but you'll need to follow up with a "down" rsync. That obviously won't take as long, so this is perhaps useful.



Fri Mar 8 12:51:49 2013: 11946   TonyLawrence




You need the /opt/kerio/*.cfg files also..

Yes, you could do this, with the caveats above. Though faster still would be to mount that drive at the store directory.



Fri Mar 8 12:53:27 2013: 11947   TonyLawrence




Horror stories?

The restore is weak in functionality, bit it works. I've never had a problem with that.



Tue Jun 25 23:41:24 2013: 12160   TonyLawrence




By the way, when moving to another site, be sure NOT to bring the old server back on line until the new MX has fully propagated. You risk having some mail arrive at the old server if you do. This actually happened to one of my customers!



Sun Jun 30 22:09:51 2013: 12187   anonymous




Thats great advice (probably overlooked alot) thanks tony, what a nightmare having to do the process a second time !



Sun Jun 30 22:32:57 2013: 12189   TonyLawrence




Huh? I think you might have misunderstood something.



Wed Jul 3 09:29:07 2013: 12204   david




hi, i have to install kerio and move an old connect to a new server same sortware (centos)
but not same hardware.
this method will work in this case also ?
or the method with the master and differential backup ?
like described here (link)






Wed Jul 3 09:37:15 2013: 12205   TonyLawrence




Assuming that the OS will be the same, yes, this method will work.

The Store directory is the same across all hardware. The program differ.

------------------------

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us