GFI Software

Welcome to the GFI Software community forum! For support please open a ticket from https://support.gfi.com.

Home » GFI User Forums » Kerio Connect » Using DFS as a backup system.
Using DFS as a backup system. [message #131661] Fri, 02 September 2016 23:30 Go to next message
benjalamelami is currently offline  benjalamelami
Messages: 72
Registered: October 2010
Location: Cali

I wonder if it would be reasonable to use DFS as a backup system. Just in case the mail server fails, another windows server would have the most recent files in it, would only be needed to install the Kerio Connect

Would that work?
Re: Using DFS as a backup system. [message #131777 is a reply to message #131661] Tue, 13 September 2016 16:54 Go to previous messageGo to next message
Maerad is currently offline  Maerad
Messages: 275
Registered: August 2013
benjalamelami wrote on Fri, 02 September 2016 23:30
I wonder if it would be reasonable to use DFS as a backup system. Just in case the mail server fails, another windows server would have the most recent files in it, would only be needed to install the Kerio Connect

Would that work?


Mhhh... it should work.... But DFS is more meant for file shares, not a mail system. So if Kerio keeps the DB open, it won't be synced by DFS IMHO. Also DFS can be a bit tricky and hits the performances quite hard, if there is much I/O going on. Even with RDC.

For a FailOver with windows I would suggest HyperV Replica. You set up both hardware servers and virtualize both with HyperV. That way you can enable the HyperV Replica for the KerioVM from Server 1 to Server 2.

Replica basically copys the KerioVM Guest over to the second server at first, after that it updates the VM every 5 minutes or less, depending on which HyperV/Windows Version you use. It dosn't affect the hardware / performance much. I use it for 2 VM on a server, one VM with kerio, other one with our ERP System, both quite much I/O, but the Replica takes away like 1-2% at most.

If your hardware for server 1 fails, you can just start the server from the second server and done. And depending on the windows version with real time data, you wont have problems. Also you can enable snapshots on the replica. Example I have at least 4 automated snapshots from out ERP VM, so I can say "start the last version" or "Start the version from 3 hours before" - makes sense if something happend and the last recent copy is already affected.
Re: Using DFS as a backup system. [message #131809 is a reply to message #131661] Wed, 14 September 2016 21:50 Go to previous messageGo to next message
benjalamelami is currently offline  benjalamelami
Messages: 72
Registered: October 2010
Location: Cali

Yes... your solution should work too, but that would involve having both machines on the same host, which defeats the purpose for having the second server ready to go if the first one breaks, rather than trying to wait till the copy of all folders from vm to vm.


Re: Using DFS as a backup system. [message #131827 is a reply to message #131809] Fri, 16 September 2016 13:43 Go to previous message
Maerad is currently offline  Maerad
Messages: 275
Registered: August 2013
benjalamelami wrote on Wed, 14 September 2016 21:50
Yes... your solution should work too, but that would involve having both machines on the same host, which defeats the purpose for having the second server ready to go if the first one breaks, rather than trying to wait till the copy of all folders from vm to vm.


Wait, you didn't get what hyperv replica is. You need two servers in hardware. Both run windows server with hyperv. On your production system you run the VM with kerio. In HyperV Manager you select the VM and turn on "HyperV replica" and select as target the second server in hardware. The VM gets fully copied (only the first time!) over to the second server. When finished, your disaster recovery / failoversolution is ready. Every change on the main server gets synced with the replica on the other server, usually in a 1-5 minute rhythm, even with heavy loads only some MB. In server 2012 the sync time is defined by the OS (max. ever 5 min), on server 2012R2 you can select the sync time yourself.

You can even use that over a WAN to another location!

If your main server fails, you start the failover vm on the other server and kerio runs like nothing happend. It's like a live copy.

Additionally you can select some options like "Keep 4 or more Snapshots on the failover host", so you can not only start the most recent vm on the failover server, but even the last 4 versions from the past 4 hours. Quite nice, if something like locky fucks up your network.

If you do DFS, your IO is way higher, problems with sync can occur (very bad with mail servers I tell you) and you don't have a running system if something happens.

With hyperv replica, you get a free failover system. With dfs you might have to config the server, install kerio anew etc.

With replica your server runs in like 1 minute (or as long the vm needs to start).

We have 4 Servers in Hardware, two in out server room (main servers), 2 in our warehouse / production (another fire zone) mounted on a wall, high up (can't reach without a ladder) - one Server as NAS, one as failover system with some older vms (changed our ERP recently).

Our VM with kerio and another with our ERP system have a failover to the other server "outside", so in a case of hardware failure, fire, flood etc. I have a real time copy. One time our system failed and I had to start the failover - was running smooth as hell and up 5 minutes after the server down. A bit slower because of the missing horsepower, but it worked and we could still work. After my repairs the vm replicated back to the main server and the main server started again.

Not to mention that backups etc. are much easier with vms Razz

Nice read about it: http://www.sbsfaq.com/?p=4175&doing_wp_cron=1474026164.1 787600517272949218750
Previous Topic: Kerio Connect Desktop Client - outgoing connections
Next Topic: Unreliable notification of online status in instant messaging service
Goto Forum:
  


Current Time: Tue Mar 28 23:57:56 CEST 2023

Total time taken to generate the page: 0.09319 seconds