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 Backups
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.
Pingback: CFD3 Prep Post: Druva - Tech Field Day
Thanks for the post, Justin. Yes, we are indeed well-regarded in the endpoint backup space. Some of the largest companies in the world use our endpoint product to protect their mobile devices or SaaS apps like Salesforce, Office365, or GSuite. Our Net Promoter Score is in the high 70s last time I checked, and Gartner lists us as #1 in that space. We are also the third biggest user of some of AWS’s services!
Phoenix, our relatively new datacenter product, builds on the backend cloud technology used in the endpoint product and supports Windows and Linux servers, as well as VMware, Hyper-V and Nutanix AHV. We support SQL Server and Oracle for now, and are examining other apps for the future. And you guessed right on Apollo. It’s a very new product aimed at protecting IaaS/PaaS workloads in AWS.
Yes, we are built on AWS. In fact, to my knowledge we are the only cloud-native data management service available today. Our service runs as a series of microservices on clustered VMs and containers, none of which are assigned to an individual customer. We just spin up more or less of them as needed based on the current load of the moment. Our customers never see, manage, or have to care about backup servers, as there simply aren’t any associated with their account. There is an authorization service, a storage service, and a configuration service. All backup data is stored on S3 and all metadata is stored in DynamoDB. We require no on-prem hardware, but do offer an optional and FREE offering called CloudCache that holds recent backup data for LAN-speed restores of large datasets.
This is very different from our competitors that basically use AWS as a hosting provider to run customers’ backup server VMs “in the cloud.” It’s the difference between Hosted Exchange and Office365, between Hosted SAP & Salesforce.com. I could go on, but suffice it to say what we do is VERY different from what our competitors do.
We do perform source-side dedupe that is global to your whole account (within a region) and uses roughly 1/3 the amount of storage of competing dedupe offerings. In addition, we charge our customers ONLY for the amount of actual S3 storage they consume after dedupe is done. We do not charge for an onsite copy if you use our CloudCache offering, and there is no charge for restores – including AWS egress charges. Again, this is all very different than our competitors.
Fat pipes into AWS are not necessarily needed. The hardest part is the first backup for a big customer and we can do that using a physical seeding option. Many customers install our software and start backing up while waiting for the arrival of a seeding system, only to find their first backup is done before they receive it. After that the incredibly effective app-aware global dedupe keeps traffic to a minimum. Restores are a different problem that I’ll get to in a following paragraph.
Before it is transmitted, customer data is wrapped in AES-256 envelope encryption with a key that we do not see or escrow. This is why we recommend customers have more than one admin, because if you have only one key and lose it — your data’s gone. So don’t do that. :) It’s then encrypted in transit w/TLS 1.2 and stored encrypted in S3. Our security model has withstood the toughest tests, and qualifies for FedRamp.
Restore options include direct from cloud, DR to cloud into your AWS account (we convert VMs to AMIs), or local restore using optional & free CloudCache software you run on commodity hw. This trio should meet the recovery needs of vast majority of companies. For the DR to cloud option, you do some config up front. You then have two choices: create the AMIs at time of disaster or have them done ahead of time and continually updated with each backup. The former is less expensive and the latter is much faster in a full disaster. It’s the customer’s call.
Hopefully that answered your questions without too much “competitor bashing.” As much as I hate talking about competitors, there is so much cloud washing going on that it’s really hard to explain how what we do is different than what they do without explaining a little bit about them. Thanks again for the article and the chance to comment.
Pingback: Druva Announces Cloud Platform Enhancements | penguinpunk.net