Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect » Any plans for Kerio Connect to offer an option to use database back end?
  •  
jo_moreware

Messages: 243

Karma: 3
Send a private message to this user
From some users I hear that there is a need for a database as back end instead of file system. The main concern with using the file system is the strain it puts on IO, especially if you use a VMware appliance or HFS+.
I guess that a database back end also would make searching on the server much faster, which would be a real boon to users of mobile devices.

Does anyone agree?


What says the Kerio Connect Team?

With best regards
J├Ârgen, Moreware
  •  
majo72

Messages: 17
Karma: 0
Send a private message to this user
Yes, please Smile
That would be absolutely awesome!
  •  
emilh

Messages: 13
Karma: 0
Send a private message to this user
YES PLEASE!

Any step towards making Kerio more reliable/redundant is a step in the right direction.
As it currently stands the Mailstore is a huge weak point and single point of failure for Kerio Connect.

You can double up on servers for running the server all you want but there's no good way to secure the store.

A database would enable redundancy by the built in clustering features of most db engines.

  •  
vlada

Messages: 34
Karma: -2
Send a private message to this user
Please, absolutely NO
  •  
My IT Indy

Messages: 1262
Karma: 40
Send a private message to this user
I see both sides of this, why do people want either way?

-
My IT Indy
Kerio Certified Reseller and Hosted Provider
http://www.myitindy.com
  •  
PC

Messages: 10
Karma: 0
Send a private message to this user
If you want a single point of failure look no further than Microsoft's Exchange database. One of the great appeals of moving to Kerio was to finally escape from that temperamental black box.

Databases may be fast but they are a huge disk hog and a pain for back-up systems. Get any disk corruption and you loose the whole database. You run the rebuild utility and start praying 'cause no amount of human intervention can help save that data.

On the other hand, we all know how easy it is to rebuild an index or a few corrupted files on Kerio and it all happens without crippling the entire mail server. Worst case you restore the backup and grab any missing emails off the users computers.
  •  
emilh

Messages: 13
Karma: 0
Send a private message to this user
PC wrote on Wed, 23 March 2011 00:46
If you want a single point of failure look no further than Microsoft's Exchange database. One of the great appeals of moving to Kerio was to finally escape from that temperamental black box.

Databases may be fast but they are a huge disk hog and a pain for back-up systems. Get any disk corruption and you loose the whole database. You run the rebuild utility and start praying 'cause no amount of human intervention can help save that data.

On the other hand, we all know how easy it is to rebuild an index or a few corrupted files on Kerio and it all happens without crippling the entire mail server. Worst case you restore the backup and grab any missing emails off the users computers.


While I agree that we don't want to go down the Exchange-route I don't think a DB backend necessarily will have to end up like that. A DB-backend built on an open solution such as My/PostgreSQL/etc would probably be the way. But hell, it doesn't have to be a db backend at all.

If there is a way to keep the open/transparant file backend but with support for clustering/redundancy I'd be all for it!

As for the index rebuilds, I don't agree that it's all that smooth - you still have to restart the mailserver, which is something you pretty much want to avoid at all costs if you are hosting a mailservice. For internal use it's probably not that big a deal.
  •  
elias

Messages: 114
Karma: 0
Send a private message to this user
PC wrote on Tue, 22 March 2011 16:46
Databases may be fast but they are a huge disk hog and a pain for back-up systems. Get any disk corruption and you loose the whole database. You run the rebuild utility and start praying 'cause no amount of human intervention can help save that data.


I don't agree. I've already had to build my KMS box to database specs anyway to get the disk IO I need for my user base. Grabbing properly indexed records out of a database is way more efficient than pulling a bunch of small files off of disk.

A database backend would be wonderful for backups. All current database servers support hot online backups of a database which guarantee a transactionally consistent backup. Logs become your differential backup mechanism and you backup window shrinks to a fraction of what it takes to scan all the files in the filesystem. Most current database servers also support some form of replication, and if used properly, could be used to keep a warm standby server in constant sync efficiently. Databases also provide some powerful functionality for free too, such as fulltext indexing.

emilh is right. If you look at Exchange as your model for what a database backend might look like, then yeah, bad idea. But there should be no reason you'd have to build something as crazy as Microsoft did to use a database backend for the store effectively. I'd bet that if done carefully, a database backend could provide enormous performance and management benefits without the unnecessary complexity of Exchange.

-Elias
  •  
freakinvibe

Messages: 1553
Karma: 62
Send a private message to this user
Quote:
A database backend would be wonderful for backups.

This is only true if you need to restore the whole database, i.e. you have a disk crash and need to restore the whole mail system.

But most of the restore cases are single mailboxes or single mails. For this, the backup software must have an agent specific to your mail system to restore single items (e.g. brick level restore in Exchange). So each backup vendor would have to create an agent specifically for Kerio. Will probably never happen.

For single items, getting an .eml file back, or a whole folder, is much easier.

[Updated on: Fri, 25 March 2011 09:32]


Dexion AG - The Blackberry Specialists in Switzerland
https://dexionag.ch
  •  
emilh

Messages: 13
Karma: 0
Send a private message to this user
freakinvibe wrote on Fri, 25 March 2011 09:30

So each backup vendor would have to create an agent specifically for Kerio. Will probably never happen.


Again, if based upon an open and common db this would not be an issue. A proprietary and difficult to access db-backend would be a really bad idea though.

  •  
BudDurland

Messages: 348

Karma: 10
Send a private message to this user
Personally, I've always thought that a hybrid solution would work best. Store the messages as ascii files, use a "real" database for indexing the key elements of the messages (to, from, envelope to, envelope from, sending IP, spam score, date, size, subject, etc), link them to the file name on the disk system. Create a utility that can scan the message store and rebuild the database.

Good is better than evil because it's nicer
--Mammy Yokum
  •  
elias

Messages: 114
Karma: 0
Send a private message to this user
freakinvibe wrote on Fri, 25 March 2011 01:30
Quote:
A database backend would be wonderful for backups.

This is only true if you need to restore the whole database, i.e. you have a disk crash and need to restore the whole mail system.

<SNIP>

For single items, getting an .eml file back, or a whole folder, is much easier.

Yeah, absolutely true. I haven't ever had the need to restore a single mailbox or a single email, so I hadn't thought of that use case. But its also common with databases to soft delete records with a deleted flag field, so if this were a common need for Kerio customers, it could be built into the design.

-Elias
Previous Topic: Why does updating the Kerio Server require blowing out the customized webmail login?
Next Topic: Some help recovering mail please!
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Tue Nov 21 20:39:55 CET 2017

Total time taken to generate the page: 0.00456 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.