Seeded/re-mapped backup copy doing full backup

[pkelly_sts]

I've been discussing progress on re-seeding a job to our remote site in another topic but I've hit an issue I'd like some comments on so thought I'd start a new topic rather than leave it buried.

Everything below is within a single instance of VBR which owns all repositories & tape libraries on local & remote sites:

Local backup to local SoBR containing 2 simple repositories (& configured for per-vm backups)
Backup copy to another (temporary) local SoBR containing single simple repository also configured with per-vm backups. (Copy is up to 6 restore points at this stage).
Copied full copy chain to tape (6 rps, per-vm backups) as backup-to-tape job
Restored full chain to SoBR (containing two simple repositories) at destination/remote site no problem.
Restore process sent .vbks to one simple repository and .vibs to the other (within the SoBR - expected)
Restore points appeared as imported job as expected
Edited the original backup copy job & re-mapped it to the new repository also pointing to src/target WAN-X's (global cache already populated)
Started the job & it initially started looking perfect, until I realised it was creating a new .vbk for the first VM it was processing so I cancelled the job at that point.

What would cause the creation of a new .vbk? It's creating it in the same location as the existing .vbks.

[Dima P.]

Hi Paul,

We are still investigating your scenario. Was the original backups modified by synthetics or not?

[pkelly_sts]

Thanks Dima - The original local source backup? Yes, it will have been as it has been running for a number of months, but the first local backup copy (which was then transferred to other site) has never processed a synthetic.

[pkelly_sts]

Actually there's one more thing worth mentioning in case it's relevant.

The repository I restored to was a SoBR as mentioned, but at that time it was NOT configured for "per-vm backups" as I have the original legacy backup copy (which this process is intending to replace) already going to this repository.
I did switch the SoBR to per-vm BEFORE re-enabling the job, but after it started the full & I stopped it, I switched it back to NOT being per-vm, otherwise that would have also kicked off another fully copy from base to remote sites.

I'm more than happy to create another SoBR (on the same disks, just moving the files over) but didn't want to start messing with things before hearing from yourselves...

Also if you think it's worthwhile I'll happily open a case for this.

[pkelly_sts]

Any updates on this one Dima? I've kept my local backup copy paused since as I didn't want to change the data in case what I've already copied to remote site was salvageable but it's getting well out of date now...

[Dima P.]

Hi Paul,

I hate to say it but we need your logs. Can you open a support case and let me know the case ID, so I could forward it directly to QA folks?

[pkelly_sts]

No problem Dmitry, now opened as #01850643

[Dima P.]

Thanks. Shared with the team.

[pkelly_sts]

Whilst looking for something else I just re-stumbled upon the Veeam docs for seeding a backup copy job and noticed a subtle difference with how I've always done them & just wanted to check if it made much difference generally.

At this link it suggests to create a temp job to create local copy, then move the copy and finally create a new job pointing to the copy.

I've always just re-pointed the original copy job to the new location.

Is there much real difference between the two approaches?

[Dima P.]

Paul,

It's a workaround to overcome the limitations of the backup copy job mapping: backup copy job can be mapped only to a backup created with the incremental backup method. You cannot map a backup copy job to a backup created with the reverse incremental backup method, or to a backup whose chain contains both incremental and reverse incremental restore points.

[pkelly_sts]

Ah, I see, so if I never use reverse incremental then I don't need to worry about double-job-creation?

[Dima P.]

Hi Paul,

Ah, I see, so if I never use reverse incremental then I don't need to worry about double-job-creation?

Yup, correct.

Sorry for keeping silence regarding the original issue. It appears that metadata file is generated only while restoring the backup into infrastructure. However, when you perform backup mapping the .vbm file is also required for backup copy job to recognize the backup chain. Since backup chain cannot be recognized – backup copy starts a new full.

We are going to fix this behavior in the upcoming version but meanwhile its recommended to use a file to tape job for such data migration as it keeps the .vbm unmodified.