In the past few years Immutability — the concept of making data unable to be deleted or modified — has been a core tenant of disaster recovery design and has driven the rise of Object Storage for backup purposes. To this point in the Veeam ecosphere, immutability has been contained to traditional Infrastructure backups, virtual machines, and cloud native instances. But in the age of ransomware, there has been a great appetite for this capability to apply to SaaS backups as well.
With the upcoming v7 release of Veeam’s Backup for Microsoft 365 (VB365) the product now has a method of allowing true, verifiable immutability, or object-lock on backup sets. In their interpretation of how to make this capability happen, Veeam has incorporated a long-known best practice for all things backup, adhering to the 3-2-1 backup methodology where there are two copies of the backup. This happens because immutability can only occur on the secondary copy of the backup set, leaving the primary set on unlocked, performant object store to ensure that recovery operations are achievable and optimized.
So What’s Changed?
Starting with VB365 v6, support for backup copies has been available, but only in very limited situations. First, the backups must land in Azure Blob or Amazon S3 for the first copy. Second, the copies can only go to related secondary locations. For example, backups residing in AWS S3 could only be copied to S3, S3 Infrequent Access or AWS Glacier storage. Further, while these backups can be encrypted, the object-lock — the object storage attribute that powers immutability — cannot be set.
With VB365 v7, this has changed. First, backup copies can now land on Azure, S3, or any S3-compatible backup storage that supports the necessary functions of the S3 API. Further, those backups can now optionally have the object-lock attribute set at the object repository level, with the immutability expiration automatically set to the duration of the retention period. In other words, unlike Veeam Backup and Replication, where retention points are set at the job level and immutability is set at the repository level, with VB365 both are set together at the repository level.
VB365 Immutability in Action
Here are the steps you’ll want to take when setting this up.
- Add primary object storage and backup repository.
On this repository is when you want to set your long-term retention as needed. Repeat the process until you have repositories to support your organization’s backup needs in accordance with best practices for maximum supported objects per repository.
- Add your secondary object storage and VBO repositories. These should arguably be setup in a different object storage environment as your primary copy but still well connected. Because you will be writing data that is set to object-lock for the retention period of the repository you should consider the shortest retention period here in accordance with your organization’s data policy and standards.
- Create backup jobs targeting your primary backup repositories. These will automatically copy to the secondary repository and become immutable as it is written.
11:11 Systems Impact
This capability is going to be a game changer for 11:11 Systems, our customers, and our partners. We will soon be able to support this long-requested capability on backups that reside on our cutting-edge Object Storage platform. Additionally, our customers and partners will be able to maintain a secondary copy of backup sets on disparate systems to ensure the durability of their backups. While there is no immediate roadmap for supporting this feature, we are excited by the feature and look forward to bring it to our customers and partners soon.
