azure immutable days

[apolloxm]

Hi,

We are using the V12 to support azure immutable. we configured the backup copy jobs to azure with the immutable days to 4 days so the totally immutable days would be 14 days. and we set the retention policy to 14 days. the job will be run at every thursday. We didn't enable the GFS on this backup copy jobs. So, it will run as forever incremental.

For the first week,Veeam will upload the full backup to azure, Next week will offload the incremental.

after the first week, when Veeam finished offload the data to azure,(on Nov 1st ) I tried to delete the data from Veeam, Veeam said we can't delete the data after 14 days. (until Nov 15th)

the second week, when Veeam finished the offload the data to azure, I tried to delete the data from Veeam again,Veeam said we can't delete the data after 14 days. (until Nov 15th).

My question: why the second week have the same days as first week? when the whole backup chain can be extended immutable period? will it start to extend immutable period in 11 days ? how can we make sure all the backup in the azure was immutale? Thanks!

[Mildur]

Hi Apollo

Block generation adds 1-10 days of immutability to each block. If there was no full backup in the second week, it may be possible that objects belonging to restore points have still the same immutable date.
Feel free to open a support case and let our customer support team check the logs. Logs will 100% confirm why those objects have the same immutable date.

Our general recommendation: If you want to have guaranteed 14 days immutable backups, you also should configure 14 days and not rely on the block generation.

Best,
Fabian

[apolloxm]

if we configured 14 days, it will take effect immediately?

[Mildur]

For new restore points and their objects. Older restore points won't be extended.

Best,
Fabian

[apolloxm]

Hello Fabian,

if we configured as 14 days, when the new block generation will be applied?

[Mildur]

Block generation is explained here:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

This is an example how block generations works with daily job sessions:

1st day: 1 Full Backup is written with 14 days immutability + 10 days (block generation)
2nd day: 1 incremental is written with 14 days immutability + 9 days (block generation)
3rd day: 1 incremental is written with 14 days immutability + 8 days (block generation)
4th day: 1 incremental is written with 14 days immutability + 7 days (block generation)
5th day: 1 incremental is written with 14 days immutability + 6 days (block generation)
6th day: 1 incremental is written with 14 days immutability + 5 days (block generation)
7th day: 1 incremental is written with 14 days immutability + 4 days (block generation)
8th day: 1 incremental is written with 14 days immutability + 3 days (block generation)
9th day: 1 incremental is written with 14 days immutability + 2 days (block generation)
10th day: 1 incremental is written with 14 days immutability + 1 days (block generation)

All objects belonging to this 10 restore points will have the exact same immutability expiration date on the bucket. That way, all restore points are immutable for at least 14 days. We don't need to extend immutability on a daily base. Extending each object every day will cost you alot of money for API calls against Azure.

After these 10 days, the process repeats itself again and starts with extending the immutability period and adding 10 days to all data blocks in the backup chain.

Best,
Fabian

[apolloxm]

one more question, when the block data that was expired and immutabled will be deleted during the Storage initialized or during the Full backup file merge?