Customer Stories

Q&A: Why Build Group Chose Druva

December 14, 2018
W. Curtis Preston, Chief Technologist

In this blog series, Adam Kailian, IT Systems Administrator at Build Group, has been discussing the highly successful construction company and how it has coped with increasingly complex data-management challenges. In this last post, he gives some history to the Druva/Build Group relationship and explains why it continues.

Q: Adam, how did you first learn about Druva?

AK: In previous jobs, I’d seen Druva at tradeshows and knew they had a strong reputation as a cloud-native service. It was easy to understand the key benefits, and I think their model reflects the way the industry is headed. Build Group had already chosen to deploy Druva Phoenix, a server backup service, when I joined them, it was a very happy coincidence, because I’d always wanted to see their platform at work. Setting it up was one of my first assignments.

Q: What was happening at Build Group that led to the deployment?

AK: I think people underestimate how much data is involved with a construction company, it’s huge, tons of graphic files and everything else. We were backing up to local storage hardware and it took forever, the network was regularly getting jammed up during business hours. We had to go to the cloud. Backing up mobile endpoints was an issue too, that’s been the case everywhere I’ve worked. You really need something simple and easy to make it happen on a reliable basis, and Druva took care of that too.

Q: What cloud services does Druva itself leverage?

AK: They’ve been pure AWS from the start. It’s hard not to be, AWS is secure, they’ve got an incredibly broad platform, everything from computing and storage to content delivery. Build Group had used Amazon Glacier for cold storage, so moving our data retention protocol to Druva was an easy decision. And when I’ve talked to Druva technical support, they’re completely behind AWS in everything, I know they work closely with them.  

Q: How exactly are you using Druva?

AK: We started with Druva Phoenix, their server data protection and management product. It’s comprehensive, it also does disaster recovery, archival, and analytics, and it’s got incredibly fast deduplication. We’ve been testing out restoring VMs from the cloud, with 200 Mbps fiber, we’ve restored 100 GB in half an hour and it would probably take less than a day for a 2 TB server.

Later, when we went to Exchange 365, we added Druva inSync, their endpoint product. People take for granted that data is backed up by cloud apps like 365 and Salesforce, but usually it’s limited, it takes time, and sometimes they charge you for restores. Druva inSync does a way better job of it and its as-a-service model made it an easy decision.

Q: Any future plans?

AK: Disaster recovery is always a big deal for IT groups, but Druva takes care of a lot of it just by its nature. If you can’t find a file to close a deal, that’s pretty much a disaster, and the Druva solution is all about making restores fast and easy, whether it’s a sales pitch on a lost smartphone or an entire VM after an earthquake. But disastery recovery is a lot more, and as we build out a more formal system, Druva will be an important part of our plans.

Next Steps

Download our Build Group case study and learn how Build Group and Druva formed a lasting relationship.

View the webinar featuring Build Group and learn more about solving the challenges of data management, protection, and governance.

Read the first blog in this Q&A series, “Customer Spotlight: Build Group,” and the second blog, “Q&A: Data Management Challenges Facing Construction Companies.”