Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.

Backup Exec 2012 SP2 - Jobs don't run if one job "queues"

Created: 13 Sep 2013 | 7 comments

Hi, We are running Backup Exec 2012 SP2 on a Windows 2008 r2 x64 server.

The scenario is that we backup all our servers to 4 internal disks and then duplicate them to 2 x USB/eSATA disks for taking off site. Each internal disk can run 8 jobs at once with the external disks set at 4 jobs per disk,.

Lately our backups and duplicates have been taking longer and longer and we put this down to our external hardware... USB3.0 Caddies with SATA 2TB and 3TB disks...

We changed to eSATA III as a test and still they were slow...

We reduced the number of jobs on the external disks to 2 each for testing and noticed that if we ran 3 jobs to say 'External disk 1' - 2 would run and 1 would queue and then set some jobs running for 'External disk 2' they would queue... Is this correct even though both external disks can have 2 jobs running at the same time? The jobs for external disk 2 would start when one of the jobs for external disk 1 would complete so the queued job for external disk 1 would start..

Hope this makes sense...

Is this correct, backup exec queues all the jobs sequentially even though a job could run elsewhere or I have done something wrong?

Thanks everyone..

Martin

 

Operating Systems:

Comments 7 CommentsJump to latest comment

Donald Eady's picture

under the properties of the disk storage location did you adjust the number of concurrent jobs that can be run ??

 

 

concurrent.JPG

I hope this posting was helpful

  

MartinBerry's picture

Yes, both disks are set to "2 Concurrent write sessions"...

 

 

Donald Eady's picture

You would need to increase the number of concurent sessions. if you have two jobs writting to say internal disk one and you go to run the duplicate job to external disk one at the same time i will que as there are already 2 sessions being occupied on the internal disk. once your internal completes one of these jobs and has an available session the duplicate kicks off now occupying the available session "even though its reading from the disk and not writting" so when any other job that targets that disk location will then que until a session is freed

I hope this posting was helpful

  

MartinBerry's picture

Thank for your response again... The internal disks have 8 concurrent sessions per disk as these are SAS disk and handle multiple sessions better than SATA disks. So in theory this should not be the case.. e.g.

If you run the jobs in this order:

All these run from Internal disk 1 that can handle 8 sessions

BckUpJob1 --> duplicate to External disk 1    (One Session)
BckUpJob2 --> duplicate to External disk 1    (Two Session to External disk 1)
BckUpJob3 --> duplicate to External disk 1    (Queues because there are 2 concurrent sessions)

All these run from Internal disk 2 that can handle 8 sessions

BckUpJob4 --> duplicate to External disk 2    (Queues, but this has 2 free concurrent sessions)
BckUpJob5 --> duplicate to External disk 2    (Queues, but again there should be a free session on ED2)

BckUpJob4 & 5 will not run until BckUpJob3 runs, it seems to be when a job before hand goes into a queue state it stops other jobs from running.

Thanks

Donald Eady's picture

in the scenaraio above you dont say where the jobs are comming from... 

BckUpJob1 --> duplicate FROM to External disk 1    (One Session)

BckUpJob2 --> duplicate FROM to External disk 1    (Two Session to External disk 1)

BckUpJob3 --> duplicate FROM to External disk 1    (Queues because there are 2 concurrent sessions)

All these run from Internal disk 2 that can handle 8 sessions

BckUpJob4 --> duplicate FROM to External disk 2    (Queues, but this has 2 free concurrent sessions)

BckUpJob5 --> duplicate FROM to External disk 2    (Queues, but again there should be a free session on ED2)

 

Please fill this in for me.. so i know were the data is being read from

I hope this posting was helpful

  

Donald Eady's picture

I believe that your Source location may have 2 sessions running when the duplicates are kicking off. "This is why they are queing"

 

 

I hope this posting was helpful

  

MartinBerry's picture

Hi Donald, sorry for the delay response... Please note when doing my tests these are the only jobs running..

BckUpJob1 --> duplicate Internal Disk 1 to External disk 1    (One Session)

BckUpJob2 --> duplicate Internal Disk 2 to External disk 1    (Two Session to External disk 1)

BckUpJob3 --> duplicate Internal Disk 3 to External disk 1    (Queues because there are 2 concurrent sessions)

All these run from Internal disk 2 that can handle 8 sessions

BckUpJob4 --> duplicate Internal Disk 4 to External disk 2    (Queues, but this has 2 free concurrent sessions)

BckUpJob5 --> duplicate Internal Disk 4 to External disk 2    (Queues, but again there should be a free session on ED2)

We have 4 internal disks, each disk is set to 4 sessions...

Thanks