VBR12 - backup copy job scheduling after another backup copy job

[doktornotor]

Backup copy job scheduled after another backup copy job is not possible? The only "copy type" options that appear in the dropdown selection are file copy and application plugin copy jobs. Maybe I'm confused/missing something but I somehow recall this was working with VBR 11.

[HannesK]

Hello,
backup copy jobs from backup copy jobs are not available in V12.

Before merging your question to the existing thread, I would like to know, whether that's really what you ask for? BCJ -> repo 1 -> BCJ -> repo 2

Backup copy job scheduled after another backup copy job is not possible?

that option did not exist in V11. I just checked it. The "after this job" option does not exist in V11.

The only "copy type" options that appear in the dropdown selection are file copy and application plugin copy jobs.

that sounds like a bug. Do you have a case number for that? It should show "image-level backup", "Application level" and "storage copy" (only if HPE StoreOnce is connected). File copy is a separate button and not in the dropdown menu



Best regards,
Hannes

[doktornotor]

I am aware of the v12 limitation you mentioned, by the question was merely about scheduling. E.g., schedule BCJ(x) to run after another (different) BCP(y) is finished. Not to use the files/repo used by BCJ(y) by BCJ(x).

[HannesK]

for scheduling: that option never existed. If you create to backup copy jobs in periodic mode, and just give them different start times, that should be close to what you want to have. The first backup copy job will consume all repository tasks because it already runs. So the second backup copy job will have to wait until the first one finishes.

Which problem do you try to solve?

[doktornotor]

Well, basically BCJ1 -> BCJ2 -> ... -> BCJx (most important first) to various offsite locations over a junky internet connection so that they get completed over weekend.

[HannesK]

if bandwidth is the limiting factor, then reducing tasks would probably not help. I would set static start times and stage them. Not optimal, but hopefully "close enough"

[doktornotor]

Ok, thanks for comments. Consider this a feature request.

[HannesK]

well, chaining jobs in general is a bad idea. let's say you have 50 branch offices and you do 49x "run after". if the 2nd backup copy job fails, then all the other 48 backup copy jobs will never start.

overall, there must be enough bandwidth anyway. if there is not enough bandwidth for parallel backup copy jobs, then also sequential jobs (especially the last ones) will never finish.

I'm not sure whether that option would solve the problem

[doktornotor]

Turns out Veeam does better job than expected, especially once the initial "seeding" is done. Testing with Wasabi, the first "full" backup took less than a day, wonderful. The subsequent backups seem very fast (there's not so much changed). The remaining BCJs are pretty small, so it looks this won't be much of a problem. Will keep watching it for a couple of weeks.