Move-VBOEntityData question

[dan.kennedy]

We have a repository which is currently used for a single backup job that contains all data types for an organisation. It is currently is taking up 12TB of space and is growing rapidly. We now want to split this repository down into smaller repositories based on the data type - e.g one repository each for all Teams, Sharepoint, OneDrive, and Exchange data.

I understand we need to use the Move-VBOEntityData cmdlet to move this data but the reference article I found only shows examples of doing this on a per user basis.
My question is, can we simply run the command without the "User" parameter - e.g. to move all of this organisation's Teams data from current repository to new target repository:

$source = Get-VBORepository -Name “sourceRepo”
$target = Get-VBORepository -Name “targetRepo”
$data = Get-VBOEntityData -Type Team -Repository $source

Move-VBOEntityData -From $source -To $target -Confirm:$false

If that's not possible I'm assuming I would have to use a ForEach loop within Powershell to pick up the individual user's data and move them one by one?!
I'm reluctant to test this on such a large data set in case i break anything and prevent them from being able to restore historical data!

Any assistance would be appreciated!

Dan

[chris.arceneaux]

Hi Dan,

Have you reviewed KB3067? It provides a good explanation of what's required as well as a sample script you can download at the very bottom.

[dan.kennedy]

Hi Chris,

Yes I have seen the script from that KB article, and although it does give me some pointers to work with it doesn't actually achieve what i want - which is to split the data out into separate repositories.
The script seems to just pick up all the data from one repository and move it into another single repository?

It also doesn't seem to mention teams anywhere - would teams data be included in the "Groups" section of the script?

[nielsengelen]

Hi Dan, the script is indeed created for v4 and not updated yet for v5. I'll come up with an example on how to do it (I currently only have an example to remove the specific type of data).

[dan.kennedy]

To update this thread, so far i have tried the following....

I created a new test job using our own O365 tenant which backed up the entire organisation and allowed this to run once overnight, it completed with no errors.
I then split the example script from KB3067 into 4 separate scripts and moved each set of data (mailbox, sites, groups, onedrive) individually into separate repositories.

This seemed to work OK but for some reason the total amount of data doesn't match up - we are about 20GB short across the 4 new repositories compared with the original single repository size.

Is there any way to confirm 100% that all of the data has been moved over correctly?
I wouldn't expect to see such a large difference in the amount of data as the original job only ran once so white space should not be coming into play at all?

[Polina]

Hi Dan,

If you were using Jet-based repositories, some space inside databases might be empty but still consuming disk space. After data deletion (i.e. retention) repository databases don't shrink, but this free space inside databases is then reused for the new data.

You can check the actual space consumption in a repository with the Get-VBOUsageData cmdlet and compare it with your new repositories.

[dan.kennedy]

Hi Polina,

Now I really am confused!!

I've run the Get-VBOUsageData cmdlet against the 4 new repositories I created and they are all showing 0 bytes used?
The output below is for the new mailbox repository - if i look in Windows explorer it shows the folder has 79.2GB of data in there, but Get-VBOUsageData shows 0 bytes?!

$repository = Get-VBORepository -Name "*****"

Get-VBOUsageData -Repository $repository

RepositoryId : ******
Organization : ******.onmicrosoft.com
UsedSpace : 0 B
LocalCacheUsedSpace : 0 B
ObjectStorageUsedSpace : 0 B
IsAvailable : True
Details :

Am I running the command wrong?!

[Polina]

Hm. Now I'm confused as well
I'd expect to see zero bytes consumed on the old repository where the data has been moved from, but for the new repository, it doesn't look right.

[dan.kennedy]

I can see the data management jobs (which are still showing in the history tab of the GUI) and they confirm the data was actually moved across, so I really have no clue why the usage would be 0 bytes!
If i run Get-VBOEntityData cmdlet against one of the new repositories (the mailbox/archive repository in this case) it shows all of the expected users.

$repository = Get-VBORepository -Name "****-Mailbox"
Get-VBOEntityData -Type User -Repository $repository

DisplayName Email IsMailboxBack IsArchiveBack IsOneDriveBac IsPersonalSit AccountType Organization
edUp edUp kedUp eBackedUp
----------- ----- ------------- ------------- ------------- ------------- ----------- ------------
*** ***@data... True True False False User ***.onmicrosoft.com
*** ***@data... True True False False User ***.onmicrosoft.com
*** ***@da... True False False False User ***.onmicrosoft.com


Do the services perhaps need restarting or something like that? I haven't done that since i moved the data to the new repositories. I can't think of any other reason for it?!

[Polina]

Dan,

I asked for some assistance on this from the RnD team, and it turns out that getting zero's doesn't necessarily indicate an issue with moved data. Space usage statistics is collected once a day, and it's quite possible that it hasn't been updated yet after the move. Restarting the services should help.

[dan.kennedy]

Thanks Polina!

I've restarted services but still showing 0 bytes used on all the new repositories (and the original which should actually be empty anyway!)
I'll check it again tomorrow and update.

[dan.kennedy]

Unfortunately it is still showing 0 bytes used on all the new repositories.

I checked another customer repository with the same command (just to make sure i wasn't doing it wrong!) and that did show the amount correctly so I'm not sure what has happened with the moved data now?

[dan.kennedy]

I have raised a support ticket for this issue - #04794718

[Polina]

Hi Dan,

Thanks for opening the case. I'll follow up on the investigation.