How to move repository without the need of pausing backup?

[srdegeus]

Similar question has been asked in the past and in most cases the kb1889 https://www.veeam.com/kb1889 would apply.
However that article assumes that the manual copy would be finished between the two backup runs, or that the backup is paused.

The challenge that I have is that we use a forward incremental (always), and the copy of the largest (.vbk) in the repository takes over 24 hours to copy.
So the issue/scenario I run into is:

• Backup job starts
• Creates new .vib, injects oldest .vib into .vbk
• Start initial (robo)copy to new repository location (takes more than 24h)
• Copy not finished when new backup job run begins
• Creates new .vib, injects oldest .vib into .vbk which is now a different file so needs to be copied (again)

So this never completes (in time), unless I put the backup on hold.

Initially using scale-out repositories (https://forums.veeam.com/vmware-vsphere ... 45399.html) seemed like an alternative, until I read the remark:
“keep in mind that backup jobs for chains that are currently located on the extent that is in maintenance mode (being evacuated) will fail (unless you temporarily disable the jobs)”

Now imagine you are a Veeam Cloud Connect provider and need to move the repository, are you going to tell your customer that they cannot backup (copy) for a day (or more) because you need to move the data?

What would be the procedure to move a ‘live’ repository from within Veeam without a long downtime?

[PTide]

Hi,

If you switch from forever-forward incremental mode to simple forward incremental, then you can easily copy the backup as there will be no need for merge operation anymore. For example, you can enable synthetic full backup in Advanced settings.

Thanks

[srdegeus]

This is not really feasible as this would (almost) double the space requirements for the repository, making the copy twice as long. (Assuming you are allowed to change the original backup job.)

I agree that changing the job would (possibly) postpone the merge and allows more time for the copy (E.g. temporary increasing the restore points.) But that would imply that you can actually change the backup job. If you are on the receiving end of a copy-job (like a Cloud Connect provider) you don't have that option.

[PTide]

This is not really feasible as this would (almost) double the space requirements for the repository, making the copy twice as long. (Assuming you are allowed to change the original backup job.)

Then you should temporarily increase your retention value so that the chain will get merged later than in 24 hours. After robocopy is done, revert the retention back to the initial value. In this workaround there is no need to create an additional full.

Thanks

[srdegeus]

That's what I already said.

So as a Cloud Connect provider (who cannot edit the job) who has to migrate the storage, the only 'solution' is to disable the tenant and have the jobs fail during the copy?

[PTide]

Considering the circumstances, yes, you have only thses options:

a) Increase retention
b) Configure intermediate full
c) Stop the job temporarily

The only workaround that I can think of would be to try copying the vbk file from a shadow copy so that it does not interfere with the ongoing job.

Thanks