Run jobs serially instead of parallel

Last post 09-25-2014, 7:29 AM by johanningk. 10 replies.
Sort Posts: Previous Next
  • Run jobs serially instead of parallel
    Posted: 08-18-2014, 7:43 AM

    what's the best way in configuring jobs to run in serial instead of parallel for one client with multiple agents.


    I'd like to have the exchange server to run the database back-up first, and have the mailbox backup start after the database backup completes.

  • Re: Run jobs serially instead of parallel
    Posted: 08-18-2014, 9:05 AM

    Not sure of any particular setting within the GUI that you can use to achieve this, especially as you are trying to achieve it with different agent types.

    You could save the second job as a script and then add the script as a post process of the first job. Might be a bit of work if you need to do this for lots of subclients, but for one or two it could be managable.

  • Re: Run jobs serially instead of parallel
    Posted: 08-18-2014, 9:14 AM

    Yes that's what i thought as well.

    I was suprised i could not find (and set) a max job count per client actually...
    If i have 5 subclients kick off at scheduled time, but only want 2 of them to run at a time for whatever reason, i'm not able to configure this easily...
    If this feature was available, priorities could handle the order in which sublcients start

    ah well.. maybe one day...

  • Re: Run jobs serially instead of parallel
    Posted: 08-18-2014, 9:59 AM

    You can create a workflow and use the wait for job completion option to chain the jobs.

  • Re: Run jobs serially instead of parallel
    Posted: 08-18-2014, 10:07 AM

    hmmz have not thought about workflows!

    I'll have a look at those, but i'd have to upgrade from v9 to v10 first then.

  • Re: Run jobs serially instead of parallel
    Posted: 08-18-2014, 11:12 AM

    If you don't want to bother with WF, scheme you need could be done by

    - create a new SP specifically for Exch DB and MB backup

    - limiting the maximum stream in SP to only 1 stream

    - Create an exch DB subclient, and an exch MB subclient, each with 1 stream

    - create schedule for DB subclient to start ealier than MB subclient for 1 min.

    Once you follow above steps, you see that DB will get backed up first, and MB backup wait until DB backup finish.

  • Re: Run jobs serially instead of parallel
    Posted: 08-19-2014, 7:34 AM

    yeah that's possible, but with the major disadvantage of managing a seperate SP just to get this done

  • Re: Run jobs serially instead of parallel
    Posted: 09-24-2014, 5:17 AM

    Is there an example available for such a workflow ?

    I'm currently having the same problem with backing up of SQL DB + Filesystem on different Clients, where a pre Script is needed on the Filesystem Client before any (including the DB) Backup is started and a post script on the Filesystem Client after ALL Backups are done.

    so serializing this with a workflow, seems to be promising.
    Only no example WF available for this use case


  • Re: Run jobs serially instead of parallel
    Posted: 09-24-2014, 9:58 AM
    • Ali is not online. Last active: 07-03-2019, 12:32 PM Ali
    • Top 10 Contributor
    • Joined on 08-05-2010
  • Re: Run jobs serially instead of parallel
    Posted: 09-24-2014, 10:40 AM

    One option is to use alerts. Configure an alert for successful job completion and then you can either run a script or a workflow which starts the next job. If you simply want to cap the number of jobs running on a client then there are some hidden options for it.

  • Re: Run jobs serially instead of parallel
    Posted: 09-25-2014, 7:29 AM

    hi ameykarandikar 

    Using Alerts, seems to be the easiest approach for this.
    I have to think of "error handling" in those cases the jobs can not be iniiated by "qoperation execute -af backup.xml -tf token -backupLevel %xxx% ...." but this seems ok.

    using a command (batch) as alert on jobsucess can do the trick to build up a backup chain.
    I can even forward the backupLevel  of the monitored job to the new backups to be started (cool)
    so schedulePolicies on the first backup in the chain can be used to get the same level of Backup to all the following jobs. 

    not easy to manage, but its for only limited amount of clients :)


The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Copyright © 2020 Commvault | All Rights Reserved. | Legal | Privacy Policy