-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Some quite valid points.  The splitting of a DSU's to alternate media
servers sounds like requirements from Veritas engineering would be
needed as the images on disk would be owned by a different media server.
I suppose scriptable be I can foresee several potential hiccups in the event
of errors.

Have you identified all the performance stats for each item in the mix?
So, for instance:
 max read/write of one tape drive
 max read/write of two or more tape drives at the same time
 max read/write of one LUN from CX
 max read/write of two or more LUNs from CX at the same time
 utilization rate of FC ports in switches throughout fabric

Not to ask a silly question, but are you sharing data paths at all?
There have been some posts in the past week or two on max transfer rates
round on LTO3, have you researched the archives of this list?  How big
a system is the media server?  Does it have the bandwidth to perform what
you want it to?  These all may be futile questions as you may have
reached the limits of your storage system.  The obvious but potentially
more expensive solution is to spread your load across more media servers.
It is a fully supported configuration...

Thanks
Peter

Peter DrakeUnderkoffler
Xinupro, LLC
617-834-2352



Weber, Philip wrote:
> Sorry if this has been done to death recently but...
> 
> What sorts of disk systems are people using as disk staging to keep
> LTO3s happy?  Our current EMC Clariion Cx300 struggles to supply data
> fast enough to 3 LTO2 drives (even outside of NetBackup) and performance
> goes through the floor if (as is often the case) it is still trying to
> write backups to disk while streaming data off to tape.  We have pretty
> much a 24*7 backup window with lots of slow & small, slow & big, and
> some fast, clients.
> 
> It seems the idea that you need disk staging to keep your LTO tapes
> running nicely, rings a bit hollow.  Also seems to me we're looking at
> needing a high-end disk system.  Which makes a mockery of backing up to
> cheap ATA/SATA disk being the way forward.
> 
> The only way I can see to get around the performance problems with
> writing/reading backup streams to/from disk concurrently, other than a
> high-end system, is to script some kind of mirror-split-off process and
> use it to do the duplication with scripts rather than DSSU.  i.e. back
> up to disk overnight & then split a mirror off (to somewhere where its
> I/O will be separate) and duplicate off this during the day before
> resynching.  Anybody do anything like that?  I can see all sorts of
> nasty gotchas ... maybe that way madness lies?
> 
> cheers, Phil
> 
> Phil Weber
> Business Technology (Egg)
> Storage Technical Services - Senior UNIX Technologist
> Phone: 01384 26 4136
> Mobile: 07748 333503
> Jabber: weberp at jabber.pn.egg.com
> 
> -----------------------------------------
> Egg is a trading name of the Egg group of companies which includes:
> Egg plc (reg no
> 2448340), Egg Financial Intermediation Ltd 
> (reg no 3828289), and Egg Banking plc (reg 
> no 2999842). Egg Banking plc and Egg 
> Financial Intermediation Ltd are authorised 
> and regulated by the Financial Services 
> Authority (FSA) and are entered in the FSA 
> register under numbers 205621 and 309551 
> respectively. These members of the Egg group 
> are registered in England and Wales. 
> Registered office: 1 Waterhouse Square, 138-
> 142 Holborn, London EC1N 2NA.
>  
> 
> This e-mail is confidential and for use by 
> the addressee only. If you are not the 
> intended recipient of this e-mail and have 
> received it in error, please return the 
> message to the sender by replying to it and 
> then delete it from your mailbox. Internet e-
> mails are not necessarily secure. The Egg 
> group of companies do not accept 
> responsibility for changes made to this 
> message after it was sent.
> 
> 
> Whilst all reasonable care has been taken to 
> avoid the transmission of viruses, it is the 
> responsibility of the recipient to ensure 
> that the onward transmission, opening or use 
> of this message and any attachments will not 
> adversely affect its systems or data. No 
> responsibility is accepted by the Egg group 
> of companies in this regard and the 
> recipient should carry out such virus and 
> other checks as it considers appropriate.
> 
> This communication does not create or modify 
> any contract.
> 
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)

iD8DBQFFE7FLl+lekZRM55oRAgdpAJ0cdyS6ncDyvk+NreG40i7eXDCwpACeO1wQ
puv/Vkd9B2jvob2Zqd/2FDs=
=0CZ5
-----END PGP SIGNATURE-----