we started with Veeam Backup for Office 365 in early 2021. In the beginning we decided to create one backup job per workload distributed over two proxies with one local disk repository each. While the system is growing we will soon facing the problem that I cannot expand the repository disk anymore because the underlying VMware datastore is limited. There's enough space on additional datastores on the same storage machine, but the limit is a single datastore. An additional datastore means an additional vmdk means an additional repository. That given I'm wondering how to best redesign my jobs because now we back up the entire org per workload and that is quite simple. The best way would be using something like Scale-Out-Repos as in VBR, but afaik in VBO there's no such feature. With more than one job per workload I have to distribute the objects of one workload evenly between these multiple jobs!? I'm aware that much is possible through powershell, but at the moment it seems too complicated to me. Is it actually correct, that I have to split the backed up objects over different jobs for one workload in order to use multiple repos repectively is it really necessary to create an additional repo? Does anyone have an idea how to usefully spread the objects (automatically) over more than one job? I guess it's a quite common design question. How are you getting around this issue? Or is there another way not to split into multiple jobs per workload? Note: Object storage is no option at the moment.
Thanks for any input,
Daniel
No case id because this is actually no technical issue .
We ran into a similar issue with one customer's repository that grew to over 13TB and was all being backed up by a single job covering all workloads.
I looked at splitting it out alphabetically but this would have meant manually adding/removing users from the jobs which was out of the question for us.
In the end I changed them to 4 separate jobs (Mailbox, OneDrive, Sharepoint, Teams) which were all pointing at separate repositories.
The fun part was moving all of the current backup data to the new repositories - this has to be done through powershell and takes a long time! Moving ~5TB of mailbox data took 4 days!!
We already use one job per workload type spread across two proxy servers with local disks. The proxy servers are vms but we're going to migrate to Exchange Online and one on premise Exchange vm is about 10TG big. The Exchange job points to one repository with resides on a lokal drive on the proxy. The underlying storage is was 48TB but has been split into 6TB chunks by our storage administrator. Now the vmdk containing the Exchange repository cannot extended to more that about 6TB. I'm afraid that will not be enough space. I guess we will have the same issue when migrating our company share to SharePoint Online. The highest benefit is currently just to select the organization with Exchange as the only workload and no need to configure groups or individual users in this job. We considered object storage when designing the environment but we wanted to have the backup data on premise and setting up a s3 compatible storage with redundancy was out of question for us. We decided to use local disk because we can backup it up with VBR and leverage all VBR backup features such as copy jobs and the storage for the vms was already available at no additional costs.
I have the following questions:
- Is it correct that I will have to set up additional repositories on additional disks that reside on the other datastores and therefore have to split the Exchange job for example?
- Am I right, that I cannot get around to set up multiple jobs on different repositories on additional local disks/vmdks and have to switch to dynamic user assignment per job through powershell in case I don't want to mange backed up object manually?
- Scale-Out-Repos in VBO would be the solution for my problem, but as far as I know it currently isn't planned to implement such feature, is it?
- Correct. If your repository reaches the 6TB limit, you'll have to split the job and point it to a new repository located on a drive with a sufficient amount of space. Note also that if you run out of space on the current drive, it potentially can cause backup database corruption.
- Correct
- Correct, there're no short-term plans for implementing scale-out repositories in VBO.
.