Data protection solutions have long had a reputation for being complicated to configure and maintain. Cohesity, however, stands in stark contrast to other backup vendors in that the company has made it surprisingly easy for an organization to protect its SQL Servers.
In order to use Cohesity to protect SQL Server, a backup administrator needs only to register the SQL Server and then create a protection job. The Cohesity interface provides a very simple prompt, asking the backup administrator what type of protection job they wish to create.
As you can see in Figure 1, this screen presents an option for protecting SQL Servers.
Click the SQL Servers option to create a SQL Server protection job.
Once an administrator has specified that they wish to create a SQL Server data protection job, then the next step in the process is to choose a protection policy. As you can see in Figure 2, the available protection policies are presented on a simple drop down list.
The second step in the process is to select a protection policy.
Upon making a selection, the interface shows exactly what type of protection the policy will provide. In the figure above, for example, the Gold SQL Policy has been selected, and the interface very clearly shows that the policy will result in snapshots being created on an hourly basis, and that these snapshots will be retained for 365 days.
We can also see that logs will be captured every fifteen minutes, and retained for 365 days. The descriptive text even explains what will happen in the event of an error.
The policy description is written in a way that is very easy to understand. Perhaps more importantly, however, the policy description is displayed while the administrator is making a policy selection. Hence, the administrator does not have to guess what the protection policy will do, or go and look up the policy settings later on.
The third step in creating a protection job for SQL Server is to specify the job settings.
As you can see in Figure 3, this involves entering a name for the job, as well as an optional job description. Administrators are also given the option of scheduling when the job should start and the type of deduplication that they wish to use.
For example, an administrator might perform post processed inline deduplication, post processed only deduplication, or they might choose not to perform any deduplication at all.
The next step in creating a protection job is to specify the job settings.
The last step in setting up a protection job for SQL Server is to take a look at the summary information, just to make sure that the job was set up properly. As you can see in Figure 4, this screen displays a large, green indicator in the Confirmation section that clearly tells the administrator that the SQL protection job has been created. Furthermore, the Job Summary section confirms which data protection policy is being used, and how many SQL Server host VMs are being protected.
Of course, there is a button that can be clicked to view additional information, and there is also a link to a screen that shows exactly which VMs are being protected.
Figure 4
The View Summary screen very clearly confirms exactly what is being protected.
As you can see from the screen captures, Cohesity has created a very clean interface that takes all of the ambiguity out of creating SQL Server protection jobs. Better still, Cohesity has designed its interface so that administrators can use the same basic steps, regardless of what type of protection job they are creating. As such, an administrator who knows how to create a VMware protection job, for example, should have no trouble creating a SQL Server protection job.
