Immutable Backup on Azure Blob (immutable blob storage)

[dalbertson]

Correct, bucket level immutability will not work. And if it did it wouldn’t be supported.

[bit_inspector]

Does Veeam got any wind of Microsoft deploying a feature similar to AWS S3 immutable?

[Vitaliy S.]

I believe once there is any news on this, Gostev will definitely share it. For now, there are no changes in this functionality. Thanks!

[jim.lowry]

AWS is not the only supported vendor. S3 API requirements exist, and we have an unofficial support list of vendors using the supported S3 API version. See here:object-storage-f52/unoffizial-compatibi ... 56956.html

[Gostev]

I believe once there is any news on this, Gostev will definitely share it.

I actually have had news for a long time, but I can't share them here because they are under NDA. I would suggest reaching out to your Microsoft sales rep, maybe they will be willing to share their current plans in this regard in a private conversation.

[jim.lowry]

@Gostev - Not even for a scooby snack?

[wa15]

We are also VERY interested in this feature and have been following this.

Question: Azure supports WORM. How does AWS immutability compare with the WORM feature? Can WORM not be used in the same way?

[jim.lowry]

It's a function of HOW immutable data sits. WORM can apply to other media beyond object - and it may even be physical only... it's been too long, I'd have to review the nuances of WORM. If memory serves, WORM implementations like NetApp SnapLock will physically alter the actual disk geometry for the specified period of time. That would apply to spinning disks SAS, NL-SAS, and SATA. SSD MAY also be supported, but I've never had anyone ask me if they can brick really expensive SSD for a few years .

For us, our implementation of immutability is based on object storage and is controlled per object. AWS allows for object level immutability in their API which is why we support it. Azure currently is bucket level only. We're still waiting for the BLOB API to implement object level API calls.

[wa15]

Got it, thanks. Any news on IF this feature will be implemented in Azure at some point? And if so, roughly WHEN? Are we talking within a year or two?

[jim.lowry]

See @Gostev's note above.

[Slowrider5]

Got it, thanks. Any news on IF this feature will be implemented in Azure at some point? And if so, roughly WHEN? Are we talking within a year or two?

Best info I've heard is preview may be available by end of this year and GA in Q1 of CY2021. However, that is strictly from the MS side of the equation and could be subject to change. Veeam will obviously need time to test the feature and build in support for it.

[borismittelmann]

I guess we should vote massively to get this feature request noticed. Just 6250 votes should do.

[Mildur]

You have my three votes

[Gostev]

Don't worry about voting guys. Great timing for the post actually - we have just received all the technical documentation from Microsoft for the upcoming technology preview.

Everything is looking good and their implementation should fit right into our existing architecture, with the exception of enabling object lock on existing containers which already contain backups. This might be next to impossible for us to support, as I understand there are some significant differences in versioning design in Azure comparing to Amazon S3. We're clarifying this part with Microsoft.

[Mildur]

Thanks Anton

[frankive]

What is the appx. timeline before this could be implemented in VBR? The Azure immutable feature
And does that mean that also the latest bacup could be offloaded to the object repository with the immutable feature?
We were looking to implement a Ubuntu-server local to fullfill the 3-2-1-1-0 requirements regarding immutable and protection against Ransomware.
But an immutable Azure object storage and offloading the latest restore point (with a large GFS retention of course to protect against long time insiders) should fullfill out purpose.

[dalbertson]

@frankive it will take some time to develop this feature. V11 will be released first so I would recommend using the local immutable repo in v11.

[Gostev]

We will determine the release vehicle once Microsoft releases the preview of this functionality, and we can test our current prototype against it. I mean, it's going to be v1 of their Object Lock, what if there are scalability issues on their end? The fact that it is v1 makes things quite unpredictable.

But even if their implementation is flawless right out of gate, currently it looks like Microsoft is already running too late for this feature to make it into our next minor release (11a). Just to give an idea, by now we have already finished the implementation of all features that will go into 11a, and are in the full-scale testing stage for this new functionality.

