Question
What are the ways to backup, recover and develop Standby Strategies for the Kaseya VSA?
Answer
There are a number of ways today to backup and recover the Kaseya VSA and it depends on the environment that the VSA is running. In today's world, most people now run Window Servers virtually under VMware or Hyper-V (these being the most popular). There are still those that do run Kaseya from physical servers and others that may have a combination. Kaseya itself uses VMware and Hyper-V to run it's SaaS customers. Depending on the size of your implementation, you may have a single server or a split configuration (one application server separate from a database server). This KB will go over some of the recommended Strategies to backup your Kaseya Environment that we support.
The Built-In Database Backup
The database is your most critical asset in the VSA second to the files that are stored on the application server. Kaseya has a built in backup in the VSA that executes a database backup every 7 days by default in the System->Configure page. It's highly recommend to change this to 1 time a day for daily backups. Kaseya keeps 2 copies of the backup by default, so it's recommended that you copy this file to other storage on a daily basis especially if you need more than 2 copies. Additionally, on a split configuration where the database server is separate from the application server, the folder path has to be located on the database server.
The run database setting can be set to zero if you prefer to do the backups via another method or backup solution. Setting it to zero effectively stops the Kaseya database backup. Sometimes this is desirable because you can compress the backups with other backup products or have even more versions backed up than the two built into the VSA. Just a note, if you do backup using other products, you have to restore the database using those products since the VSA will not "see" any backups in the backup folder. NOTE: by setting the database backup to zero days, the build-in maintenance for index reorganizations and update statistics will no longer run. We highly recommend that you create external jobs using the SQL Server Maintenance Wizard to set this up to run at least weekly.
You should also make sure that the backup path is not shared with the same drive as the database data files. We recommend that the drive path, even if this is a Virtual Machine, be located on a physically different device if possible from the actual database files. This gives you another level of security and redundancy for the database. Even if you do full image backups of the VM.
Data Corruption
Any backup of the database should also be tested from time to time by doing a restore to a test database server. Additionally, you should also run a DBCC checkdb weekly to insure the database is clean without any corruption. It's not uncommon that we see customers backup religiously and still have to rebuild their environment from scratch because of a corrupted database. And yes, you can backup a corrupted database and not know it till it's too late! Run this in a SQL job weekly and sent the report as an email:
dbcc checkdb with no_infomsgs
The results should come back clean like this with no allocation errors.
Microsoft Clustering for SQL Server
Kaseya does support the ability for the SQL Server database to run on a Microsoft Clustered SQL Server environment, however, there are limitations that are specific to Microsoft in terms of reporting services as it's not cluster aware. In these configurations, Microsoft requires a separate server running Microsoft SQL Server Reporting Services (SSRS). Please note that this still may not be a solid recovery option this doesn't protect from any data corruption due to a SAN or human error. It's still a good idea to backup to another device as shown above.
Always On Clustering/Log Shipping for SQL Server
Please note that Kaseya does not Develop or Test with Always On Clustering. Any issues will not be supported by our Engineering and Support teams. Customers have be able to run Kaseya with the SQL Server in an Always On Environment (or using log shipping), however, there are limitations. During patches and upgrades, Kaseya will require alter database commands which may fail with earlier versions of SQL Server if Always-On/Log Shipping is enabled. In these cases, Always-On/Log shipping needs to be disabled before maintenance occurs. Additionally, Kaseya will keep the database in a simple recovery mode even if it's changed to full (it will switch it back automatically). To disable Kaseya from changing the database back to simple recovery mode, run this SQL against the ksubscribers database:
INSERT INTO tempdata (tempName,tempValue,expireTemp) VALUES ('noRecoverModelReset','noRecoverModelReset','20330101');
Customer have seen issues if multi-subnet support is set to "1" in the listener. By setting this to "0" (zero), it will address any timeout issues waiting for the secondary IP address.
It is also still recommended that you do traditional backups of the database because this approach doesn't protect you from data corruption due to a hardware issue or human error.
Virtual Machine Backups/Replication
Kaseya does support the ability for the SQL Server (and application server) VM to be replicated to another hypervisor using various forms of replication available in VMware, Hyper-V or using backup products such as Veeam. How to configure replication of VMs is beyond the scope of this KB, but Kaseya recommends that even if replication of the VM(s) are used, please augment that with traditional SQL Server backups for the database.
Kaseya has seen performance impacts due to snapshots taken on earlier releases of VMware (specifically 5.x) where busy VMs may get "stunned" for a long duration causing UI timeouts and even all agents falling offline. We have seen better improvement in snapshots in VMware 6.x where this isn't a concern. This also was a problem with Image backups where snapshots are also used during backups.
Using traditional backup/recovery procedures for the VSA
You can use traditional backup and recovery procedures which is basically backing up selected folders in the application server in conjunction with a backup of the database. This is more labor intensive during a restore as you must create a new server with a new install of the Kaseya Application Server and SQL Database. You then must restore specific folders to the new server and restore the database as well. By reviewing the instructions found in the installation guide under the section "Moving the Kaseya Server", specifically under the "Creating an Archival Folder Structure", you can setup a backup and recovery strategy based on the information provided in the guide. Here is the link for V9.4: Kaseya R94 Server Setup Guide
Leveraging Veeam for Virtual Machines running Kaseya
Kaseya supports image backups using Veeam from Hypervisors based on VMware and Hyper-V. Full or incremental backups work great for restoring a server back a day or more depending on the event requiring the restore. For small implementations of Kaseya (5000 or less agents), having both the database and application server on the same instance makes things easier to manage with backups. There is no need to worry about timing between the database and application server.
If you do have split configuration with the application server on one VM and the SQL Database on another, we recommend that you back up the database server before the application server. This way, during a restore, you will insure that you have at least all of the files on the application server so you don't have an orphaned condition where files paths saved in tables on the database server are pointing to non-existent files on the application server.
Always test the restores of your VMs! We have seen issues in the past with CBT (Change Block Tracking) where incremental backups that were restored, were corrupted (power failure or hard power off). Again, Kaseya recommends highly that you should also consider some traditional backups of the SQL Server database to a NAS and even some of the file folders mentioned in the section above for moving a VSA.
Summary
There are a number of Strategies that can be used for backup and recovery of a Kaseya Environment. If you have questions, please contact our support representatives. They can provide more information or get you additional internal resources that can provide more detail on backup and recovery questions.