Veeam Backup for Microsoft Office 365 4.0 introduced a new type of a repository - the Object Storage repository. You may want to migrate your existing backups to this new repository and store your backups in the cloud.
Veeam Backup for Microsoft Office 365 4.0 doesn’t have an option to migrate existing backup data from a local backup repository to an object storage repository via the product UI. The data can only be moved using Veeam Backup for Microsoft Office 365 PowerShell cmdlets.
The purpose of this article is to provide additional information on the workflow and to demonstrate how it can be automated.
Existing backup data can be transferred from the local backup repository to the object storage repository using the Move-VBOEntityData PowerShell cmdlet.
Mind the following:
- In Veeam Backup for Microsoft Office 365 4.0, the following data migration scenarios between repositories are supported:
- Migration from the local backup repository to the object storage repository.
- Migration between local backup repositories.
- If you plan to change retention policy from the longer retention period to the shorter one, it's recommended to lower the local backup repository retention period to the value of your planned object storage repository and only then to perform a migration. This way you can make sure that the costs of data transfer would be minimized.
- Existing restore points will be available after the migration and accessible with a right-click on the corresponding Organization name instead of a job name since they will no longer be attached to the original job.
- The migration procedure will not automatically reconfigure the corresponding backup jobs. To proceed with backing up to an object storage repository, you must reconfigure the jobs manually and point them to the new target.
- It’s recommended to run migration operations outside of backup windows to avoid overhead on a proxy and affecting backup jobs performance.
1. Understanding Variables and Parameters
This example shows how to perform basic operations with Veeam PowerShell cmdlets to move backup data from the local backup repository to the object storage repository.
$source = Get-VBORepository -Name "Source Repository Name" $target = Get-VBORepository -Name "Object Storage Repository Name" $data = Get-VBOEntityData -Type User -Repository $source -Name "John Doe" Move-VBOEntityData -From $source -To $target -User $dataThis description covers details on the cmdlets and parameters that are used to get the necessary objects and migrate backup data that you want to move (a single user’s mailbox, archive mailbox, OneDrive and SharePoint site) between the repositories with the Move-VBOEntityData cmdlet.
- Run the Get-VBORepository cmdlet to get the source local repository. Provide the Name parameter value to get the repository by its name. Save the result to the $source variable.
- Run the Get-VBORepository cmdlet to get the target object storage repository. Provide the Name parameter value to get the repository by its name. Save the result to the $target variable.
- Run the Get-VBOEntityData cmdlet to get the backup data that you want to move. Provide the value for the Type parameter to specify the type of data that you want to move.(You can specify either of the following types of data: user, group, site. For more information on the types of backup data, that you can get, see the Get-VBOEntityData article of PowerShell Reference for Veeam Backup for Microsoft Office 365). Note: The Organization type of backup data is not supported for this scenario. In addition, the Move-VBOEntityData cmdlet works only with a single user object. Therefore, for the purposes of data migration, the Get-VBOEntityData cmdlet should always be used with the "-Name" parameter. Without this parameter, the Get-VBOEntityData will assign an array of users to the $data variable, which can not be used by Move-VBOEntityData cmdlet.
- Run the Move-VBOEntityData cmdlet to migrate data from the local backup repository to the target object storage repository.
Move-VBOEntityData -From $source -To $target -User $data -OneDrive -ArchiveMailbox
By default, the session iniciated by running the Move-VBOEntityData cmdlet is a single-thread operation and you will not be able to start another migration job before the current one is finished. To migrate larger amounts of data, it's recommended to run migration jobs in parallel by using the -RunAsync parameter. For example:
Move-VBOEntityData -From $source -To $target -User $data -RunAsync
The status of data management jobs is presented in Veeam Backup for Microsoft Office 365 console under the corresponding node on the job sessions history:
The script below is designed to demonstrate how to automate backup data migration to an object storage repository.
Please note that the script is provided to demonstrate automation possibilities and is not supported by Veeam Technical Support. Use it at your own risk.
The script consists of several steps and performs the following operations:
Step 1. Organization Selection - this step defines the organization that data you want to migrate.
Step 2. Backup Proxy Selection - this step defines the backup proxy server that hosts existing backup data.
Step 3. Target Repository Selection - this step defines a target object storage repository.
Step 4. Limiting Migrations Sessions - this step configures the maximum numbers of simultaneous migration sessions to a half of all threads configured for the selected backup proxy server (for example, if there are 64 threads configured on a backup proxy server, it would limit migration sessions to 32 migration sessions).
Step 5. Disabling all Jobs for Selected Organization - this step disables all backup jobs created for the specified organization.
Step 6. Creating a list of source repositories - Creates a list of backup repositories used by the backup jobs from the step 5 that will be used as a source repositories (if a repository is not in use by at least one backup job, the data residing there would not be migrated).
Step 7. Getting and Migrating all Users - this step creates a list of all Users, Sites, and Groups located in the repositories from step 6 and then migrates their data.
Step 8. Reconfiguring Job to Use New Repository - this step 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 on step 5.
For the ease of use, each step is provided with a corresponding comment in the script.
Please be aware that we’re making changes which will restrict access to product updates for users without an active contract.