How to properly delete an old orphaned backup chain from an object storage repository

[massimiliano.rizzi]

Hello Community and good day,

first things first, Case # is 05721978.

As part of doing some housekeeping for one of our customers earlier this week, we noticed that the size of an existing Wasabi S3 bucket (part of a SOBR) reported in the Veeam Backup & Replication Console is 11.8 Terabytes, while the size of the same S3 bucket reported in the Wasabi Console is 16.69 Terabytes.

We believe the reason for that is related to the presence of an old orphaned backup chain in the S3 bucket, resulting from a failed attempt from our side to seed the initial upload to the Wasabi S3 bucket back in July as the initial upload consisted of several Terabytes.

Basically, we would like to get rid of this old orphaned backup chain in the S3 bucket, if possible, in order to avoid unnecessary costs and waste of space by importing the Wasabi S3 bucket on a second/helper VBR server, add it as repository (no SOBR) and "import" all of the existing backup chains.

After the import process is complete, I I would expect the old orphaned backup chain present in the S3 bucket to be visible in the helper Veeam backup server as well in order for us to be able to delete it.

Is it supported without interfering with the operations of the Veeam Backup Server used in production with the SOBR ?

I decided to reach out to the Community as the engineer sending out the initial response for the case above and the permanent engineer seem to contradict themselves.

Any help on this matter will be greatly appreciated.

Thanks and Regards,

Massimiliano

[Mildur]

Hi Massimiliano

What your last support engineer probably meant, was using direct backup to object storage.
This is a v12 feature and it is not related to your case.

From a product standpoint, it is not supported to use another VBR server to manipulate objects on an object storage container.
You can connect it to a second VBR server for doing disaster recovery tasks only.
I recommend keeping working with your support engineer on that issue.

Thanks
Fabian

[massimiliano.rizzi]

Hi Fabian,

thank you very much for your reply.

From a product standpoint, it is not supported to use another VBR server to manipulate objects on an object storage container.

To be honest, this is what I was afraid of.

You can connect it to a second VBR server for doing disaster recovery tasks only.

Regarding this possibility, please consider a scenario where the S3 bucket is configured on the Veeam Backup & Replication server used in production with the SOBR with an immutability period set to 30 days. When connecting it on the second VBR server, is it recommended to add it with the same immutability settings used on the Veeam Backup & Replication server used in production (in order to avoid interfering with the operations of the latter) or it simply doesn't matter ?

This question is not strictly related to my OP.

Thanks and Regards,

Massimiliano

[Mildur]

Hi Massimiliano

You have to enable immutability in Veeam if object lock and versioning was activated on the bucked.
The configured immutable time doesn't matter. This setting is stored only on the VBR server. And the second VBR server will not offload or remove objects by himself as long as you don't add it as a capacity tier to a SOBR.

Thanks
Fabian

[massimiliano.rizzi]

Hi there Fabian,

The configured immutable time doesn't matter. This setting is stored only on the VBR server. And the second VBR server will not offload or remove objects by himself as long as you don't add it as a capacity tier to a SOBR.

thanks for the information.

Regarding my OP, I have just arranged a quick phone call with the support engineer in order for me to provide him with some more information and see what we can do.

I wish you a great weekend ahead.

Regards,

Massimiliano