killing a job on specific time

Have you tried to set a blackout window for when you want the jobs to end?

@Orazan - Does blackout window impact already existing running jobs? It only queues newly triggered jobs for later AFAIK.

Can you please confirm?

`Hello @Orazan 

Yes, actually i am using blackout window..
But the issue for me, using blackout window is that Backup job stay “paused” during blackout window.

I am backing up some Virtual Machines, and, the issue is: All Snapshots stay on vmware until job is on blackout window, and it is impacting end user..

I need that all jobs get killed. Because on killing process, all snaps get excluded.

@christopherlecky - This might not be feasible.

What if jobs are neither queued, nor in waiting / pending and are progressing normally. If we kill the job, even if it’s progressing normally, it would just end up occupying more media on disk / cloud (unless aged by data aging) and new job will eventually be backing up same stuff.

Plus, the screenshot seems to be at individual job level. I think he would have to make this change at schedule policy level.

Not sure if customer is looking for this option, but let’s see.

Hard to tell, he refers to a single vm but also uses “they” which references multiple vms 

Which is why I specified “schedule / schedule policy” it’s hard to answer questions definitively without assuming a base level of competence.

Either way any change he makes, he will learn what he’s not understanding when he audit’s the results the next day.

Have you tried to use the blackout window in conjunction with running time.  The job would be paused by the blackout window and while paused would hit the max run time and be killed

So now that the question has been answered the follow up question is why are backups running too long? Do you have a specific job that is taking too long to complete or is this a larger issue with mutiple vm jobs running longer than expected?

Whoops just reviewed the entire thread and see you have discussed this option already.

Hey Folks.

Thanks for all help, so, let me try to explain clearly…
I have some VMs being backed up (hosted on a vmware).
My datastore has some old disks that does not permit to execute any backups using Hotadd transmer method. I use NDB Method. And, we have also some network issues as well.

This is why all my vms backups take so much time to be completed.

End user DOES NOT permit that any backup will continue after 6AM (my backup window is so agressive: 2am-6am)

Everyday on 6:01am, end user is sending e-mails to Management, telling there exists some vms taking backup and impacting the vm)

I already tried to use blackout window, but the issue to use blackout window is that Snapshot taken still continue on Datastore and, end user does not permit it. But when i kill the job, snapshot get excluded.

I also tried to use Total Running time configured. But the issue that i have is. Those VM Backups does not start everyday on the same time. Some days it start on 2am. Some days it start on 3am…

But you gave me an idea that maybe can work. “to use blackout window with total running time”.

I'll try this method, and keep everyone updated

thank you folks!

I dont think it will get the results you are looking for.

The reason they aren’t running at the same time is likely the number of vms are causing them to queue up. Based on stream limits. What you want ideally to have as many vm backups running at the same time as is feasible. 
essentially its a challenge of optimization.

you may want to engage with PS, send me a private message if you decide to go that route. 
 

Put another way the actual problem you want to solve is getting as many vms to run in parallel as possible starting at 2 AM, it’s quite likely that this limitation is self imposed, but you will need to increase the effective stream limit until you have reached the physical limitations imposed by your hardware.

Those limitations are

1. Concurrent VM snapshots
2. Storage speed
3. VM Datastore free space
4. Bandwidth for moving the data
5. Proxy allocation - ie the number of scsi slots available per proxy.

if you are lucky you can just spin up a bunch more proxies increase their disk slots and turn up the number allowed streams on the storage policies and disks.

the risk of doing this is running out of a disk space on the datastore since snapshots wont free as quickly with so many concurrent snaps. 
 

the job time limit should be imposed only in addition to the changes needed to meet your backup window.

Or you can cheat and migrate to intellisnap.

Your “backup” window would shrink to a few minutes.