Kerio Connect Failover and disaster planning


2012/09/24

I'm often asked what can be done to be sure that email remains available in the case of major hardware failure or Internet outage. My usual answer is that you probably don't need to do anything.

I say that because email is a resilient protocol that expects problems like that. If a mail server can't reach your server to deliver email, it doesn't just throw up its hands and toss the email away - it waits patiently and tries again a little later. It will keep trying - most servers are configured to keep trying for up to three days and even very restrictive systems will try for at least a day. If your server is down for a few hours, mail will almost certainly be delivered.

Secondary MX

Of course you could set up a secondary MX record or even more than one. If you have done that, a server that can't reach your primary MX machine will try other machines listed and deliver the mail there. That's good, right? Your very important incoming mail has been delivered.

But do you have it? Well, no, you don't. It's at the secondary. Some systems are configured to automatically transfer email to the primary when it becomes available, but if your primary were available, it would have already been delivered!

Worse, because even a transient problem will cause a sending machine to use the secondary, mail that should have gone to your primary may get re-routed. If you had no secondary, it might have tried again a few minutes later and been successful: having the secondary MX might delay the mail more than not having it at all.

If the cause of the problem is that your local Internet is down, you won't be able to get at that email on the secondary until that problem is fixed, so you haven't necessarily gained much: you can't see your email until the Internet is back up and when it is, you'd probably get it anyway unless you have been down for days.

For these reasons, I don't recommend secondary MX servers for most small businesses. It is extra expense that you may never really need and having it may cause more problems.

Failover

There are failover solutions for Kerio. See Third party tools and applications for Kerio Connect and look in the "High Availability" section. If you really can't stand the thought of email being delayed, you might do something like that. But again, let's do a reality check: if the problem is dead Internet, you won't be able to reach the remote replica server either. These kinds of solutions can help in some situations, of course, but they are not a cure-all.

Manual Replication

For small businesses, your major concern is probably hardware failure. If the Internet is down, your workflow is likely difficult anyway and email may be the least of your concerns. You are more worried about hardware failure on the box running Connect.

Generally speaking, you shouldn't be. As Kerio Connect can run on Windows, Mac or Linux and even as a virtual machine, you have many choices for where you can install it. A mail server doesn't need a lot of horsepower, especially in an emergency situation. Installing Connect is just a matter of a few minutes. If you have the Store or a copy of it and your config files, you can be back up and running on another machine literally in minutes. If you have to use kmsrecover and backups it will take longer, but you could delay recovering old mail until later and at least have new email available almost instantly (see Recovering from a bad Kerio Mailserver crash for an example).

Note that you'll need your license file or at least the license number. Now might be a good time to be sure you have that information somewhere safe - looking it up in email won't work if your email is down!

I think it can make sense to have a copy of your store directory if you have a place to put it. Rsync can keep it current and if you ever need it, having it will save you time - a lot of time if your mail Store is large.

You can rent space in the cloud and install Connect there also. You might do that and have it ready to act as your server but without a MX record in place yet. In the event of an emergency, you'd change the MX to point to that and you'd be up and running. The Store might be kept current with rsync.

A solution like that doesn't even require two Kerio licenses. Don't run the "spare" server unless and until you need it. When you need it, upgrade it to whatever version you were running on the crashed box and off you go. You might even want to keep the install package there so it is ready to go if you ever need it.



Got something to add? Send me email.





(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Kerio Connect Failover and disaster planning




Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence



Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

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





Anyone who puts a small gloss on a fundamental technology, calls it proprietary, and then tries to keep others from building on it, is a thief. (Tim O'Reilly)

An algorithm must be seen to be believed. (Donald Knuth)








This post tagged: