If you’re going to build a cloud-based data protection service, it behooves you to do everything you can to address the fact that all backup data must traverse a network to get to you. This means doing two things:
- Reducing the number of gigabytes that must be transferred
- Ensuring you use whatever bandwidth you are given wisely
Data reduction
The two keys to reducing the number of gigabytes that must be transferred and stored on your customer’s behalf are block-level incremental (BLI) backups and source-side global deduplication. Previously, BLI backups were the exception, but they have now become the norm due to virtualization. Both VMware and Hyper-V have APIs that allow backup software products to ask which blocks have changed since the last backup. So any products that would like to can very easily perform hypervisor-level BLI backup. A physical server running Windows can also provide BLI backups via VSS. Getting BLI backup from a Linux server requires the backup software system to provide it themselves.
Source-side deduplication is another really important feature, and (if implemented correctly) actually provides BLI backup as well. In fact, it can reduce the number of gigabytes transferred even more than a typical BLI backup can. But the best systems use the two techniques together. First, a BLI backup identifies what appears to be new blocks that need to be backed up. Second, the deduplication system chops those blocks into chunks and calculates a cryptographic hash on them. If the backup system has seen the hash before, it is considered redundant and not transferred. If it’s a new hash, it’s a new chunk, and is transferred to the backup system for storage.
The two keys to doing this successfully are doing the hash table lookup in the cloud so the dedupe is global, and storing the chunks for fast restores. Most backup systems do neither of these things, meaning they transfer more gigabytes and get slower restores from the cloud due to inefficient storage design. But if you’re going to design a cloud-based data protection service, you need to get both of these right.
Bandwidth management
I’ve seen many backup products that overwhelm the networks they use. In fact, I have a very solid memory of completely killing a bank’s network early in my career due to a bad backup decision I made. If you’re going to backup across the Internet, you need to manage that bandwidth effectively. You need to do everything you can to manage the available bandwidth and minimize any retransmit that simply wastes bandwidth.
You also need to be able to throttle backups back if they’re consuming too much bandwidth. This can be manually, by specifying maximum bandwidth usage as a raw number or percentage of available bandwidth. But a truly impressive product simply monitors how its behavior is affecting available bandwidth and adjusts accordingly. It uses all the bandwidth it needs as long as no one else needs it, and without negatively impacting anyone else. But the moment that changes, it should automatically throttle back.
Be a steward of your customer’s bandwidth
Your customers pay dearly for this bandwidth, so make sure you are wisely using whatever they give you. Using too much simply because you don’t have BLI backups, source-side global deduplication, or bandwidth management is unacceptable.
At Druva, we understand the challenges of next-gen data management, and developed the Druva Cloud Platform to offer simple, scalable, cost efficient storage with accelerated data access to eliminate complexity, no matter the business case. Reach out for a demo today, or read a case study for a look at how customers leverage the Druva Cloud Platform to reduce TCO up to 50%.