News/Trends, Tech/Engineering

Why Druva was architected for the cloud

February 25, 2020 W. Curtis Preston, Technical Evangelist

Druva designed backup-as-a-service in the cloud because it was the only way to solve all of the typical data protection challenges that I have mentioned in two previous blogs. The first blog explored how difficult it is to size, purchase, and maintain a backup system, which also requires juggling many vendors. The second blog discussed how challenging it is to tune the performance of tape, as well as how difficult, risky, and costly it is to get tape offsite. In addition, it also covered how burdensome it is to scale backup systems and manage unexpected costs.

Industry response to data protection challenges

In other posts, I have also covered how the data protection industry attempted to solve these challenges over the years. Target deduplication systems helped to solve tape performance issues and brought disk backup to the mainstream, but they were really only a band-aid on a much bigger problem. Other companies responded with fully disk-based backup products aimed specifically at the new virtualization market. Unfortunately, backup systems based entirely on disk introduced a new risk because they eliminated the air gap tape provided.

Hyper-converged backup products made things simpler by reducing the number of vendors and products that customers needed to maintain. Furthermore, hyper-converged backup products made it easier to scale your backup system, but they still didn’t address the issue that backup servers and storage must still be maintained by the customer.

None of these advancements addressed the issues associated with large capital purchases. Backup storage hardware must be purchased way in advance before it is ever needed and goes unused most of its life. Just when storage gets close to full utilization, the customer must purchase a whole new set of storage hardware that will go mostly unused as well. That is an incredible amount of waste.

Finally, all of these products were designed to run in a data center, not in the cloud, and simply running backup software in a VM in a cloud (i.e. cloud-washing) does not make it a cloud product. It’s just a more expensive way to have a backup server. I also explained that even if a vendor takes care of all of the maintenance, the fact that the product was not actually designed for the cloud will show up in significantly higher costs for the customer.

Druva took a different direction

Druva’s founders felt that the only way to solve all of these data protection challenges was to start from scratch with backup-as-a-service designed for the cloud. Let’s review those challenges again and see how Druva addresses them.

  • Sizing a backup system – Druva automatically scales up and down throughout the day to meet the needs of our customers. The customer doesn’t have to do anything to size the backend. The system will automatically give customers all of the power and storage they will need.
  • Purchasing the hardware and software – There is no hardware or software to purchase with Druva. Everything is included with the service, which is billed on a per-user or per-terabyte basis, depending on which product you’re using.
  • Maintaining the OS & backup software – All systems are automatically maintained and updated as necessary by Druva. Customers never log in, nor do they have to manage backup servers or storage.
  • Managing multiple vendors – The only vendor Druva customers need to interface with is Druva.
  • Tape management issues – There are no tapes in Druva’s infrastructure.
  • Offsite storage costs – All Druva backups are stored in Amazon Web Services (AWS) S3 storage, which is replicated to three availability zones. It’s like having three copies of your backups in three Iron Mountain locations – without having to manage them.
  • Unexpected costs – Our customers’ costs are very predictable. The customer pays only for the resources they consume, a bill that stays roughly the same every month. Druva’s customers also do not pay egress charges the way our competitors’ customers do.
  • No air gap – Druva customers’ backups are encrypted and stored in AWS S3, which is configured in such a way that only our application can read and write to your backups. There is no direct way to access customer backups from a customer account; they can only be accessed via our backup and recovery application.

A cloud service designed for a new future

Druva’s services automatically scale to meet any customer’s needs and at a price typically half the cost of our competitors. This is due to our design that fully utilizes the elasticity of the cloud. We also offer some of the best RTOs and RPOs in the industry; if you don’t believe us, put us to the test. Our service, designed from the ground up to run in the cloud, is really the only way to handle all of the data protection challenges of the past, while also preparing for the data protection challenges of the future.

Learn more about the Druva Cloud Platform and why Policy Services, a UK-based financial firm, relies on Druva for their data protection and backup.