Update 4 for Service Providers – Extending Backup Repositories to Object Storage with Cloud Tier
When Veeam Backup & Replication 9.5 Update 4 went Generally Available in late January I posted a What’s in it for Service Providers blog. In that post I briefly outlined all the new features and enhancements in Update 4 as it related to our Veeam Cloud and Service Providers. As mentioned each new major feature deserves it’s own seperate post. I’ve covered off the majority of the new feature so far, and today i’m covering what I believe is Veeam’s most innovative feature that has been released of late… The Cloud Tier.
As a reminder here are the top new features and enhancements in Update 4 for VCSPs.
- Cloud Tier
- Cloud Mobility
- vCloud Director Support for Cloud Connect Replication
- Gateway Pools for Cloud Connect
- Tape as a Service for Cloud Connect Backup
- vSphere RBAC Self Service Portal
- External Repository for N2WS
When I was in charge of the architecture and design of Service Provider backup platforms, without question the hardest and most challenging aspect of designing the backend storage was how to facilitate storage consumption and growth. The thirst to backup workloads into the cloud continues to grow and with it comes the growth of that data and the desire to store it for longer. Even yesterday I was talking to a large Veeam Cloud & Service Provider who was experiencing similar challenges with managing their Cloud Connect and IaaS backup repositories.
Cloud Tier in Update 4 fundamentally changes the way in which the initial landing zone for backups is designed. With the ability to offload backup data to cheaper storage the Cloud Tier, which is part of the Scale-Out Backup Repository allows for a more streamlined and efficient Performance Tier of backup repository while leveraging scalable Object Storage for the Capacity Tier.
How it Works:
The innovative technology we have built into this feature allows for data to be stripped out of Veeam backup files (which are part of a sealed chain) and offloaded as blocks of data to Object Storage leaving a dehydrated Veeam backup file on the local extents with just the metadata remaining in place. This is done based on a policy that is set against the Scale-out Backup Repository that dictates the operational restore window of which local storage is used as the primary landing zone for backup data and processed as a Tiering Job every four hours. The result is a space saving, smaller footprint on the local storage without sacrificing any of Veeam’s industry-leading recovery operations. This is what truly sets this feature apart and means that even with data residing in the Capacity Tier, you can still perform:
- Instant VM Recoveries
- Entire computer and disk-level restores
- File-level and item-level restores
- Direct Restore to Amazon EC2, Azure and Azure Stack
What this Means for VCSPs:
Put simply it means that for providers who want to offload backup data to cheaper storage while maintaining a high performance landing zone for more recent backup data to live the Cloud Tier is highly recommended. If there are existing space issues on the local SOBR repositories, implementing Cloud Tier will relieve pressure and in reality allow VCSPs to not have to seek further hardware purchase to expand the storage platforms backing those repositories.
When it comes to Cloud Connect Backup, the fact that Backup Copy Jobs are statistically the most used form of offsite backup sent to VCSPs the potential for savings is significant. Self contained GFS backup files are prime candidates for the Cloud Tier offload and given that they are generally kept for extended periods of time, means that it also represents a large percentage of data stored on repositories.
Having a look below you can see an example of a Cloud Connect Backup Copy job from the VCSP side when browsing from Explorer.
You can see the GFS files are all about 22MB in size. This is because they are dehydrated VBKs with only metatdata remaining locally. Those files where originally about 10GB before the offload job was run against them.
With the small example shown above, VCSPs should be starting to understand the potential impact Cloud Tier can have on the way they design and manage their backup repositories. The the ability to leverage Amazon S3, Azure Blog and any S3 Compatible Object Storage Platform means that VCSPs have the choice in regards to what storage they use for the Capacity Tier. If you are a VCSP and haven’t looked at how Cloud Tier can work for your service offering…what are you waiting for?
Object Storage Repository -> Name given to repository that is backed by Amazon S3, S3, Azure Blob or IBM Cloud
Capacity Tier -> Name given to extent on a SOBR using an Object Storage Repository
Cloud Tier -> Marketing name given to feature in Update 4