As you can tell I’m on a bit of a “migrate all the things” story arc here of late and today will be the latest installment. In my last post I covered using the VeeaMover capability to move backups between repositories or jobs but that is not an effective data migration mechanism if you’ve used the Capacity Tier “COPY” capability of a Veeam Scale Out Backup Repository (SOBR). This is because capacity tier data is a very special unicorn in the VBR portability universe due to it’s ability to hold both backup copies as well as offloaded backups via MOVE all in the same general construct. As I pointed out in the past on my personal blog, even making this data appear for restores after a migration outside of the source VBR can be tricky.
As of VBR version 12.3.2 it is now possible to add object storage repositories of different types (AWS S3, Azure Blob, S3 Compatible) into the same tier of a configured SOBR. With this addition Veeam has updated its guidance to recommend the “maintenance mode, seal, then evacuate” method of migrating data from one cloud repository to another.
This post will outline the process of migrating compatible object storage data located in a SOBR Performance or Capacity Tier to 11:11 Object Storage for Amazon S3.
Considerations
-
If moving between cloud based object storage systems please refer to “Setting up Object Storage Gateways For Data Migration to AWS S3/11:11 Object Storage for Amazon S3” to allow for efficient transfer
-
Data migrations speed can vary based on several factors; object storage gateway sizing, overall VBR system load, SQL server sizing, bandwidth, etc. Please ensure monitoring of the related components is setup prior to transfer and a baseline is established to maximize data transfer.
-
SOBR evacuation cannot make use of any data that is migrated by 3rd party tools such as rclone or AWS DataSync. For the purposes of the above please assume that the destination repository has no data/objects that relate to the source extent. Attempts to use the capability with existing data present will at worst result in evacuation failure and at least storage inefficiency.
Process
-
Ensure your new bucket that you wish to transfer to is added as an object storage repository to the system. For assistance see https://success.1111systems.com/docs/cloud-object-storage/add-aws-s3-as-vbr-direct-repository.
-
Disable any jobs targeting your affected SOBR.
- Ensure that no SOBR offload jobs for that SOBR are currently running. These can be found under History > Storage Management
- From Backup Infrastructure edit the properties of your SOBR, navigating to the tab for the tier you want to migrate. Right click on your source object storage repository and choose “Maintenance Mode”, then Seal Extents. You will be warned about sealing the extent, choose Yes.
- Click “Choose” and then add your new extent or extents to the tier. In this case we will use the Capacity Tier. Then click Apply and Finish to complete modification of the SOBR.
- Now back in the SOBR screen of Backup Infrastructure you should see your performance tier, and your now 2 capacity tier repositories with the source one with a disabled icon.
- Right click your sealed repository and Choose “Evacuate backups.” When prompted for confirmation choose “Yes.”
- The migration will now begin. A statistics screen will launch to allow you to monitor the evacuation.
- If that is closed and you wish to monitor you can relaunch from the Running portion of the Home tab
- Once completed you should see a success message.
-
To complete the process edit your SOBR once again and remove the source repository from the Tier configuration and re-enable your jobs.
Conclusion
Portability of data in the cloud is a vital consideration for many today. This can be due to cost, capability, data locality, or many other reasons but migration topics are complicated base on what wrote the data, how the data was written, how the data is protected among others. Further you should be mindful of vendor requirements for data migration and use their supported tools to ensure both success as well as supportability.
There are a large number of SOBRs configured out there in the Veeam Extended Universe and as customers want to migrate that data cloud to cloud, 12.3.2 brings a simple and potentially performant way to move that data cloud to cloud.
