"No restore points found" in backup copy job?

[pkelly_sts]

I'm trying to create a single consolidated backup copy job based on 3 individual jobs so I can seed it to another site & ultimately replace the 3 jobs with the 1 consolidated job.

The three copy jobs currently copy just fine to a different site from three original local backups.

If I create a second, local, copy job with the source being the three original backup jobs, the data from the biggest of the 3 jobs copied fine but then the remainder seemed to be taking an age when I realised it was (slowly) using the existing offsite copy as the source so I cancelled it, then removed that repository from the list of possible sources, then restarted the job.

It then sat at the offending VMs saying "no restore points found" when I *know* there are numerous restore points available.

What am I missing? The original backups are local, I'm running this on the same B&R server, I don't understand why it doesn't "see" the local backup files?

(Thought I'd ask here in case I'm missing something dumb before raising a ticket)

[Shestakov]

Hello Paul,
So what is used as a source of backup copy job now, from jobs of from infrastructure?
How often do the source jobs run?
Thanks!

[pkelly_sts]

Local (physical) B&R server runs the primary backups jobs to local storage.
Same server runs the first backup copy jobs to remote storage (another full B&R server as it happens)
Same server again is running the second backup copy to local storage.

The only thing that's jumping out at me ATM which might be a cause, is that the destination repository of the second copy job happens to be the same repository for the "offending" VMs. Is it the case that you can't copy from repository-a to repository-a because normally it might be considered to be a wasted exercise whereas all I'm trying to do is create a single .vbk to be able to use as a seed.

If this is the case then I guess I'll just have to create another folder on the same physical disk and create a second "repository" on it for the short-term copy?

[Shestakov]

What product version are you at?
Two different VBR servers are unaware of each other, so you need to rescan repository to make VBR aware of backup files made by another server jobs.
Why do you need to use 2 servers instead of a single one?

[pkelly_sts]

We're currently on v8, we tend to take our time moving to new versions (hence why still at ESXi 5.5 given all the v6 issues)

The "destination" site has a B&R server but it's use in this case is purely as a repository (although it has other tasks such as "pull" replication for now). I understand they're unaware of each other but that's actually irrelevant for this discussion as everything relevant is trying to be run from the local B&R server, it just so happens that because this B&R server knows about the copy sitting on the (repository of the) remote B&R server, it's deciding for some reason that that is the best one to use as a source.

[Shestakov]

You are correct looks like all jobs are operated by the same, and yes backup copy job can`t use same repository as source and destination.
Workaround is to create any new folder on the same physical repository, add new backup repository pointed to this folder and then use it in your jobs configuration. In this case you will have the same physical repository, but Veeam will treat it as two different logical repositories.
FYI, v9 has a new component, called Backup & Replication Console which can help decrease number of backup servers used.

[pkelly_sts]

Thanks for the confirmation, my latest test seemed to confirm the situation so I've literally just created the second folder before seeing this reply.

Yes, I'm looking forward to v9 when we're ready to move to it!

[Shestakov]

Great!
Let us know once you have a question.