Vaulting and multiplexing

[fparki]

We are writing to VTL and vaulting to tape. I appreciate that a media server will write to the VTL with a MPX value of 1 and this would be carried through to the vault to tape i.e. one vdrive to one tape drive. However, where we have multiple media servers writing to the VTL and then performing vaults can these utilise the same drives and benefit from multiplexing i.e. each media server is using a MPX 1 but the multiple media servers are interleaving to the same drives.

The context is to improve the throughput of the tape drives which are currently pegged to the same speed of a single vdrive during vaulting.

Thank you,

[mph999]

I don't believe so.

You mention, one VTL tape to one tape drive' - just be aware that although this is what you achieve, Vault doesn't actually copy tapes as such, it copies images.

Anyhow, back to the question:

From the Vault admin guide

This is what Vault can duplicate

From multiplex to nonmultiplex format.

■ From multiplex format and retain the

multiplex format on the duplicate. The

duplicate can contain all or any subset of

the backups that were included in the

original multiplexed group. This process

is done with a single pass of the tape. (A

multiplexed group is a set of backups that

were multiplexed together during a single

session.)

It doesn't mention anywhere it can go from non-multiplexed to multiplexed.

Martin

[fparki]

Thanks Martin.

Does the admin guide speak from the perspective of a single media server or multiple? I want to argue that the MPX level from a single media server would remain constant and that the interleaving of the output from multiple media servers to the same drive is MPX at a different level. I suspect that this is not possible as a single media server will acquire a lock on the drive. If that is the case I would welcome any thoughts on how to increase throughput with a one-to-one relationship of vdrive to tape drive with the assumption that we cannot increase the vdrive throughput to match the LTO5 performance. 

[mph999 · Accepted solution]

Single.

You are correct, two media servers are not going to mpx together, as only one can write to the drive at any one time.

How fast is the dup going, LTO drives have got so fast that it doesn't surprise me that the VTL can't drive the  LTO drive at it's maximun speed, but it should go fairly fast.

Also, as a matter of interest, how fast do the backups go.

You will notice I'm avoiding the mpx at the moment, firstly, bacuse I don't think it is possible, and secondly because it shouldn't be necessary.  One of the ideas of VTLs is that they are good for clients that backup slowly (no shoe shining issues) but can then write to real tape quickly.

So I think the first question is to understad what speeds you are getting, and then from this determine if the VTL is performing correctly, if not, can it be fixed.

If it is performing well then, some ideas ...

• Check speeds of normal backups and duplication from bptm log (search for Kbytes/sec). If backup speeds are slow then you can’t expect duplication speeds to be good either.
• Check for the size of the image that is being duplicated (is it large)? How long did the backup for it take? Compare with how long the dup take.
• Determine where the bottle neck is happening in the duplication process (delays in waiting for empty buffer or full buffer?)
• Check if duplication is going across the network or local? If going across network, change it to local by using altreadhost. See if speeds improve.
• Check the bptm buffer sizes (number of data buffers and size data buffers).
• Are the backups MPXed, if so, ensure MPX being preserved during duplication.
• Check that there is no media contention between duplication batches (look at source media ids in duplicate.log.X in the sid directory). Media ids should be unique amongst dup batches. If they are not then it is a  batching problem (see batching section).
• If dealing with Solaris 10, ensure TCP_FUSION is disabled.

Regards,

Martin