Wasabi S3 - never any deleted items

[TonioRoffo]

Hello,

I'm testing Wasabi S3 as a SOBR capacity tier for a while now, and I'm still not observing any deleted objects in the utilization overview.

I'm using following settings in wasabi:

* Versioning: Enabled
* Object Locking: Enabled
* Bucket-Level Object Retention: Off
* I have contacted Wasabi to change the storage charge time from 90 to 30 days.

On the Veeam side: SOBR with:

* Data locality
* Copy backups as soon as they are created ON
* Move backups to object storage as the age out ON
- Move backups older than 28 days (operational window)

Veeam S3 capacity bucket:

* Make recent backups immutable for 30 days

The Backup jobs themselves:

* Retention policy 7 days
* Keep certain backups longer for archival purposes - 4 weekly, 6 monthly, one yearly. Synthetic backups on saturdays, schedule backup every day, once per day

In this setup I'm assuming that my performance storage AND capacity tier are keeping one months worth of backups and the capacity tier is keeping my long term backups. This all seems to be working, at least from the backup view in Veeam.

For example, I see a backup in the capacity tier being retained, 1st of october, as a monthly backup. All the rest of that month (weeklies, dailies) are gone. In this situation I assume that at least some blocks aren't supposed to be kept on the capacity tier anymore and they should be marked as "deleted" on the utilization overview on Wasabi, is that correct to assume?

I don't want to make this into a case yet, just looking for feedback on a possible wrong assumption or misconfiguration on my part.

Thank you!

[TonioRoffo]

OK, it might be me, looking wrongly at the Wasabi S3 statistics. There are no deleted items, but sometimes I see the storage going down with a few gigabytes per day vs the older days.

Is there however, a log to see if objects are being deleted on S3 storage?

[Mildur]

Hi Yves

I suggest opening a case with our support if you think something is wrong.
Looking at your settings everything should be ok. There is only one problem I see.
You configure your immutability to 30 days on capacity tier, but you only want to keep 7 daily restore points.
Unused blocks of this incremental backups cannot be deleted for 30 days + ~10 days (block generation).
Retention should be higher or similar to the immutability period.

Thanks
Fabian

[TonioRoffo]

Thank you, Fabian.

I will change that. I did this to keep the data low on the performance tier, but of course looking at it, it should be better to have similar retention - even if I have 4 weekly GFS synthetic backups.

[Mildur]

You can still use the move policy. Configure the move policy to 7 days operational window.
And the retention of the backup job to 28 days.
This will allow you to keep at least 7 days (can be 7-14 days with this setting) on the performance tier, but 28 days on capacity tier.

Thanks
Fabian

[Kazz]

Would this Wasabi policy apply to your case? Assuming you are a pay as you go customer so the earliest delete you would see is gonna be 90 days.

Wasabi has a minimum storage duration policy that means if stored objects are deleted before they have been stored with Wasabi for a certain number of days, a Timed Deleted Storage charge equal to the storage charge for the remaining days will apply. This policy is comparable to the minimum storage duration policies that exist with some AWS and other hyperscaler storage services.

With Wasabi minimum storage retention policy, minimum number of days are as follows:

90 days (default) for customers using Wasabi’s pay-as-you-go (pay-go) pricing model
30 days for customers using Wasabi’s RCS pricing model

[Mildur]

You can contact wasabi support after your first offload and they should set the minimum storage policy to 30 days for buckets which contains veeam backups.
Even if you use the pay-as-you-go model.

Best,
Fabian