Moving Existing Jobs to New Scale-out Repository

[DGrinev]

Hi Paul and welcome to the community!

You can add the repository to the new scale-out repository and change target for the job to that SOBR. The job should continue with an incremental run.
Also, review this thread for additional information. Thanks!

[Highside1100]

Hey,

Thats great thank you very much

Regards,

Paul

[xefil]

Hello,

I'm following this guide as well as KB2236 to move data from an old repo to a new SOBR.
What I'm not understanding well is:

"If redistribution of files is not desired or necessary, you can simply copy the folder containing VBM and backup files to an existing extent. Rename both path and VBM to ensure import, and re-scan."

I move a lot of data to the temp directory in the same partition of a repo that already is into scale out:

d:\Backups (production repo and part of SOBR)
d:\Backups-temp (temporaru repo for migration)

Now, when I put the repo into maintenance and then select to evacuate it, it copies AGAIN a LOT of data.
Isn't there a way to prevent this step and manually add it to SOBR?

Thanks,

Simon

[veremin]

The note suggests that if you don't want backup files to be distributed across multiple extents, you can simply copy backup folder to one particular extent manually and then make SOBR aware of those files (rename, rescan, etc.). In this case no temporary extent is needed, so, some steps taken by you look excessive. Thanks.

[xefil]

Ok, why (how) rename?
Let me explain what I've done:

• temp repo: created a temporary repo in the same partition of the produtction repo, part of SOBR
• old repo: moved backup files to temporary repo (first big copy)
• temp repo: rescan. A new backup was found.
• job: edited the job, pointing the backups to the temporary repo and mapped the backups
• SOBR: added (extend) the temp repo.
• temp rempo: placed in maintenance and then evacuate it (second big copy from temp repo to production repo, part of SOBR).

With above steps, now the backup was succcessfully moved to SOBR.

Now, If for the last step would be possible to move manually the data to the production repo, part of SOBR, that would avoid a second copy process. It's a lot of data. A move would be sufficient.
How to do that?

Thanks!

Simon

[veremin]

A move would be sufficient.

Backup evacuation = move. Backup files will be deleted from obsolete extent, once they land on new extent.

[xefil]

Hello,

Not exactly (I suppose).
Evacuation moves the data with a copy and delete (I've checked it with resource monitor) and it has take hours.
Having the data on the same partition of the temporary repo and the production repo, the file explorer move is much faster (instant).
Isn't there a way to do it manually?

Simon

[toreml]

Hi.
I have a repository which is running low on free space.
I've now created a scale-out repository with new disk.

Can I add my existing repository into the scale-out - and the jobs will then be updated with new target?
The old repository is not set Pr-VM - so the scale-out is also not pr-vm since there - for now - not enough space for a new active full backup.

Will there be any issue with restore - since the disk is now a part of a scale-out, or is the backups related to the extent and not the scale-out repository?

Regards
Tore ML

[DGrinev]

Hi Tore,

Yes, you can add existing repository to the SOBR and change the target of the job.
There are no issues expected with the restore.
Please review this thread for additional information. Thanks!

[foggy]

Isn't there a way to do it manually?

I'm not sure why you need a temporary repository at all. Why not just add existing repository as extent to SOBR and evacuate it?