CFD3 Prep Post: Druva

This is part of my series of posts on Cloud Field Day 3.

Druva Logo



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.

Bookmark the permalink.


  1. Pingback: CFD3 Prep Post: Druva - Tech Field Day

  2. Hey, Justin. Thanks for the post. I’ll clarify a few things. Yes, we’re well regarded in our original market and we have companies happily backing up as many as 120K mobile devices (from a single company) to our solution. Our Net Promoter Score is over 75 last time I checked. Our endpoint product supports Windows, Linux, and Mac, along with Office365, Salesforce, GSuite, and Box.

    Our relatively new datacenter offering supports Windows, Linux, VMware, Hyper-V, AHV, SQL Server & Oracle. And yes, Apollo is designed for backing up AWS workloads. Version 1 is supporting EC2 only, but we’ll be expanding to the rest of their offerings.

    Yes, our differentiator is that we are indeed built on AWS and are a truly cloud native service. We are the only backup product of which I’m aware that can say that. All other solutions of which I’m aware essentially use AWS or Azure has a hosting solution for what is essentially datacenter software. We are built on AWS and architected to use it to its fullest advantages.

    We require no on-prem hardware and no VMs are associated to an individual customer. Instead our service runs in clusters of VMs and containers that are spawned according to current load. If a few customers are running backups, we’re spawning a few VMs & containers. If thousands of backups are running, we’re spawning 1000s of them to handle the various microservices required to handle that load. When the load reduces, we spin them down.

    Current backup data is stored on S3 (older backups go on Glacier) and all metadata (backup catalog and dedupe index) is stored on DynamoDB. The is why we can do global dedupe across 100s of thousands of mobile devices or thousands of VMs in your environment. Both S3 and DynamoDB just scale up to meet our needs. In contrast, the biggest dedupe appliances go to only a few hundred TB of deduped data before you have to start another dedupe silo. Not us. Grow as big as you need to with no architecting on the back end. In addition, our dedupe is so efficient, we tend to use about 1/3 of what competing dedupe offerings use to store the same data.

    Competing offerings run backup software in one or more VMs assigned to each customer’s account. These VMs run 24×7, and store backup data and metadata (catalog/index) on EBS. It’s also very common for these products to require some on-prem hardware. As you can see, this is very different than what we do.

    Yes, Druva does source-side global dedupe + AES-256 envelope encryption w/two keys, and TLS 1.2 during transit. In a restore our app supplies our key & you supply yours. Data is restored. No one at Druva can ever see ur data. Your key cannot be reset, so we strongly suggest customers use more than one admin.

    Restore options include direct from cloud, DR to cloud into ur AWS account (we convert VMs to AMIs), or local restore using optional & free CloudCache software you run on commodity hardware. This trio should meet the recovery needs of vast majority of companies.

    Does that clear up a few things?

Leave a Reply

Your email address will not be published. Required fields are marked *