Moving backups to archive tier

Let me say it now, and I’ll say it a lot below, I’m not super familiar with Azure as I don’t do much cloud computing and I use Wasabi for S3 compatible object storage.  But I’ll take a crack at this, and people can correct me if I’m wrong….

• My understanding is that if you wanted to move data to an archive tier and you’re already using a SOBR, you would just add your archive bucket/container to the SOBR as the archive tier.  Perhaps I misunderstand that though as I’m not using archive tiers.
• I believe the immutability flag is based on when the file is written to the repository and doesn't have anything to do with the retention policy (based on when the backup was taken).  This is the reason that if your retention policy is shorter than your immutability flag, immutability will hold on to the file which will be marked for deletion and should be deleted after the immutability flag expires.
• I personally when using Wasabi would use a different bucket.  If the same server is accessing the bucket (in the case of the Wasabi/S3 compatible storage), then I think you’d be fine to use a different folder.  I can’t speak for Azure containers though - I was under the impression that the different tiers use different containers and it’s not set at the folder level.  Again, not super knowledgeable of Azure storage here, so I could be wrong.
• My guess here is that if you had a proxy server in Azure that can access both containers, this would possibly eliminate the data egress/ingress because it’s all staying withing Azure.  That said, I’m not azure expert, but that’s what I’d at least be researching vs downloading to your on-premise server and then back up.
• If you have a hacker in the Veeam server, you’ve already got problems.  My recommendation would be deploying Veeam ONE and using it to monitor your jobs/infra and alert of changes made.  This would include stopping the copies to the archive tier.  I haven’t spent a ton of time with ONE, but I know that there is some alerting for these sorts of things.  Also note that with proper immutability, even the Veeam server can’t delete the data with the immutable flag set, so while they could stop moving data to the archive tier, newer data would still be protected in the capacity tier.  But if you are trying to protect your archive data, you’re going to need some monitoring in place to make sure that continues to happen.

I’m not super familiar with using VBR to store backups in Azure, but I am more familiar with Azure for other uses.

Azure “blobs” (like “objects” in S3 storage) in object storage as you’re referring to, each “blob” has it’s own storage tier, “Hot”, “Cool”, “Archive”, so assuming Veeam sets the tier per object then there should be no need for separate containers or even separate folders in Azure. When you create a “container” you set a default tier, but when Veeam uploads objects it can specify a different tier to upload the objects as (I don’t know if Veeam actually does this, I just know that Azure supports it), the “default” tier for Azure Blob Storage is just what tier Azure will use in the event the uploading software doesn't specify a tier in the upload process.

So assuming Veeam actually takes advantage of the Azure capabilities, it shouldn’t be complicated to set up on the Azure side.

Unfortunately I’m not fully aware of how Veeam handles immutability with Object Storage platforms at all, but my assumption is if it’s set up properly then once data leaves Veeam and goes into Azure, it will be secured from anyone without other access to the Azure account. Blob Storage does support blob versioning and deletion protection, but I believe if someone had access to the Azure account they could still do things like delete the entire container, which would delete anything inside of it even if the contents have historical versions and/or protection from early deletion.

So from that perspective it’s basically the same as any other storage platform. Once the data is out of Veeam, it’s “immutable”, but not to someone with access to the place where the data is stored.

@BackupBytesTim Thanks for explaining the different storage tiers within the same container.  I wasn’t aware that it did that but it makes sense to me at least.  More and more I learn that I need to learn a lot more about Azure and how it works.  :-)

Thanks @MicoolPaul for all of this.  I knew you’d have the answer to these questions and I’m happy that I had at least a few of them right or close to it.

As @dloseke already said, you’re in for a bad time if your environment is compromised, configuration change monitoring such as via Veeam ONE is useful (though arguably they can attack this too). But whilst they can impact new offloads to archive etc if you’ve got immutability end to end, they can’t tamper or delete your data until such immutability periods expire.

Thanks guys for the extensive explanation. Just tipping my toes here so excuse me if i come off ignorant. Would this mean i'd have to copy to archive tier well before performance immutability ends? This buys me some time when someone stops the archiving process.

Hi @Knuppel -

I’m just following up on your Archive Tier question. Did any of the provided comments answer your question sufficiently? If so, we ask you select which comment best helped you as ‘Best Answer’ so others who come across your post with a similar question may benefit.

If you do indeed have more questions, don’t hesitate to ask.

Thank you.