Cohesity: My Initial Impression


A few weeks back Cohesity gave me access to a lab environment, where I could play around with their HyperConverged Secondary Data solution. For those unaware of their offering entails, it’s simply put a solution for managing secondary storage. In this case, secondary storage is really everything that isn’t mission critical. It can be your backups, test/dev workloads, file shares and so on . The idea to place these unstructured data sets on a secondary storage platform, to ease management and analytics but at the same time keep it integrated with the rest of the existing environment. It’s a Distributed scale-out platform, with a pay-as-you-grow model.

Currently Cohesity supports both SMB and NFS as data entry points, and it also supports acting as a front-end for Google Cloud Storage Nearline, Microsoft Azure, Amazon S3 and Glacier.

Partial Feature List

I won’t go through a complete feature list for the current v3.0 offering, but here are a few highlights:

  • Replication between Cohesity Clusters
  • Physical Windows and Linux support (in addition to VMs)
  • Single object restore for MS SQL, MS Sharepoint and MS Exchange.
  • Archival of data to Azure, Amazon, Google
  • Tape support
  • Data Analytics

Getting data out of your VMs, and onto a secondary storage tier makes sense, even more so when you can replicate that data out of your datacenter as well. This makes your VMs smaller and thus easier to manage.

Naturally I was most interested in looking at this from a vSphere perspective, and that’s what I had a look at in the lab. Backups and Clones are presented back to the vSphere environment using NFS, something that enables quick restore and cloning without massive data transfers to get started.

Without any introduction to the product what so-ever I was able to create Protection Jobs (backups) and clone VMs directly from the Cohesity interface.

screenshot-2016-11-05-23-04-26Creating Protection Jobs:

Creating a Proection Job is easy, select the VMs you want to protect from the infrastructure:

Select, or create a Protection Policy (did I mention it’s policy driven?)


Watch the backups run


Creating Clones

The procedure for clone jobs is equally simple

screenshot-2016-11-06-23-45-32 screenshot-2016-11-06-23-46-23






The Cohesity 3.0 UI is beautiful and easy to work with. As I mentioned in my tweet after looking at this for a little under an hour:

It’ll be interesting to see where this moves from here, but from a purely technical point of view the current offering looks pretty darn good! Of course, I’ve only scratched the surface here playing with backup/restore and cloning only, the platform has much more to offer besides that.

#vDM30in30 progress:

Veeam vCenter Migration Utility

Way back in 2013, I published Preserve your Veeam B&R Backups Jobs when Moving vCenter, outlining how to “cheat” (by using a CNAME alias) to preserve your Veeam Backup & Replication jobs if you replace your VMware vCenter.

Naturally, when there is a new vCenter instance, all the Virtual Machine Managed Object Reference’s (MoRef) change, which makes Veeam Backup & Replication start a new backup/replication chain, since all VMs are treated as new ones. Not ideal by any means, but at least you wouldn’t have to recreate all your jobs.

Veeam has now made a tool available that can map old MoRef’s to new MoRef’s in your backup jobs, in order to keep your incremental chains intact even after replacing your vCenter.  

Check out vCenter Migration Utility!

vCenter Server Appliance Backups

For some time now I’ve been advocating the usage of VCSA instead of the traditional Microsoft Windows based vCenter. It has feature parity with the Windows version now, it’s easier to deploy, gets right-sized out of the box and eliminates the need for an external Microsoft SQL server.

One of the questions I often face when talking about the appliance, is how do we handle backups?  Most customers are comfortable with backup up Windows servers and Microsoft SQL, but quite a few have reservations when it comes to the integrated vPostgres database that the VCSA employs. One common misconception is that a VCSA backup is only crash-consistent. Thankfully vPostgres takes care of this on it’s own, by using what it calls Continuous Archiving and Point-in-Time Recovery (PITR).

I essence, vPostgres writes everything to a log file, in case of a system crash. Since this is done continuously, every transaction that should hit the DB is recorded and can be replayed if required. From the Postgres documentation:

“We do not need a perfectly consistent file system backup as the starting point. Any internal inconsistency in the backup will be corrected by log replay (this is not significantly different from what happens during crash recovery). So we do not need a file system snapshot capability, just tar or a similar archiving tool.”

With regards to the VCSA, this means that your image level backups  will be consistent, and there isn’t really a need to dump and export the vPostgres DB and then archive that. Yet another reason to switch to the appliance today!

Myth busted!