Ver. 8 "After this job" schedule doesn't manually work

[CCS-IT]

Current version: 8.0.0.917

We have several backup jobs that are scheduled to run chronologically. When the first job in the chain runs on the scheduled time all other jobs run after as they should.

The problem is when I run the first job in the chain manually all the other jobs that need to follow do not run. Again the way the jobs are set to run chronologically. Any help?

We just upgraded from version 7.0.0.690 to 8.0.0.817; then installed Patch 1.

Thank you.

[veremin]

It's expected behaviour. We've implemented this logic in version 8 due to amount of requests and complains we had previously. Thanks.

[CCS-IT]

v.Eremin,

Thanks for replying.

Can you clarify further or shine on another way I can manually run the first job and it would trigger all the other jobs?

[veremin]

PowerShell script executing jobs one by one might be one way to go. Thanks.

[Josh-VCAP]

Hello, I just upgraded to Veeam Backup and Replication 8 and am now having issues with the way my backup jobs are scheduled.

I have about 15 jobs and extensively use the "after this job" scheduling so that it's a big loop / chain and we always have something being backed up. I do not want to schedule anything for a specific time as this will either cause jobs to overlap if the total takes over 24 hours or will leave time when nothing is being backed up if less.

After manually starting one job and it completing the next one is supposed to start but it never does even though it's scheduled after one that has just completed.

I called Veeam support and he told me this was now by design in version 8 and i should submit a feature request then got off the phone...what the heck?

Veeam Support - Case # 00734239

[veremin]

After manually starting one job and it completing the next one is supposed to start but it never does even though it's scheduled after one that has just completed.

That's by design, indeed. We were forced to that due to number of complains we'd had previously.

On a side note - what's main reason of using after this job type of schedule? I'm wondering because the recommend approach is limiting number of concurrent tasks proxy/repository can have.

Thanks.

[spittles.adam]

Hi,

I have noticed that with Veeam V8, unless a job is kicked off by a schedule the job no longer chains i.e doesn't kick off the next jobs. I have also had Veeam support confirm this.

This can be a real pain if we had a set of backups not run, or we wanted to delay them due to a backup copy synchronizing etc.

I can see the benefit of this, as we create a backup job per guest, so it's nice to be able to run just one backup, but it would be nice to have the option of 'run this job only' or 'run all jobs'. Maybe something you can tie into a right click on the job?

Thanks!

A

[foggy]

Adam, may I ask you the same question: in your case, what is the reason of using chained jobs, which are not among our best practices?

[Gostev]

I can see the benefit of this, as we create a backup job per guest, so it's nice to be able to run just one backup, but it would be nice to have the option of 'run this job only' or 'run all jobs'. Maybe something you can tie into a right click on the job?

This would be a good idea indeed, however normally there is simply no sense to chain jobs to start with...

[Josh-VCAP]

My reasoning is around a multi-tenant environment with vCloud Director

We have numerous customers and a separate job for each customer. I don't really care when the jobs run as long as we are getting backups at least once per day per customer but preferably as frequently as possible.

When I chain all my customer jobs it ensures that backups are being completed and on to the next customer as soon as possible with no dead time or overlapping time between jobs.

[tedgrandpre]

"That's by design, indeed. We were forced to that due to number of complains we'd had previously"

I am curious to know what complaints were filed from having the option to chain your jobs.
I too deeply miss the chain functionality.

[veremin]

The major issue was the fact that running one job manually resulted in the execution of whole chain. That's not the case with version any longer.

Thanks.

[spittles.adam]

@foggy

Reason we create a backup per guest is:

Granular control on the backups
Speeds up the backup copy process - I run a single backup copy job that covers all vm's, when jobs are set individually a backup copy will begin while other backups run. if all backups are contained in one job, the backup copy will not start until the job is finished.
Less impact should a backup chain get corrupted
Easier management - because I have each guests backup in isolation, moving and managment becomes easier.

I totally get why this feature is here, however I feel it would be a very good idea to have the option to manually kick off your schedule if required. For example, I have a patching Window every other month on Tuesday evenings which sits right in my backup window. I disable all the backups, patch then re-kick the jobs off. I now have to sit and manualy kick off each job, or wait until the following day. Not a deal breaker, however the additional option I mention above I feel would go down well!

A

[justind]

I don't know why you guys can't make these kind of changes configurable.

A "one size fits all" mentality doesn't work that well when you flip-flop between implementations and expect users to just deal with the fact that the feature has changed behaviour.

[foggy]

When I chain all my customer jobs it ensures that backups are being completed and on to the next customer as soon as possible with no dead time or overlapping time between jobs.

Reason we create a backup per guest is:

Granular control on the backups
Speeds up the backup copy process - I run a single backup copy job that covers all vm's, when jobs are set individually a backup copy will begin while other backups run. if all backups are contained in one job, the backup copy will not start until the job is finished.
Less impact should a backup chain get corrupted
Easier management - because I have each guests backup in isolation, moving and managment becomes easier.

Guys, I totally see your reasoning behind what you're doing, however don't see why you cannot do the same without chaining the jobs, but rather configure concurrent tasks maximums and just start the jobs at the same time (with short intervals), to let Veeam B&R handle everything automatically.

[spittles.adam]

@foggy

Thanks for your reply.

I guess it's because chaining jobs is easier from a management aspect, it also results in less changes of the infrastructure. Say a new server comes along, I would then have to start changing concurrent connections - something I would consider a change. Instead with chaining, I can just add a new job, tag it on the end. I can leave all the default settings of veeam in tact and it's very very clear exactly what is going on.

I get Veeam have invested a lot of time in working out clever ways to make this work, however some customers want to have control and do some of the clever stuff themselves. Playing devil's advocate a bit here, if Veeam don't recommend chaining, why give customers the option to do so? It would be a really different discussion if customers were making their own way of chaining, and then complaining that veeam didn't support it.

