Born in the cloud companies approach problem-solving differently to on-premises software companies, so Druva looks at the world differently to other enterprise backup vendors. One difference is the expectation that infrastructure is rented from cloud providers, rather than purchased from hardware vendors and deployed on-site. Druva offers Backup-as-a-Service and prefers to deploy as little infrastructure as possible inside their customer’s environments. Initially, Druva provided a backup solution for distributed endpoints (laptops and PCs) that live outside the corporate offices. Highly mobile staff who generate business data are a prime target for endpoint backup, and backup to the public cloud works extremely well for these uses. More recently, Druva has added support for enterprise virtualization as a data source for backup to the cloud.
My latest time with Druva was at Tech Field Day 19, here’s my Tech Field Day disclaimer post.
I spent a little time last year playing with Druva’s data center backup product, and it seems that I just didn’t get what Druva is all about. Druva is cloud-first and all cloud for backup and archive storage. My preference is for an on-premises backup and has cloud storage for archives. I have a feeling that the mismatch between my expectation and Druva’s is down to location. Druva is in Silicon Valley, where Internet connections are hundreds of megabits to gigabits per second, and Amazon’s data centers are a dozen milliseconds away on the network. Here in New Zealand, it is a little different, a hundred megabit Internet is good, and the nearest AWS region is 60ms away. There is a different expectation of how fast data transfers to the cloud in New Zealand compared to Silicon Valley. I love Druva for protecting data on highly mobile laptops, even over New Zealand Internet connections, because each user has their own Internet connection. I’m less happy with server backups that might take six to ten hours to complete because thirty servers share the same Internet connection and latency to an AWS region is high.
You are not me; you may only have datacentres with gigabit range Internet and near to AWS regions. You may love Druva because there is no backup infrastructure to manage, just off-site data protection as a service. One great feature of Druva is the ability to take those backups of your on-premises, vSphere based VMs, and restore them as AWS EC2 instances without a lengthy conversion process. That is an excellent DR to the cloud story. As always with DR to the cloud, check that you can fail-back to on-premises.
You can find all of the videos of Druva’s presentations at Tech Field Day here: https://techfieldday.com/companies/druva/
For some other views of Druva take a look at these articles from other Tech Field Day 19 delegates:
Jim Palmer – Data, Data Everywhere, Nary a Byte to Eat
Adam Fisher – Data Protection as a Service With Druva
Liselotte Foverskov – Druva – Uber for Data Protection
Dan Frith – Druva – in the Cloud, of the Cloud, Protecting the Cloud
© 2019, Alastair. All rights reserved.
RSS - Posts
I appreciate the honest appraisal of our capabilities. Bandwidth concerns are the most common objection that we get, so I thought I’d add a comment. While the typical pipe in NZ may be smaller than what we typically deal with, we’re also typically dealing w/much larger data sets over here. So our customers actually the same concerns even with their larger pipes.
A VM should only take hours to back up if it’s its first time backing up. After that, bandwidth is much less of a consideration. Subsequent backups should finish in minutes thanks to block-level-incremental forever and source-side deduplication. Your vBrownBag test was a one-off so you really only saw that first backup. The first backup is definitely not our strong suit.
Bandwidth issues show up in the first backup and any large restores, and we do our best to address both. Initial backups too large for a customer’s available bandwidth are solved via Snowball Edge, which completely automates the seeding process using sneaker net, and its included in the price. Large restores can be handled three ways: CloudCache is included software running on a VM or appliance of your choice that holds a copy of recent data onsite, reverse seeding via Snowball Edge (RTO will be days), or DRaaS to an AWS VPC. Those seem to handle the bulk of customer concerns WRT large restores.
Every once in awhile the math doesn’t work out. The pipe’s too small, the dataset’s too big, or the daily change rate is too high. But you might be surprised how big the numbers are before we usually run into problems. All I’d say to a potential customer is to give Druva a chance to see if the math works for them. If it does, then you get a fully automated backup service without buying hardware or software that should cost less than the alternatives. If it doesn’t work, there are many other products for you. 😉
Keep in mind that backups are only important to enable restores.
If the first, full VM backup takes hours then a full VM restore is also likely to take hours.