Cloud Only SOBR, Immutability and GFS, Separate Containers

[RobMiller86]

Lots of threads on this lately but I guess my question is a bit different so starting a new thread.

Goal is to have a simple small customer deployment. Windows server with VBR Ent Plus storing backups for up to 10 VMs locally, no immutability locally due to Windows. Then a SOBR with separate containers for performance: hot, capacity: cool, archive: archive in Azure. One storage account, with 3 different containers. Immutability only enabled on the performance extent hot container for 7 days. This SOBR will be configured to move backups after 14 days for the operational window to capacity. Archive for GFS after 90 days.

We will have a copy job from local backups to this cloud SOBR once per day, periodic. GFS on the copy job set to keep 4 weeks, 3 months, and sometimes longer than 3 months, including annual backups for certain customers.

It's my understanding that immutability will only be set on the hot tier and for 7 days (in reality a bit longer I believe). Immutability will not follow GFS backups down to the cool and archive tiers as those containers do not have immutability enabled. We only desire immutability for recent backups, so that older archives could be deleted if desired.

My questions are regarding storage usage. If we do this, will it essentially maintain full backups chains in each of the tiers? Or will it use some of the Veeam magic similar to synthetic fulls? I'm concerned that maintaining the backups in separate containers like this will eliminate any storage savings from the deltas from the fulls. Will it maintain essentially a full backup in each container so each tier is a separate independent chain or will it combine all tiers and reference blocks between the tiers?

I have essentially the same question with Veeam Backup for Azure. If we set 3 different containers, with immutability only on the daily tier going to hot, and the weekly and monthlys going to a different container as cool without immutability, will it double the backup storage used between the two containers? Or will it reference blocks between the containers saving storage on the deltas?

[RobMiller86]

Another scenario that I am curious about.

Single storage account, default to hot, with a single container that has immutability enabled. Hot folder and cool folder inside this container.

Cloud SOBR:
Performance = St Acct Hot folder, immutability set to 1 day (it adds 10)
Capacity = St Acct Cool folder, check box to use cool tier, immutability set to 7 days (it adds 10 more I imagine)

Capacity tier policy set to move backups older than 14 days from Performance to Capacity.
Daily copy jobs from local repo up to the Cloud SOBR with GFS enabled.

In this scenario, I am assuming GFS backups will not have immutability enabled beyond the repo period that is set as we are using the move policy, even though they are moving in the same container, simply different folders. Is that correct? Is moving between folders in the same container enough to disable GFS immutability beyond the repo setting?

If the scenario I outlined in my first post isn't storage efficient, if it maintains a separate and complete chain in each container, is there any storage benefit to using this second method outlined in this post and having both performance and capacity extents in the same container? Basically, is there a difference in efficiency between using separate folders in the same container vs using separate containers for each extent?


It's probably pretty clear but my goal is to have a solution for on-prem VBRs copying to Azure

• With immutability in Azure for recent backups only

• With the option to have lengthy retention without immutability on older backups

• Making it as storage efficient as possible keeping costs as low as I can.

Then similarly, replicating this methodology for VBAZ deployments, with the same goals of short-term immutability protection, with long time archives that could be deleted if desired. If there are any better suggestions for how to accomplish this, I'd love to hear them!

Thanks,
Rob