Backing up a Kerio Connect VM [message #134553] |
Tue, 07 March 2017 15:32  |
IT Guy
Messages: 4 Registered: March 2016
|
|
|
|
I have recently moved my Kerio server from a bare metal server with an application installed in the OS for backup to a Kerio virtual appliance. I'm using a couple ESX hosts for my virtual environment and Veeam to replicate between them and backup the VMs to a backup server. What should I do to ensure that the replicas and backups of my mail server are properly backed up and resistant to data loss if/when the physical host has issues?
Also, while I'm here, I'd like some advise regarding the in-built backup utility in the Kerio server. On my old server I had Kerio back itself up to another physical disk in the server, however I don't know that the datastore has enough capacity to hold a disk containing the backups, and I would rather have a different location for those backups. Would it be OK to use a network location for the backups, or should I look into creating an iSCSI disk on my NAS and use that for the backup location?
|
|
|
Re: Backing up a Kerio Connect VM [message #134563 is a reply to message #134553] |
Tue, 07 March 2017 16:59   |
Maerad
Messages: 275 Registered: August 2013
|
|
|
|
Kerio already has his own backup system and you can use UNC paths with it. So get a NAS with some HDD + SMB, enter the path and done. If needed of you can also set user/password.
You don't need to do that locally.
|
|
|
Re: Backing up a Kerio Connect VM [message #134568 is a reply to message #134563] |
Tue, 07 March 2017 17:19   |
IT Guy
Messages: 4 Registered: March 2016
|
|
|
|
I've got a NAS already (as mentioned in my OP), however I don't know what user account I should create on the NAS to enable the appliance to view it. I cannot create a 'root' user on the NAS, and I see no way to designate a set of credentials within the admin dashboard for the backup location.
As for not needing to backup the actual virtual machine, you and I will disagree, apparently. I'd rather have a working backup of the VM to be able to spin up if needed, rather than having to do a full DR from an offline backup (which should honestly be a last resort). With Veeam I can have a much shorter time between replication and have the replica up and running in minutes with minimal data loss, versus spending hours rebuilding the VM and losing all data between the failure and the previous backup.
|
|
|
Re: Backing up a Kerio Connect VM [message #134570 is a reply to message #134568] |
Wed, 08 March 2017 00:22   |
Maerad
Messages: 275 Registered: August 2013
|
|
|
|
I have a bit of a hard time to get your question actually ... so let me try it 
Depending on the NAS and software, you just have to create a user, add a new folder, let the folder share with SMB / Samba and add the user as read/write access - it should be quite easy. Kerio Backup makes sense, because you can use it, to recover specific mail boxes etc. fast and easily - I would see that as an additional backup to the primary one(s).
For your backup - I would strongly advise to do multiple backups (looks like you do). I use HyperV Server as Virtualisation Host. The VM Guests are backed up daily to a local usb HDD with Windows Backup , to a local (but in another burn-protect area in our building) NAS with AltaroVM Backup, to our off site location over night (also with Altero, if our side burns down, Offsite location is 150km away) and of course with kerio backup itself.
This is my "long time" over night backup solution. I also implemented a real time failover with HyperV Replica, so the important VM's are replicated to a server in the other burn area we have. So if our hardware fails, I got a real time backup from the main servers and can start them right away in a failover scenario.
I work in IT for a long time, also back then in a 3rd party IT Service company and for important Servers we always told "at least 2 different backups per server". We had many cases, where one backup system was having problems and - for example - the backup reported "everything fine" but the backup files were empty.
If your concerns where more about "will this work with ESXi and Veem, if I backup the VM's to a NAS and in a replication, failover scenario" ... this is not a question for kerio, this is more a question for Veem and ESXi and the compatibility of the guest linux. USUALLY ESXi and Veeam are really matured, so it should work without problems. I also used this combination like 3 years before the last time and I never had problems. I also used a cheap backup script for the free vsphere thingy and it worked great
|
|
|
Re: Backing up a Kerio Connect VM [message #134592 is a reply to message #134570] |
Wed, 08 March 2017 16:28  |
IT Guy
Messages: 4 Registered: March 2016
|
|
|
|
Thank you for the reply Maerad. I must have misinterpreted your last reply, as it came off as not needing to do more than use the internal Kerio backup. I had the internal backup running on my previous Kerio server, and that's actually how I migrated to the new Kerio appliance. But like I said initially, that was all done on local drives.
For my NAS I'm running a Synology Diskstation, but I'm unsure as to what the user account should be for the NAS user. I have a Kerio user set up on the NAS, and I can mount the Kerio backup share through the Linux appliance without issue, but I'm unable to enter in the UNC path to the share into the backup page section in the console. I could potentially just mount the remote share and tell the Kerio system to backup to that, but I believe the system warns against using mapped drives.
As for using Veeam, I just want to make sure there are no settings that need to be changed to ensure that data is not lost or corrupted when I have to fail-over to a replica or a backup. I've had issues in the past where the bare metal Kerio server unexpectedly shut down due to power loss and I had issues with data integrity, and given that when I spin up a replica it behaves like it went through an unexpected power-loss event, I'm just trying to make sure that I'm doing everything in my power to make the recovery as smooth as possible.
|
|
|