Unable to manually delete objects from S3 even after immutability period.

[ConradGoodman]

I configured a copy backup job with GFS monthlys, quarterlies, yearlies. Destination is an SOBR with S3.

I set immutability to 1 day only.

When I go into the 'blocks' folder within S3, the object lock properties are set for 10 days time (29th May).

Obviously this is for testing purposes and I wouldn't generally be doing this, but why is the immutability set for 10 days instead of the 1 set on the Object Storage repo? Is it something Veeam is doing to ensure the blocks it needs are not deleted for the backup chain later on?

Also if I 'empty' the bucket it deletes nothing.

[sfirmes]

@conrad.stephens We have a concept called Block Generation which adds a 10 day buffer to the immutability duration. A great explanation of Block Generation can be found here https://helpcenter.veeam.com/docs/backu ... ml?ver=100.

Hope this helps.

Steve

[ConradGoodman]

Hi Steve

Great explanation thanks.

So if I were to accumulate GFS backups for 12 months in Object Storage, would it re-use the same blocks as much as is possible every month, effectively deduplicating the cloud object storage?

Is there any reliable way to calculate how much object storage a dataset will need when using GFS archives monthly, yearly?

[sfirmes]

We use a block cloning/ReFS like method to send only unique blocks to the Capacity Tier (S3 target). There is a sizing calculator that you can use https://rps.dewin.me. Make sure you check the ReFS/XFS box and this will give you an estimate of your sizing needs.

[veremin]

So if I were to accumulate GFS backups for 12 months in Object Storage, would it re-use the same blocks as much as is possible every month, effectively deduplicating the cloud object storage?

Correct.

As to the said checkbox, it mimics the forward forever incremental nature of our object storage integration.

Thanks!

[ConradGoodman]

I have used the simulator as suggested, and it appears to save no space at all?

[Gostev]

I cannot comment on the calculator as this is the community project, and it may have bugs in certain scenarios.

However I would not count on too many matching blocks between yearly restore points to start with. It's just too much time to hope any similarities still remain, unless of course we're talking about some completely static workloads (like file server with files that never change).

On the other hand, you will see much savings between weekly GFS restore points, for example.

[ConradGoodman]

I'm talking about a SQL Database, that has 4 years of data retention in it before it gets deleted.

So there would be a fair chunk of overlap, especially between the last 4 years of GFS yearlies.

[Gostev]

In that case, you will get good savings for sure. However, this kind of specifics are hard to capture in a general purpose calculator