This is part of my series of posts on Cloud Field Day 3.
Druva got its start doing endpoint backup (laptops, phones, tablets) and data governance (legal discovery, compliance with regulations like HIPAA, PCI, etc.) but has recently decided to expand into the broader data protection market. It now sells what it calls Data Management as a Service, which is where the cloudiness comes in.
From what I’ve been able to work out, Druva is well regarded in its original market, and has a solid business from which to grow. The expansion into a broader data protection and management company makes sense for growth.
Druva is positioning itself against legacy on-site backup and recovery options, which is a similar tactic to other new players like fellow CFD3 presenter Rubrik. The Druva difference appears to be that it’s built on AWS, rather than needing on-site hardware, and it specifically talks about backing up data in SaaS applications like Office365, Salesforce, and Box.
SaaS hosted email is really handy, and as a G Suite customer I am quite conscious that my mechanisms for backup and recovery of cloud-hosted data aren’t nearly as robust and well tested as what I use for data on physical servers near my desk. I know that my super-important data is on encrypted removable drives in a fire-proof safe, so how do I do something similar for stuff in Gmail without copying the data out and into the same data protection system?
Same goes for SaaS hosted Sales CRM like Salesforce. There’s a lot of history and in-flight information in these systems that would be a pain to restore if I needed to. Same goes for cloud-hosted accounting software like Xero.
And if you move to doing basically everything in Office365 (assuming you have a network that’s fast enough) you have even more data you need to keep protected from accidentally damage.
The vendors themselves protect the systems that run the platforms, and they may even protect the data en masse so if they accidentally lose a server they can attempt to restore all the customers’ data that was on that server. But if they can’t, what do you do? No one cares about your data as much as you do, and getting an individual email or file back can be tricky unless you’ve thought things through.
How Does It Work?
The big question for me is about the mechanics of how Druva actually does what it does. Having hardware on-site close to where data needs to be restored reduces the time it takes to recover. Really fat pipes into AWS are expensive, and recovering from local snapshots is usually much faster, but whole disk recovery isn’t needed anywhere near as often as just “I accidentally deleted the wrong email.”
The information on Druva’s website is pretty high-level, but it looks like you’d end up with a per-customer central Druva datastore in an AWS region that you can select. You’d use Druva’s inSync for laptops and tablets as well as SaaS applications, Druva Phoenix for servers and datacentre stuff, and Druva Apollo for things that specifically live in AWS, which I think is more for IaaS things.
Beyond that, I’m not really clear on how things would work on a day-to-day basis when I need to backup or restore data. It looks like there’s source-side dedupe going on, as well as encryption, and then I think data gets sent over the wire into the Druva AWS/cloud datastore thing.
Disclosure: Druva has previously approached PivotNine about us doing some consulting work for them, but PivotNine has not done any work for Druva at time of writing, nor do we have any pending work we’re about to start doing for them. PivotNine may do work for Druva in the future, but that’s true of any company that approaches PivotNine and wants to pay our fees.