Move some OneDrive users to another repository.

[moh@dhigroup.com]

I was told that it was easy to move users, Individually, within a repository to another repository using the VBO-Migrator powershell script.
I have tried to run the script and I can see that I have to move all users within that repository at the same time. That will not solve my future problem when the repository reach the storage limit. Both repositories are 90 TB each. What should I do?

[Mike Resseler]

Hi Morten,

You can move a single user, the reference for the powershell line can be found here: https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=40

[nielsengelen]

You can use my GUI Data Mover (community project) if it helps. Available via my GitHub and explained in this blog post. It uses the Move-VBODataEntity method.

[moh@dhigroup.com]

Thanks Niels.
After the users data is moved to another repository, when the next backup is running, will it then save the new data in the old repository or the new one?
And can the user still be in the backup job with the old repository settings?

[nielsengelen]

You need to adjust the user to a job which points to the new repository, else it will create a new backup in the old repository.

[moh@dhigroup.com]

OK thanks.
Is it okay to use Storage Pools in windows in relation to VBO now Scaleout it not possible, or is it better to create a new repository for each disk shelf?

[Mike Resseler]

Are you running VBO on a virtual machine? Then it is better to create a VHD per repository. We have customers saying that storage pools are not delivering good performance on jet DBs

[moh@dhigroup.com]

No VBO is on a physical server with some disk shelfs attached. I am afraid of there will be a lot of administration, moving users between repositories, if the storage limit is reached. Is there a plan for scaleout storage like in VBR? Or is there a better way now Storage Pools is not a good idea.

[Mike Resseler]

Hey Morten,

You are using a jet DB as a repository, so no flat files like in VBR. This means we cannot scale out the database. jet DB is also what is used for Exchange. To be honest with you, if you want to look or prepare for the future which such sizes, you should investigate (even on-prem) object storage. That will be the best solution from administrative point of view.

When it comes to planning today... I would consider splitting up your environment into different jobs, each with different repositories. It has many advantages in larger environments when it comes to resources usage and so on. As example, you can split per workload (O4B, EXO, SPO), you can split per country, business unit and so on...

Plan those repositories on different volumes. The good news is that each repository DB (one repository can have many though) will stop filling at 57 TB (It might be a bit more, need to check to be sure) and then creates a new jet DB. This means that if you have a solution where you can grow your volumes, you should be good to go.

Makes sense?

[moh@dhigroup.com]

Hey Mike.
I have allready split up my enviroment into different jobs. But I guess I need to split up the O4B job in more small jobs.
I know about object storage but I think, at the moment, it is to expensive and the cost can be difficult to predict.
When I'm moving users from one repository to another should I then use eseutil if I want to defrag/shrink the file physically? And do I have to clean up something before I run an offline defrag, like you have to do in relation to Exchange?
I still think it could be nice if there could be a scale out option in VBO like in VBR. I know you can't scale out the database but you could provide a repository pool so you don't need to move data manually when you reach the storage limit. Before we bought veeam licenses we wasn't told that you couldn't scale out in VBO, so it's a little bit frustrating.

[Mike Resseler]

You don't need to do a clean up. What will happen is that the size of the repository will remain the same, but will not grow until all the "freed" space is taken up again.

[c2nathan]

Morten: Are you saying object storage is expensive and difficult to predict because you're thinking of this in the context of a vendor-provided object store? I just had someone point me towards MinIO (https://min.io ) which is an OpenSource object storage engine that could give you the ability to repurpose some of the storage that you're already using to hold VBO data in Jet database format, but as Object Storage. (I'm still investigating it for my own needs, so this is more of a 'mention' than a recommendation - please do your own testing / due-dilligence if you decide to go down this track.)

Mike: Can you elaborate a little on benefits of Object Storage over Jet / ESE database for VBO Repository backing? It's going to be a little while before I have to worry about running into 50TB repo's but if there are other benefits I'd like to understand before I embark on breaking up my current repositories to align with recent changes in organisation structure. Also : do Veeam Support recommend against doing a ESE Defrag for some reason, if one wanted to 'reclaim' storage in a Jet Database that was used in a VBO repository but had a bunch of data moved out of one repo as in the 'split up your environment/jobs/repositories situation' recommended above? It could easily take a couple of years for one of my repo's to 'refill' and I don't like the idea of Multi-TB's of expensive enterprise storage being consumed by database whitespace for that length of time - it makes for poor ROI.

[Mike Resseler]

@c2nathan,

Object storage has encryption possibilities which the jet DB does not have. It also will save you more space compared to a jet DB because of the way we can built the objects. And lastly, when a proxy dies, you can create a new one, attach the folder of the object storage to that new proxy, rebuild the cache and you are back at work. Doing this with a jet DB is a more complicated work.

RE: Defrag. Note that we use jet DB but Exchange has a modified version of it, that's why I recommend against the ESE defrag.

[moh@dhigroup.com]

Thanks for your answer Mike.
I love VBR but I'm really struggling with VBO. Every time a job is interrupted and it did not complete successfully it takes forever when I start it again and the CPU peaks at 100 %. I have tried to create a support case but I have closed it because it seems like no one knows what to do. Now I have to move some users from the OneDrive job and then add them to another OneDrive job, I will create. Is there a GUI or PS command where I can see all users who are in a repository and then completely delete them from that database? I have removed them from the job but I want to be sure that there is now data related to them in another database.