Showing results for 
Search instead for 
Did you mean: 

Duplication multiplexing????

Any idea when duplication multiplexing will be available? When I look at my drives as a duplication is is shoe-shining. Write a little data....spin the tape...write a little data....spin the tape. The manufacturer of the drives says this is a BIG problem with Netbackup an duplication jobs. I have replaced 3 L5 drives in the past month. I can olny assume it is due to the duplication jobs. Thank god for waranties.

6 Replies

Please share more info: NBU

Please share more info:

NBU version as a start, as things are done differently across various NBU versions.
OS on media servers and resource capabilities to efficiently drive LTO5?

Type of duplication - SLP? DSSU? Vault?
Documentaion available for each type explaining how images are grouped into 'chunks' for efficient duplication.

Information on source and destination STU?
Basic Disk to Tape? VTL to tape? Advanced or OST to Tape?
Local SAN duplication on same media server or across network from one media server to another?
If local disk to tape, are tapes and disk zoned to different HBA's?

We see excellent duplication rates with local duplications - maintained rate of more that 100 Mb/sec using LTO3.

As you can see, there are LOTS of factors that play a part in data transfer. It is therefore extremely irresponsible of your tape vendor to make blanket statements.

OK, I see in one of many tags that you seem to be on NBU 7.5.

If using SLP, there is an

If using SLP, there is an option to 'preserve multiplexing' - so I would sugest this is already available.

From page 552 of 7.5 Unix Admin Guide 1


Select whether to Preserve multiplexing. This option is available for
Duplication operations that use tape media or virtual tape libraries (VTL).
As Marianne asked, what type of duplication are you using.

I am backing up to a media

I am backing up to a media server dedupe pool(puredisk) on windows2008 R2. The storage is direct attached(6gb sas). The LTO5 drives aew direct attached to same media server via 8gb fiber. My issue is not with the disk or tape speed. It is with duplication using a simple SLP. The duplication jobs are "single" threaded. Even if I check preserve's still single threaded. Here is an example...If I backup 15 servers(100gb of data) stright to a tape and use multiplexing....the job will finish in approx. 1hr. If I use an SLP to goto the media server dedupe pool, then duplicate to tape....the duplication may take approx. 2hrs.

Are you aware of the SLP best

Are you aware of the SLP best practise guide?

It describes how backup images can be grouped in bigger 'chunks'.

Rehydration has been a 'known issue' when duplicating from MSDP to tape:

Not sure if the 'fixes' mentioned in this TN has made it into 7.5 binaries. You may want to have a look at and Release Notes. Look for improvements related to rehydration.

Problem also discussed in this thread:


I rehydrate to disk first

As per best practice my SLP rehydrate to disk first; then push the images off to tape.  Stops any issues.

No, MSDP dedupes when writing

No, MSDP dedupes when writing to disk. Data is rehydrated (opposite of dedupe) when copied to tape. The process of finding all the bits and pieces to send to tape in non-dedupe format (rehydrate) is what is taking so long.