Connect,Kerio
2013/06/07
Kerio has long had a Knowledge Base article that details how to use "kmsrecover" to move Connect to new hardware. The article does talk about how to do it without kmsrecover, but we're only concerned with that method here. It's pretty simple; I'll quote what they say:
From How do I move Kerio Connect from one machine to another (or change Operating Systems)?:
Stop the services for the mailserver, to freeze your message store in it's current state; but still allowing you full access to the administration console. To do this, log in to the admin console, go to Services, then right-click and stop each of the services.
Run either a final differential backup on the old machine to save any emails sent since the last full backup (this is quicker for large message stores). To do this, in the Admin Console, go to Archiving and Backup -> Backup and click on "Add..." and submit a Differential backup to occur in 2-5 minutes from the current time.
Or run a full manual backup. To do this, in the Admin Console, go to Archiving and Backup -> Backup and click on Start Now.
Copy the latest full and your newly-created differential backup (Files starting with F and I .zip) files, or your manual backupfiles (Starting with C)from the old machine to a folder on the new machine.
Execute the kmsrecover command to do a full recovery according to the instructions in section 15.3 of the Kerio Connect Administrator's guide. Be sure to enter the new folder (where the backup .zip files have been copied) as the last argument of the kmsrecover command.
There's no doubt that this procedure works. I've used it myself numerous times. If you can do that, it's surely the easiest method.
There's a problem, though. If you have a very large store, it can take a LONG time to copy those backup sets to a new machine. I have customers approaching a terabyte of zipped backup data - under the best conditions that will take at least several hours to copy and your mail services need to be down while it is shipping those bytes. The restoration process on the new machine is far from instant either - that could also require many hours. This may not be acceptable!
Wouldn't it be nice if you could do a master backup, and leave your old mailserver running while you transfer and restore that to the new server? Then, you could stop services, do a differential (which will be a much smaller file) and transfer and restore that? That would be so much less downtime, wouldn't it?
Unfortunately, the kmsrecover instructions seem to be discouraging on that count:
From 15.3 Data recovery from back-up:
If Kerio MailServer Recover is run without advanced parameters specified otherwise, all items in the Kerio MailServer's data store, such as configuration files, licenses, mailing lists and data, will be overwritten.
But surely that doesn't mean that recovering a differential wipes out the store?
Well, according to Kerio, yes, it does:
From kmsrecover differential help at the Kerio forums:
None of the backup recovery options will merge the backup with the existing mail store. The backup recovery will replace the existing mail store.
This means if you recovered a full backup and a few days later you did a recovery on the differential, the data in the differential would replace what was restored from the full backup.
You will want to recover from the full and differential at the same time.
That's pretty definite, isn't it? Moreover, should you be brave enough to point kmsrecover at a differential backup, you'll get this ominous warning:
But it's apparently wrong!
I had a brave customer who actually tested this.
It worked. It worked perfectly.
I also asked a Kerio support tech (who might like to remain unnamed) to test it. He also reported that it worked, and he went so far as to delete messages before making the differential. That worked, including getting rid of the deleted stuff.
Now here's the thing: I can't GUARANTEE that this works. I don't know if there are some conditions under which you WOULD lose data. If you did, you'd have to bite the bullet and restore the whole set, taking whatever time that takes.
I have taken this up with Kerio support and they in turn threw it at the code jockeys. They responded:
"It is generally bad idea to do that, because it will simply copy all files from differential backup to the store. Which can cause store inconsistency as some of indexes may be overwritten and no longer reflect actual store content."
That's obviously not true, but I think they were assuming that the new mailserver was active before restoring the differential. I explained that it would not be, but I don't have an answer to that yet and it has been a few weeks. If and when I get a more definitive answer, I'll post it here.
It's up to you whether you dare try this. I suspect that there is no issue, but I certainly understand that some people would rather err on the side of caution.
Comments: Click Here.
Want to showcase your product to our audience? Check our advertising options.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them.
I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you
to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. If you have any question, please do feel free to contact me.
-
Skills Tests
-
Psst - wanna work for yourself?
-
Unix/Linux Troubleshooting e-book
-
Kerio Mail Server
-
Consulting
-
Advertise Here