This article provides information regarding migrating backup data between JET-based backup repositories and from a JET-based backup repository to a non-immutable object storage repository when using Veeam Backup for Microsoft 365.
Note:Data can only be migrated using PowerShell cmdlets.
This article documents how to migrate backup data between repositories. For details on how to move the Veeam Backup for Microsoft 365 installation to a new server, please review: https://www.veeam.com/kb2649
The Move-VBOEntityData PowerShell cmdlet is used to move backup data from one repository to another repository.
Limitations and Considerations of the Move-VBOEntityData cmdlet:
As data is moved, Veeam Backup for Microsoft 365 removes items from the source repository and replaces them with whitespace. For this reason:
The object storage repository where you want to move backup data must not contain any data associated with the items you want to move.
If the move process was interrupted, do not start the related backup jobs until you have resumed and completed the data move process.
Move-VBOEntityData supports the following data migration scenarios:
Migration from one JET-based backup repository to another JET-based backup repository.
Migration from a JET-based backup repository to a non-immutable object storage repository.
The following migration scenarios are not supported:
Migration from a JET-based backup repository to an immutable object storage repository.
Migration from an object storage repository to another object storage repository.
Migration from an object storage repository to a JET-based backup repository.
Migrated restore points will no longer be attached to the original job. However, the restore points are still available for restore and can be accessed by right-clicking on the corresponding organization name.
The Move-VBOEntityData cmdlet will not reconfigure backup jobs to change the repository they use. The jobs must be reconfigured manually or by using additional PowerShell cmdlets (as is done in the script example found in this article).
It is recommended to run migration operations outside of backup windows to avoid overhead on a proxy and affecting backup jobs performance.
If Teams data migration results in a mix of restore points created by EWS and protected APIs stored in the same repository, then such repository can only be used to create new backups using protected APIs
Monitoring the Move-VBOEntityData migration progress
Status of migration tasks is displayed in the Veeam Backup for Microsoft 365 Console in the History tab under the Job > Data Management node.
Migration Script Example
The script below is designed to automate backup data migration between repositories.
Expand for information about the Migration Script example
The script performs the following operations:
Select Organization. Defines the organization associated with the data to be migrated.
Select Backup Proxy. Defines the backup proxy server that hosts existing backup data.
Select Target Repository. Defines the target object storage repository.
Limit Migrations Sessions. This step configures the maximum number of simultaneous migration sessions to half of all threads configured for the selected backup proxy server. For example, if there are 64 threads configured on the backup proxy server, it will limit the number of migration sessions to 32 concurrent migration sessions.
Disable All Jobs for Selected Organization. Disables all backup jobs created for the specified organization.
Create a List of Source Repositories. Creates a list of backup repositories used by the backup jobs from Step 5 that will be used as source repositories. (If a repository is not in use by at least one backup job, the data residing there will not be migrated.)
Get and Migrate All Users. Creates a list of all Users, Sites, Teams, and Groups located in the repositories from Step 6 and then migrates their data.
Reconfigure Jobs to Use New Repository. Reconfigures all the jobs from Step 5 to use the object storage repository that is defined as a target repository and enables all jobs disabled at Step 5.
Before using the script below, it is essential that you:
Read the Solutionsectionof this article to understand the limitations of the script's cmdlets.