And there's another dependency too: we cannot ship the feature before we test it with the GA version of the corresponding platform functionality. Shipping features based on testing with the pre-release platform code is not our style.

[frankive]

Thanks for the update!

For now we will planning for the local hardened repository or the Amazon S3 bucket and discuss with the customers what they would prefer in each case.

[dalbertson]

@frankive What will you be using for the offsite portion of 3-2-1 if you use the local hardened repo?

[frankive]

our local VCC partner (or an azure object storage in SOBR-repository).

VCC for fire protection (and insider protection) and local hardended for Ransomwareprotection with long term retention

[dalbertson]

Awesome, just wanted to verify that was being discussed as well. Just out of curiosity, what would make you go with Azure over AWS or vice versa? Is there a business requirement or is it usually up to customer preference?

[frankive]

It's just what we are most used too as a Microsoft shop..

But we are really looking into Amazon S3 now because of the immutable backup feature due to the increase of ransomware attacking backupfiles.

If the storing cost in Aamazon is appx. the same as Azure, I cannot see any reason to why not go for the object lock in Amazon S3.
Even If when we have years of backup wihh daily, monthly, year GFS retention Azure is dirt cheap. I think 3TB of data costs around 30-35 USD from what I remember from last invoice.
With that cost in also is a good candidate for us to NOT go for a hardened Linux repository

[klasikrkade]

I know we now have Linux hardened local repo available for use using immutability flags which is great. We were told by a rep late last summer that Azure blob immutability api support was coming in 11. I assume this is not available yet as I don’t see it anywhere in your documentation as being supported. Will this feature be available in a v11 update in the upcoming quarters? I also assume this is not supported with your backup for azure product yet?

Does anyone have any insight regarding this feature

Thanks

[Mildur]

We will determine the release vehicle once Microsoft releases the preview of this functionality, and we can test our current prototype against it. I mean, it's going to be v1 of their Object Lock, what if there are scalability issues on their end? The fact that it is v1 makes things quite unpredictable.

But even if their implementation is flawless right out of gate, currently it looks like Microsoft is already running too late for this feature to make it into our next minor release (11a). Just to give an idea, by now we have already finished the implementation of all features that will go into 11a, and are in the full-scale testing stage for this new functionality.

And there's another dependency too: we cannot ship the feature before we test it with the GA version of the corresponding platform functionality. Shipping features based on testing with the pre-release platform code is not our style.

Hi klasikrkade

Have a look at Antons explanation.

[dalbertson]

Thanks @Mildur

This process isn’t as simple as Microsoft releases and API and we add it and move on. This is a very important process for us to test very thoroughly. This is your important data and it’s being locked. We have to make sure that every possible scenario is checked and checked tons of times. Our QA teams are very thorough and we would rather push a feature than risk your data.

Plus one of the hidden things we do is to check every aspect of the api. There may be hidden things that can affect scaleability, security, architecture design, etc. so we must also make sure that the documentation is ready for such a feature.

Trust us, we are very excited about immutability with Azure. We will get it to market as soon as we can. Or as @Gostev always says “When it's ready”

[bg.ranken]

Is there by any chance any update on this feature and if it is close to being ready to release?

[dalbertson]

The release of the API was pushed by Microsoft. We are still awaiting the release.

[Gostev]

We will determine the release vehicle once Microsoft releases the preview of this functionality, and we can test our current prototype against it.

And after 3 more months, finally I have some good news to share: Microsoft has now given us access to the Private Preview of this new functionality, and we will be putting it through its paces for the next few weeks to see how well it performs. If all is well, I think there's still a good chance for us to squeeze this integration into V12.

[jim.lowry]

@Gostev That is great news! Thank you for sharing this. I've a few VCSPs anxiously waiting for object level BLOB immutability support. I know a few would be very eager to help with private beta testing when we reach that stage.