walenteano wrote:
@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.
- (Recommended) You create a new repository that solely has your configuration backups, therefore allowing you to add your current repository to the SOBR.
- 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 
