Mix different object storage provider

[cristiano.cumer]

Hello Forum,

it's supported to mix different storage provider?

For example Wasabi for Capacity and Amazon Glacier for Archive?

Thanks!

Cristiano

[Mildur]

No, that will not work.
For the archive tier, the data needs to be on the capacity tier of the same provider.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Each type of repository that can be added as an archive extent is compatible only with corresponding type of repository configured as a capacity extent:

- To add Amazon S3 Glacier as an archive extent, select Amazon S3 repository in the capacity tier settings. If you do not have an Amazon S3 repository as a capacity extent of your scale-out backup repository, you must first configure it.

- To add Microsoft Azure Archive storage as an archive extent, select Microsoft Azure Blob repository in the capacity tier settings. If you do not have a Microsoft Azure Blob repository as a capacity extent of your scale-out backup repository, you must first configure it.

[cristiano.cumer]

Thanks!

Let's hope for the future that archiving form a S3 compatible provider to Amazon Glacier will be supported.

The rationale behind this:
Cheap intermediate S3 storage that I can lose without problems, GFS backups stored on Amazon for long there retention, as Amazon will be there for a foreseeable future.

[pirx]

Is this on the road map already? We have the simple task of migrating capacity tier extents from AWS S3 to Wasabi. With migrating I don't mean moving the old data. Just use Wasabi for new backups.

Our first idea was to add the Wasabi bucket as second extend to capacity tier. But this does not work, AWS S3 and Wasabi can't be mixed. Which is kind of strange as it's both type S3 storage.

There seems to be no good was to migrate, there is no second performance tier available for a new SOBR. And we need to be able to restore from old capacity tier.

Any ideas without egress costs?

[veremin]

Just use Wasabi for new backups.

Not sure whether I completely got your question - but if you're planning to use Wasabi for new backups only, why not to create a new Scale-Out Backup Repository in this case and leave the old one for the restoration purposes?

Is this on the road map already?

Currently, there are no short-term plans.

Thanks!

[pirx]

A new SOBR requires a performance tier and we do not have any additional on-prem performance tier / device at the locations. I now received different feedback from support and our local Veeam contacts. For me it's unclear if I can just remove the old bucket and add a new Wasabi. Then import the old bucket and have the old backups available for restore. I remember having a case a few years back where I had to replace a bucket because it had a lot of inconsistencies and failed to import it later to the samer VBR server. Support told me then that I could only import it to a different VBR (disaster scenario) due to duplicate IDs.

[pirx]

I just found my old case 04618351 from 03/2021. I'm not sure if this was 100% identical but basically I also removed a bucket, added a new one and wanted to import then old one. Which didn't work.

I discussed the possible options with QA.
They confirmed me that S3 extent cannot be imported to the same server as long as the older backups of the same job still exist.
Import to another VBR server should function well.

But this is not so much about mixing different providers as importing capacity extents to same VBR server which I brought up back in 2021 here post406580.html#p406580

[veremin]

For me it's unclear if I can just remove the old bucket and add a new Wasabi. Then import the old bucket and have the old backups available for restore.

This is absolutely possible, and we do not expect any issues with this scenario. You can remove the previous capacity extent from the SOBR configuration and then import backups from it. After that, you will see backups and will be able to restore them. Thanks!

[pirx]

Did you see my last post and the quote from an old case where I already tried this?

I discussed the possible options with QA.
They confirmed me that S3 extent cannot be imported to the same server as long as the older backups of the same job still exist.
Import to another VBR server should function well.

[veremin]

This was true in the previous product version in the case you reported, which, as I understand, was thoroughly investigated and for which you received several hotfixes.

These hotfixes are now part of v12, so we do not foresee any problems with the workflow described:

You can remove the previous capacity extent from the SOBR configuration and then import backups from it.

Thanks!

[pirx]

The hotfixes were not for the import issue. But if you and support now a sure it was a v11 issue and is working in v12, I'll take this road.

[veremin]

Yep, we certainly believe so: in v12 you should not see any problems with the scenario mentioned.

Kindly, let us know the outcome.

Thanks!