Capacity tier (Azure Blob) immutability and storage

[tjdoc]

Hi
Please could someone help with understanding immutability when applied to an Azure capacity tier of a SOBR.
This doc suggests that the amount of time a backup file will be stored is "retention period + immutability period + block generation"
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

So does this mean as follows:
-Backup Job Retention 30 days (performance and capacity)
-Performance tier immutability 30 days (because we want to make sure nothing can remove/tamper with the backup for 30 days)
-Object / Capacity Storage Immutability 30 days (because we want to make sure nothing can remove/tamper with the backup for 30 days)
-Block generation 10 days
-Backup chain - forward inc. with weekly synthetic

Therefore when a backup file is offloaded to the capacity tier, it will stay on cloud storage for 70 days before it can be removed?

I don't think I'm understanding correctly as if this is the case the storage costs will be huge...is that correct?

Thanks for any help

[Mildur]

Hi TimD

In your scenario, offloaded blobs/objects will be kept for 70 days, correct.

Please note, there are no "files/backup files" on object storage. Each restore point is split into small unique data chunks and offloaded as blobs/objects.
After the initial offload, in every offload session we will only transfer new or changed data chunks (forever forward incremental offload) to the capacity tier.
Most of the offloaded data chunks will never change in your production VM and therefore stay in Capacity Tier for forever. The backup server will only extend the immutability of these blobs every 10 days, because they are required to restore from newer restore points as well.

You can use our calculator for estimating the required storage on Azure Blob: https://www.veeam.com/calculators/simple/vbr/machines




Best,
Fabian

[tjdoc]

Thanks Fabian, I'll go through examples of the calculator and see what it shows.

So, in terms of the offload, does this mean that each week when a new synthetic full is created locally, it doesnt then copy the full data size of the .vbk to the capacity tier, only the incremental data size?
This appears to be different to what I'm seeing on our local storage, as when a new full .vbk file is created, the full data size is stored on the local disk.

Thanks
Tim

[Mildur]

Hi Tim

So, in terms of the offload, does this mean that each week when a new synthetic full is created locally, it doesnt then copy the full data size of the .vbk to the capacity tier, only the incremental data size?

Correct. Even if you run an active full backup on VMs with offloaded backups, only changed or new blocks will be offloaded to the Capacity Tier in the Scale-Out Backup Repository (SOBR), never the entire full backup.

This appears to be different to what I'm seeing on our local storage, as when a new full .vbk file is created, the full data size is stored on the local disk.

May I ask what type of repository you are using in the performance tier?
This behavior depends on the type of repository and the file system you are using.

For instance, Windows repositories with the ReFS file system and Linux/hardened repositories with the XFS file system allow the backup server to utilize our FastClone feature to create fast and space-efficient synthetic full backups. Instead of writing all data blocks to a new full backup file, we will ask the filesystem to write data blocks of changed and new backup data and reference to blocks already on disks from the previous full backups and incremental backups. In Windows Explorer, you may see the VBK file listed at its full size, but on the block level, it only consumes storage corresponding to the new or changed blocks.

There are also other repository types which support FastClone, such as deduplication appliances or object storage used as direct targets for jobs.

Best,
Fabian

[tjdoc]

Hi Fabian
I've only been testing this aspect of backups with a Windows file system which does not have any ReFS disk...so that's probably why. I do have a Linux XFS repo target as well so I'll create some backup data on that and see if its any different, that does support FastClone so providing I can actually see the real file sizes I should get a better idea on space used.

Can I just ask one other question around immutability please?
On the local storage, the documentation states that immutability will not apply to the backed up files until the last incremental backup of a chain has been created.
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
So if we were to take weekly synthetic full backups, this implies that days 1-7 will not be immutable until the next synthetic full is created on day 8 - isn't that a risk in the event of a ransomware attack during days 1-7?

Thanks

[Mildur]

Hi TIm

Of course.

On the local storage, the documentation states that immutability will not apply to the backed up files until the last incremental backup of a chain has been created.

Maybe you can share the exact statement where you found that information?

I assume its "The count of the immutability period starts from the moment the last restore point in the active backup chain is created"?

Immutability applies immediately after a restore point is created, whether it’s a full backup or an incremental backup.

Let’s assume you have configured a 30-day immutability period. What we mean in the help center is that all backups in a single backup chain (both full and incremental backups) will be immutable for 30 days from the date of the most recent restore point in that backup chain. Each restore point within that backup chain must remain immutable for the entire 30-day period.

If only the latest incremental backup file were to remain immutable while the other files in the chain became mutable again, this could pose a risk. An attacker could delete the full backup, making it impossible to restore from any of the incremental backups that depend on it. Therefore, ensuring that all restore points within the backup chain are protected by the same immutability period is important.

Best regards,
Fabian

[tjdoc]

Hi Fabian
Yes that was the statement - my interpretation was wrong which I'm happy about as it didn't make sense to me
So actually, in this example, the very first backup on day 1 would be immutable for 37 days in total, starting from day 1.
I think that's right...?

Thanks very much for clarifying...

Tim

[Mildur]

With hardened repositories, we do not add an additional +10 days.

The full backup of a new backup chain will be immutable for the 30-day period you have configured. On the following day, when you create an incremental backup, we set the immutability of that incremental backup for 30 days and extend the full backup's immutability by 1 day to match the 30 days of your new incremental backup.
On the third day, when you create yet another incremental backup, it will also be immutable for 30 days, and once again, the full backup and the existing incremental backup will be extended by 1 day.

However, with object storage, the process is different. In this case, we add an additional +10 days because extending immutability every day can become costly due to API calls. Therefore, we add +10 days to the configured immutability period from the beginning, allowing us to extend the immutability every 7 to 10 days instead of every day.

Best,
Fabian