At the end of the day, it is what it is and it doesn't change that veeam is simply an amazing product. However I think it would be beneficial to everyone to give your customers as many options as possible as no two Infrastructure's will be identical

A

[foggy]

Adam, indeed, you're free to use whatever works better for you and your specific environment, we're just recommending what looks more optimal from our perspective and doesn't have so much unexpected consequences. Provided you're aware of them, you're good to go.

Though I didn't get you statement regarding infrastructure changes, as adding new VM doesn't change anything from the proxy/repository resources perspective (where concurrent tasks limits are defined once and until hardware changes).

[Josh-VCAP]

Guys, I totally see your reasoning behind what you're doing, however don't see why you cannot do the same without chaining the jobs, but rather configure concurrent tasks maximums and just start the jobs at the same time (with short intervals), to let Veeam B&R handle everything automatically.

Then the individual VM's from each job get staggered and it takes longer over-all to complete each job, during this time we are unable to perform restores for customers with jobs open. Additionally if a multi-tier app needs to be restored the individual VM's restore points are spaced out further. I wouldn't like to tell our customers that we can restore one server from 5am but another server from 2pm if they have a global event like a network virus.

[foggy]

Do you mean that tasks from different jobs are mixed during processing? This should not happen as jobs are prioritized according to their start time and the job that started first should get resources for all its tasks first (at least in v8).

[belybely]

Sorre for my english i am a french canadien

Just lost my sunday on this one. As it was March,1 i suspected a "29 feburary" bug in the new version or corruption in VEEAM as i used manual scheduling following vSphere/SAN problems. Tried all i could to have job chain work when started manually without luck. Gave up in the evening. Monday morning saw all jobs chain runned correctly during the night. Youpi it works dont try to figure why !!!. Had to stop/restart VEEAM and do a manual start in the afternoon : Oh problem again, no chained job started. Monday night done search on Internet and found a thread about the NEW USELES FEATURE (Read below) REPLACING AND EXISTING USEFULL FEATURE.

I opened a case with no luck : It's a "Feature". First time i see a feature removing another feature. I always see those cumulative.

As this "Feature" was supposelay highly asked for by customer i HIGHTLY SUGGEST than LIKE ME you ask for the following "REAL NEW usefull FEATURE" :

In the popup menu of right click of Job replace "START option by two options :
"START THIS JOB" The new Feature as it is currently.
"START THIS JOB CHAIN" The old Feature of V7.
That should be not difficult to implement and it and with it VEEAMS should have ALL it's customer 100% satisfied.

For those who wanted the new feature and did not like the old one. YOU HAD A SO EASY SOLUTION :

Suppose you had the following chain :
JOB 1 run at 01:00
JOB 2 run after JOB 1
JOB 3 run after JOB 2
.
.
.
JOB x run after JOB x-1

To have just job 1 starting you had only to:
-use option "Disable" on JOB 2
-Start JOB 1 and wait it complete
-use option "Disable" again on JOB 2 to Enable it again before next sceduled time for JOB 1...

More generally to have just JOB n starting in a chain you had only to :
-use option "Disable" on JOB n+1
-Start JOB n and wait it complete
-use option "Disable" again on JOB n+1 to Enable it again before next sceduled time for JOB 1...

With the new Feature we have 3 unfrendly method to use the old missing Feature:
-Change the scheduling, for complex job it can be a real problem
-Start the first, wait it complete, start the second, wait it complete, ..., start the last one of the chain
-DO coding in Powerscript : Thats really a lot more complex than using right click "DISABLE"

VEEAM PLEASE PLEASE implement my suggestion !

Thanks'

[Josh-VCAP]

Found a way around this problem with a powershell script I put together.
Paste the following into a text file, extend it for as many jobs as you need. Name it Veeam-Cycle.ps1
Then open an poershell prompt, navigate to it's directory and type .\Veeam-Cycle.ps1

Add-PSSnapin VeeamPSSnapin
start-vbrjob -Job "job 1"
start-vbrjob -Job "job 2"
start-vbrjob -Job "job 3"
.\Veeam-Cycle.ps1

You'll have to leave the powershell window open since it will run continuously.

[veremin]

If you're ok with scripting, you can also utilize post-job command. Just copy the command line string from "Summary" page of the given job and paste it as post job command in the settings of the job after which the first job should be executed. Thanks.

[abecyprys]

I have the same problem - when a replication fails - and I re-try the job manually, all the rest of the "RUN AFTER" scheduled jobs now do not run.

Does this mean I have to sit around and wait until the re-try finishes before I then trigger the next job? - after which the next "RUN AFTER" job will not work, because I triggered the job manually.

So, instead of manually triggering the next job, I need to go into the schedule, and make it run a few minutes after this current time, then once it starts, need to go back in and change the schedule to what it was originally.

Does this sound like a feature? NO.

There needs to be an option in the schedule to allow "RUN AFTER" even after the previous job was triggered manually.

Thanks.

[belybely]

I installed Update 2 to version 8 and found than one of those "1000 changes" was to implement my suggestion to have manually executed scheduled job work both way (with chained job executed or not) ! Thank's VEEAM

With update 2 when we manually lunch a scheduled job with chained job the following windows ask what we want to do with the chained job :

+------------------------------------------------------------------+
| Veeam Backup and replication |
| ==============================================|
| ? This job has one or more other jobs chained to it. |
| Would you like to execute chained jobs as well ? |
| YES NO |
+-----------------------------------------------------------------+

Thank's again for your rapid correction of this frustating "new feature" of version 8

[foggy]

A number of requests in this thread have justified this change.