Feature Request: Scheduling > After This Job Continue with next job if fails option please.

[NickKulkarni]

Love the "After this Job" feature.

I set the first job in my backup list and no matter how long it takes the next job doesn't start until the previous one is finished and so on.

Previously no matter how careful I was with scheduling jobs they would collide swamping available resources in our ancient low power environment.

We use the options for periodic full and backup image verification and stagger this so not all backups do this at the same time or day. Prior to using "After this Job" we would regularly get job collision as one tried to start before the other finished.

I have just discovered a bug in this scenario. If a job in the chain fails, subsequent jobs do not execute. Given that it looks as if when the primary job fails none of the other jobs in the chain will execute. If the option to "continue with next job if this one fails" exists already I haven't found it yet.

[Mildur]

Hi Nicholas

If a job in the chain fails, subsequent jobs do not execute.

This is expected behavior. The first Job must be successful or with warnings. If not, the following jobs in the chain will not start. We don't recommend to use "After this Job" for backup jobs. That is one of the reasons.
You can use task limitation settings to make sure that jobs are not overwhelming the backup hardware resources in your environment. As an example, if you set proxy and repository settings to only use 1 Task, then you will never have a second job running.

You can also use Storage I/O Control to protect your production storage.

Thanks
Fabian

[NickKulkarni]

Hi Fabian,
Thanks for the reply about expected behaviour. I understand that, I was looking for that to have an option to change that behaviour or we get a "single point of failure" scenario.

Very grateful for the links to Storage and Task limitations, sadly I am already using them and the problem seems to be related to something else that may be unique to our setup. I have a linux Proxy and the Backup & Replication Server on one of our Physical Hosts. When backing up a VM on the same physical host using the Linux Proxy in Hot Add mode the read rate indicated on the graph in the B&R Console exceeds 120 MB/s and the 1Gbe VMXNet3 NIC, despite network throttling at 800 Mb/s it peaks at over 1GBe in the Task Manager performance charts. Storage latency restricted also but Veeam ONE reports potential ransomware activity as both Storage and Network saturate. This particular scenario is the only one affected all the others don't suffer from this massive read speed and therefore throughput to the B&R server. I read that the actual inter VM bus is 10Gbe but Veeam is possibly only seeing the VM NIC 1Gbe and attempting to throttle at this point.

[NickKulkarni]

Alarm: Possible ransomware activity
Status: Error


Previous status: Reset/resolved
Time: 08/07/2022 18:29:52
Details: "Network Transmit Rate" (99.7 MB/s) is above a defined threshold (90.0 MB/s) for '4001';
"CPU Usage" (80.0%) is above a defined threshold (80.0%)

[Mildur]

Your welcome.

Very grateful for the links to Storage and Task limitations, sadly I am already using them and the problem seems to be related to something else that may be unique to our setup. I have a linux Proxy and the Backup & Replication Server on one of our Physical Hosts. When backing up a VM on the same physical host using the Linux Proxy in Hot Add mode the read rate indicated on the graph in the B&R Console exceeds 120 MB/s and the 1Gbe VMXNet3 NIC, despite network throttling at 800 Mb/s it peaks at over 1GBe in the Task Manager performance charts.

The read speed can be higher than 1Gbit/s with the HotAdd Method.
But the network throttling between the proxy and the backup repository should be 800 Mb/s if you configure it to that value in Veeam.
I would recommend you to check that with our support.