Migrating and renaming backup copy job causes Veeam to restart backup copy from scratch

[aj_potc]

Hi there,

I'm using VBR to manage an agent that backs up a Windows system. I have a backup copy job that copies this backup to an additional repository.

I recently chose to move the backup copy to a new repository, and in the process renamed the backup copy job so that it's consistent with the new destination. Here are the steps I used:

1. Manually copied the Veeam folder with backup files from the old repository to the new one.
2. Set up a new repository in Veeam, and pointed it to the location with the old backups. Veeam scanned the new repo and accepted this with no problem.
3. Modified the existing backup copy job to change its name and its target (to the new repository).

All of the setup went fine. The problem comes when the first backup copy job runs. Instead of updating the existing backup files in the repository, the job created a new destination folder matching the new job name. It's now proceeding to re-copy all data to the repository, ignoring the data that's already there.

I assumed that Veeam would instead notice that the backup copy already exists, and would either rename those backup files or automatically know that they are related to the existing backup job.

Is there a bug here, or is there some problem in the way I migrated the files and renamed the job?

My support case number is: 04288979

Thanks for any help.

[PetrM]

Hello,

I don't think there is a bug, most likely the job did not recognize the migrated backup by some reason and started to process data from scratch.

I'm pretty sure that our support team will be able to explain this behavior after debug logs analysis, let's wait for results of investigation.

Thanks!

[aj_potc]

I don't think there is a bug, most likely the job did not recognize the migrated backup by some reason and started to process data from scratch.

Perhaps, but I definitely remember that when I set up the new repository and tried to modify the backup copy job to point to it, Veeam would not allow this until the existing backup files were migrated over from the old repository. So this makes me think that Veeam knew what was going on, and thus my great surprise at seeing it ignore the existing backup copy and blindly create a new one.

[aj_potc]

Update for others who might have this problem:

Unfortunately my support case was closed without a response from Veeam, so it doesn't look like there will be any log analysis from them.

In the end, I had to manually delete the backup copy I had migrated to the new backup repository. It appears that Veeam is not able to reliably detect and rename existing backups when the backup job name is modified at the same time the new destination is set up. In any case, it doesn't seem that there is any harm in deleting the old backup directory -- but it completely defeats the purpose of migrating the backups in the first place.

[PetrM]

Hello,

The request was not processed due to high support team load. We provide email support on a best-effort basis depending on staff availability for the customers using free products.

However, let me reach out our support engineers to clarify what exactly provoked this behavior in your specific case. I'll update the topic as soon as I have more information.

Thanks!