How to move extents from a scale out to another?

[merku]

Hello everyone.
I've configured two Scale-Out with these Extents inside:

Scale-Out1 - Disk1 and Disk2
Scale-Out2 - Disk3, Disk4, Disk5 and Disk6

Can I move Disk1 and Disk2 inside Scale-Out2?
If yes, what is the best way to do it without losing data?
I've also many jobs that point to Scale-Out1

Thnks all for the help

[Shestakov]

Hello and welcome to the community!

Does Disk1 or Disk2 operate as an object storage of Scale-Out1?

[merku]

Hi,
object storage is configured inside Scale-Out2.
Inside Scale-Out1, Disk1 and Disk2 are simple iSCSI disks

[Shestakov]

In this case you can evacuate backups from one of the extents of Scale-Out repo 1, than remove an extent from the scale-out repository and then add these repositories to the second SOBR.
Thus you don't need to re-create jobs.
Thanks

[merku]

Thanks for reply, my doubt is space on disk and performance I/O during evacuate operation becuase these disk are quite slowly.
There aren't other technique to move disk1 and disk2 from Scaleout1 to Scalueout2 without evacuate backups?
My goal would be to move the disks to the same scaleout (in this case scaleout2) and to point all jobs to scaleout2

Thanks a lot

[Shestakov]

There is a workaround, but it requires to re-create the jobs.

You need to go through these steps:
1. Remove the jobs
2. Remove backups from configuration (it will remain on disk)
3. Remove the first SOBR
4. Add Disk1 and Disk2 to Scale-Out2
5. Rescan Scale-Out2 (the backups will appear in configuration)
6. Create new jobs
7. Map the jobs to the backups

Feel free to ask additional questions and/or ask support to assist you

[merku]

I've also ask to support with Case # 04402915 to have some kind of correct procedure to do that, all works:

If you try to move an extent to another SOBR while it still has data on it, you'll get an error and you will not be able to proceed. There is a test that we can perform to see if it's possible to move the extents with the backup files on them (see below).

I suggest the following: create a dummy extent which you add to SOBR CEM1 . It can be a different folder on one of the same drives you are using (e.g. instead of setting repository to D:\backups , set it to D:\test\backups ) . After you add it, run a dummy job to it. To ensure that the files are written to the dummy extent and not on other extents, please place the other extents in maintenance mode while the dummy job is running. It would also be best to run the dummy job while other jobs targeting CEM1 are not running or disable the other jobs until the dummy job finishes. This is needed to prevent any other jobs from writing on the dummy extent.

When the job finishes remove the backup set of the dummy job from configuration . Note that most likely you'll need to hold down the CTRL key while right clicking on the backup set to see the option. https://helpcenter.veeam.com/docs/backu ... ml?ver=100

After all these steps, the link of the job to the backup set will be broken but the backup set will still exist on the repository. At this time, try to remove the dummy extent from the SOBR. Also, now you can reenable the other extents on CEM1.

If you do not receive any errors, you'll be able to add the dummy extent to SOBR CEM2 now. After you add it, make sure to copy the backup set path and the vbm file to all other extents (backup files can remain on the dummy extent only). e.g. on dummy extent you have repo path set to D:\test\backups . In backups there should be a folder with the job name which contains its backup files and vbm. Create the same job folder in the repository folder of the other extents and copy there only the vbm file ).

Rescan SOBR CEM2 -> the backup set should appear in disk (imported) -> open the dummy job properties and when you reach the target tab, select CEM2 as the new target and click on the "map backup" button right underneath the repository dropdown -> choose the backup set from there. Start the dummy job again and see if it runs properly.

Conclusion: if it does, you can apply these steps for the other jobs running to CEM1 as well and effectively migrate the backups along with the extents. If the test fails, the only option is to move the files to CEM2 (which means somehow obtaining more space on CEM2) and only afterwards remove the extents.

NOTICE: if you perform the above steps for jobs that have files on the capacity tier of CEM1, the links to the capacity will be broken and most likely you will not be able to repair them. So even if the test with the dummy job is successful, before launching a production scale migration, first download the files from the capacity tier.