Most likely your configuration backup job is target to the repo, which you want tho convert to a SOBR.

you need to configure a new backup repo and change configuration backup to that new target. The new repo for your Conf Backup can be the same storage. But It need to be another path.

After that, you will be able to convert your repo in a sobr and add the capacity tier.

the ref file type notification is only informative, that your repo would be better formated as a refs partition. Veeam will not format your backup repo for you.

Thanks for your response.

So I can go ahead creating the new SOBR? If yes, do I need to point the backup jobs to the SOBR?

Klick on show detail.

you have unsupported Job Types for a SOBR.

most likely the „Configuration Backup Job“

If you create a SOBR with your existing backup repo, every Job will be updated to use the new SOBR.

you don‘t have to create new Jobs :)

Hi @walenteano ,
you said in your mail that you get this error message: 'Unable to add extent repository because it serves as the target for one or more job types which are not supported by a SOBR'

So, as @Mildur already mentioned, there is probably the configuration backup job pointed to this repo.

Configure this job to point to another repository and all should be ok.

Thanks for your response.

However, from my understanding the repository added to while creating the SOBR would be the source of the data to be archived.

So does it mean its the new repository created that would be added while creating the SOBR?

If yes, will the error still not persist since it would be serving as a target for jobs?

If no, using the old repository will only archive the old data, what about the new/incremental jobs?

Kindly give your professional advice.

Thanks.

Backup To Azure works this way:

Backup Job (or Backup copy Job) write the backup file to a SOBR. The SOBR will have a performance tier and a capacity Tier.
Performance Tier —> your existing Backup Repo OnPremise
Capacity Tier —> your Azure Blob Storage

1. Backup writes the data to Performance Tier
2. The SOBR will offload the backup data to Azure Blob, your capacity Tier. It depends on your choosen Policy, how this will be happening. MOVE, COPY or both together.

When you create the SOBR with your existing Backup Repo, the Repo will be added as a extend to the new SOBR. The existing Backup Jobs will be updated and doing there normal incremental and Full Backup Schedule like always. The Backup Chains will NOT be changed by creating a SOBR.

Have a look at the guides, how it works and how to configure it:

https://helpcenter.veeam.com/docs/backup/vsphere/object_storage_repository.html?ver=110

https://helpcenter.veeam.com/docs/backup/vsphere/adding_azure_object_storage.html?ver=110

https://helpcenter.veeam.com/docs/backup/vsphere/sobr_add.html?ver=110

Thanks so much, really appreciate your responses. 

Also if it is your configuration backup job only that isn’t compatible you could create a separate folder on the same storage device as you want to use for your SOBR and create an additional Veeam backup repository based on this folder and move your config backup job to use that.

If this is a brand new deployment you could use this new folder for your SOBR and just create your jobs to that in the first place but I’m assuming as you want to archive off to Azure you have existing data in your repository

Hi @JMeixner,  @Mildur and @MicoolPaul thanks for your respective contributions, I have been able to create a new repository and SOBR.

However, I was unable to make the new repository the target storage, it was not in the drop down of options but could still see the previous repository.

I tried deleting the old repository from the configuration backup setting but got the error message attached.

Hello,
I am not sure wether I get you correct or not.

You have to to the topic “Configuration Backup” in the main menu

In there you have to select another repository than the repos you want to use for your SOBR.
When you change the repo for the configuration backup copy the datafiles from the old to the new repo, otherwise you will loose your exisiting configuration backups.

But I think your error message is gven because you try to delete a repo to which the configuration backup is pointing….

If you don’t want to show your environment open in community feel free to send a private message via the community site to me with some screenshots...

@JMeixner I could not add an attachment to the private message.

This is the scenario:

I want to archive/replicate my on-premise datato Azure.

I have created an Azure repository and it was when I tried creating an SOBR with the repository on the veeam server that I encountered the issue you that led to this thread.

So, after creating another repository, I was able to complete the creation of the SOBR.

So I expected my backup jobs from other servers to point to the new repository which inturn archive/replicate my on-premise data to Azure but noticed the jobs keeps failing.

So, when I click on 'Configuration backup' from the screenshot u shared, the old repository was still showing in the drop down as the target storage and not the new one I created.

So I tried deleting the old repository since all the jobs has been moved to the new one, then try to point to the new one and the target storage but was unable to delete the old repository.

Is there something i haven't done or I'm the one not getting it right?

