Discussions related to using object storage as a backup target.
Post Reply
PXAbstraction
Influencer
Posts: 19
Liked: 1 time
Joined: Jun 09, 2023 2:53 pm
Full Name: Gerry Corcoran
Location: Ottawa, Canada
Contact:

Azure Immutability Architecture Question

Post by PXAbstraction »

Hey all.

I've got some questions about using Azure immutability. I've read up on the process for setting it up and Microsoft's documentation on it, but it's still left me with a couple of questions I need to answer to design the best solution for our client.

Right now, the client's setup is relatively simple in terms of Azure. They backup all their servers locally, then put a daily copy of those backups into an Azure Blob with 7 day retention. All the more complicated archival retentions (GFS etc.) are done on their local storage as they only have so much they can spend on Azure, though they do have a desire to start keeping some longer term backups there eventually as well.

I know you can't change existing backup storage accounts over to immutability without breaking things so if they wanted to start using that, they'd need a new storage account. The client is OK with just starting a new backup set in the new storage account and then just deleting the old one once a new 7 days have passed. The problem however comes with doing merges because if the data's immutable, Azure won't let that happen.

My questions are the following: Is immutability a viable option for daily backups on a short retention? If so, what's the best way to configure that to allow merges, or would just a new full be required every 7 days? Or is using immutability only a viable strategy for longer term archival backups?

I know these probably sound simple, but it's my first time working with immutability and these are a couple of things I'm just not sure of. Appreciate the help.
Mildur
Product Manager
Posts: 8979
Liked: 2375 times
Joined: May 13, 2017 4:51 pm
Full Name: Fabian K.
Location: Switzerland
Contact:

Re: Azure Immutability Architecture Question

Post by Mildur » 1 person likes this post

Hello Gerry
The problem however comes with doing merges because if the data's immutable, Azure won't let that happen.
There are no backup files (vbk, vib) as you know them on object storage. Therefore there will be never any "merge" happening.
Object Storage used a forever incremental approach. Data blocks of a backup file will be offloaded as unique objects/blobs to Azure Blob storage. You can see them if you browse through the Blob container. Small 500-600 kb objects instead of VBK/VIB files.
Instead of merging , we will extend retention of the oldest objects if they are still required by the newest restore points for a restore.
My questions are the following: Is immutability a viable option for daily backups on a short retention? If so, what's the best way to configure that to allow merges, or would just a new full be required every 7 days? Or is using immutability only a viable strategy for longer term archival backups?
7 days is ok, but keep in mind that we add 1-10 days of additional days in the background to the immutability period of each object. This is done to lower the API costs for extending immutable period on unchanged blocks.
Please see our user guide for an explanation of the Block Generation: https://helpcenter.veeam.com/docs/backu ... ml?ver=120

Best,
Fabian
Product Management Analyst @ Veeam Software
PXAbstraction
Influencer
Posts: 19
Liked: 1 time
Joined: Jun 09, 2023 2:53 pm
Full Name: Gerry Corcoran
Location: Ottawa, Canada
Contact:

Re: Azure Immutability Architecture Question

Post by PXAbstraction »

Hi Fabian.

Thanks for this information. It's taken me a bit to wrap my head around it, but I think I get the gist of things now. So to confirm, you're saying that 7 days of retention should still work, there just may be a couple of days added to the immutability period for Block Generation? I don't think that'll be a problem for my client.

Thanks.
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 6 guests