Showing results for 
Search instead for 
Did you mean: 

Relationship between B2D 'Concurrent Write Sessions' setting and Duplicate to Tape Operations

Level 4

Curiosity question - the answer to which may have an impact on Backup Performance

BE 2014 (still) - I am noticing that if I have a B2D volume configured with [Concurrent Write Sessions] set to [1] using the Storage --> Properties page in the BE GUI it seems that Duplicate to Tape operations (which as far as the B2D volume is concerned should only be a read operation) prevents other backup jobs from beginning until the duplication completes.

For example (using actual historical data):
      I have a backup job that is scheduled to begin at 6:30 AM with a linked 'Duplicate to Tape' operation upon completion.  The job runs for about 20 minutes, ending at roughly 6:50 AM.  The linked 'Duplicate to Tape' operation then begins immediately and lasts for just about 10-12 minutes, ending at roughly 7:02:37 AM.
      The next backup job which is utilizing the same B2D volume is scheduled to begin at 7:00 AM actually begins at 7:02:39 - a few seconds after the 'Duplicate to Tape' step of the previously scheduled job utilizing this B2D volume completes.

(The serial nature of the backup scheduling is by design as it provides the best performance for our iSCSI storage, I have several B2D volumes configured to provide parallelism by way of multiple volumes rather than multiple write operations to the same volume, this methodology provides greater available disk queue depth at the iSCSI level over a single volume.)

In theory, the 'Duplicate to Tape' operation should only be reading the backup sets from the B2D voume and writing to the Tape media, so shouldn't necessarily count as a 'write operation' as far as the B2D volume is concerned.

I'm curious as to why the dupliacate operation seems to be considered a 'write' operation as far as the B2D volume is concerned and seems to be causing subsequent backup jobs to be delayed while the 'Duplicate to Tape' completes.
(Duplicate to Tape also verifies the backup sets during the duplicate job so as to allow DLM to clean up the B2D volumes faster.  Again, this should only be a 'read' operation as far as the B2D volume is concerned, so in theory, should not be preventing subsequent backup jobs from 'writing' to the B2D volume.)

(The delay in this example is only a few minutes, but can be greatly compounded over time.)


         Random thoughts, personal experience, insights and ramblings are all appreciated,
                      Thank you,