Thanks. 

Configuration Backup cannot be targeted to a SOBR.

why do you want to delete that simple disk repo (your old repo)?

You need it for the configuration backup.

Exact, the configuration backup cannot be pointed to a SOBR.

As @Mildur says, keep your old repo additionally to your new SOBR and all should be fine.

In essence, I do not need to delete the old backup?

Does it mean the necessary configurations had been completed?

If yes, kindly share with me how to confirm if the archving/replication to azure is working?

I will share some screenshots shortly. 

Here

Hi,

From what you’ve described you’re up and running. To see if any data has been copied/moved to the capacity tier you can navigate to Home > Backups and find your capacity extent, this will show you all backups in that repository.

@MicoolPaul Thank you for this.

The first attachment is a screenshot of what I have navigating to Home > Backups.

The second one are the various backup jobs I noticed they all failed.

I the third shot which I had shared earlier, if you notice you will see that one of the repositories (old repo) was in D: drive which ought to be in E: drive same as the new one I created. I think that was why the agents failed (still open to your opinion though).

I want to know if I could just create another repository in E:drive to replace the one in D:drive because the D:drive does not exist.

Thanks for sharing. Yep that’s fine you regarding creating a new repository.

I just want to take the time here to talk some bits out, as it’s been a bit scattergun question and answer in this thread and we should make sure we’re all aligned on what we’re talking about. Where appropriate I’ll include helpful links to Veeam’s documentation for extra reading if you find you need it. (Ignore that they’ll be for vSphere, it’s my go to documentation centre, as we’re talking about Veeam’s components here, it’s irrelevant).

Firstly, the objective you are trying to meet. You wanted to use Azure as a capacity tier, which requires SOBR, this is because you don’t perform a backup directly to Azure, you perform it to a more local “performance” tier first, then let the SOBR perform either copies immediately after your backup job has finished, or moves for old data after it reaches x days old for example. (Scale-Out Backup Repository - Veeam Backup Guide for vSphere, Performance Tier - Veeam Backup Guide for vSphere, Capacity Tier - Veeam Backup Guide for vSphere)

SOBR has some limitations, the key one is configuration backups aren’t supported to it, I see this as a good thing and intentional, your configuration backup is always in an expected place for restoration, you can perform file copy jobs if you want to put it in additional places, but as it’s the core of your Veeam configuration, it gets extra care. (Limitations for Scale-Out Backup Repositories - Veeam Backup Guide for vSphere)

The SOBR limitation gives you two choices.

1. (Recommended) You create a new repository that solely has your configuration backups, therefore allowing you to add your current repository to the SOBR.
2. You create a new repository that you add immediately to the SOBR, you either manually copy/move your backups into it or you just build a new backup chain for every job using this repository. You then remap all your backup jobs to using the SOBR.

Option 2 is possible, but it is a lot more work and less efficient than option 1.

Now, when we talk about creating new repositories, I just want to clarify something:

A repository doesn’t mean, a particular server. A repository also doesn’t even mean a particular disk/array. A repository is just a base folder on some storage that Veeam can target. For example:

E:\Backups can be a repository on SERVER1.

E:\Backups2 can then be a second repository on SERVER1.

Just don’t do anything like nested repositories or trying to share the same folder such as using E:\Backups twice or E:\Backups for one and E:\Backups\Backups for a second.

(Managing Backup Repositories - Veeam Backup Guide for vSphere)

If I had a single large storage array as my primary storage and I wanted to use SOBR + Configuration backup, I’d just create a second folder as a repository as above. If you wanted to use both repositories for more than just one storing the unsupported SOBR jobs, then you’d look into performance sizing etc, but that’s beyond the scope of this post.

Relating this back to your latest questions:

Based on the size of D & E it looks like they were the same volume but the drive letter was changed or something anyway. I don't know which of your jobs are targeting D and which are targeting E, but as you don’t have a D drive anymore, I would make sure any backups on disk E are in a repository folder and mapped to existing backup jobs where necessary. Then I would create another folder on E:\ (or preferrably somewhere far away from your main Veeam install) called ConfigurationBackup, make that a repository and aim the configuration backup there. Once that’s done, add your main E repository to a SOBR, you can then use Azure for your capacity tier, all should be sorted 

@MicoolPaul Thanks so much, really appreciate your analysis.

You’re very welcome. Let us know how you get on!