It happened frequently for me, otherwise I'd much
rather let the robot handle cleaning. 


--- "Brochart, Fabrice" <BrochF AT europe.stortek DOT com>
wrote:
> 
> You right, sometimes it did it.
> NetBackup wait a while before downing the drive.
> It depend of the clean number of the cleaning
> cartridge, but normally
> NetBackup didn't Down the drive.
> 
> So here are the choice: 
>                               1° TapeAlert (system)
>                               2° Cleaning Periodic
>                               3° AutoClean with Robotic
> 
> First, normally it should be the good choice, your
> system must support it.
> Veritas doesn't seem to like it.(?)
> 
> Second choice : DLT ask when it need a cleaning , so
> if you clean it
> periodically you may wait a long time between a
> demand from the drive and
> the effective clean and it's destructive (abrasive)
> for the drive head, so
> life time head is shorter.
> 
> Third choice : Good but as Douglas said ,sometimes
> NetBackup could down the
> drive due to the time of cleaning (rarely but
> exist).
> 
> As you want.
> 
> F@b
> 
> 
> -----Message d'origine-----
> De : Douglas Ritschel [mailto:dritschel62 AT yahoo DOT com]
> Envoyé : mardi 18 mars 2003 15:35
> À : Brochart, Fabrice; 'Weber, Philip'; NBUList
> (E-mail)
> Objet : RE: [Veritas-bu] Cleaning Frequency
> 
> 
> NetBackup gets confused if the robot's autocleaning
> inserts a cleaning tape in a drive at the same time
> NetBackup attempts to use the drive. There is a
> collision and NetBackup marks the drive as down.  
> 
> 
> 
> --- "Brochart, Fabrice" <BrochF AT europe.stortek DOT com>
> wrote:
> > Hi,
> >  
> > Effectively, you must not clean your DLT so often.
> >  
> > Why you don't use robotic cleaning ??
> >  
> > Disable TapeAlert,AutoClean Veritas, and use
> robotic
> > autocleaning, which is
> > the better, you can trust me.
> >  
> > Hth
> >  
> > F@b
> > 
> > -----Message d'origine-----
> > De : Weber, Philip [mailto:Philip.Weber AT egg DOT com]
> > Envoyé : mardi 18 mars 2003 13:36
> > À : NBUList (E-mail)
> > Objet : [Veritas-bu] Cleaning Frequency
> > 
> > 
> > Hi all,
> >  
> > We are running Netbackup 3.4 with an L700 tape
> robot
> > populated with DLT7000
> > drives.
> >  
> > After running out of cleaning tapes & so not
> > cleaning drives for several
> > weeks, I found that the robot was not complaining
> > about many drives needing
> > cleaning & so investigated.  I found that
> Netbackup
> > was set to clean these
> > every 24 hours which seems far too often - I have
> > upped this to 168 hours
> > for now.
> >  
> > Reading the DLT handbook, it seems to me that we
> > shouldn't be cleaning our
> > drives automatically at all, just manually
> cleaning
> > if a particular problem
> > with a drive.
> >  
> > What do other people do with these drives?
> >  
> > thanks, Phil
> > 
> > Phil Weber 
> > Egg Distributed Hosts - UNIX Systems Engineer 
> > Phone: 01384 26 4136 
> > Mobile: 
> > 
> > -----Original Message-----
> > From: Marianne Van den Berg
> > [mailto:Marianne.VandenBerg AT mgxgroup DOT com]
> > Sent: 03 March 2003 14:13
> > To: NBUList (E-mail)
> > Subject: [Veritas-bu] bpcr_connect timeout during
> > select after 60 seconds
> > 
> > 
> > Hi 
> >  
> > My customer is getting the above message in bpbrm
> on
> > the media server since
> > last night (Everything has been working fine all
> > along).
> > 2 streams are backed up on a W2K client - 1 stream
> > backs up fine, the 2nd
> > fails with code 54 after 1 minute. The timeouts in
> > the media server's
> > bp.conf (Tru64) are as follows : 
> > CLIENT_CONNECT_TIMEOUT = 7200
> > CLIENT_READ_TIMEOUT = 7200
> >  
> > This is a normal scheduled backup. When the
> streams
> > are limited to 1, the
> > backup works fine - it only happens when multiple
> > streams are backed up. 
> > I've checked all the bpclntcmd's between the media
> > server and the client -
> > everything resolves fine. No errors in bpcd log on
> > client (all exit code
> > 0's).
> > (NBU 3.4 patch 4.)
> >  
> > Any ideas about the 60 sec timeout?
> >  
> > Regards
> >  
> > Marianne van den Berg 
> > Senior Support Engineer 
> > MGX Solutions 
> > Tel:  +27 11 695 2064 
> > Fax: +27 11 695 2291 
> > Mobile: +27 82 468 8107 
> > mailto: marianne.vandenberg AT mgxsolutions.co DOT za
> > <mailto:marianne.vandenberg AT mgxsolutions.co DOT za> 
> > This e-mail and attachments relating thereto, is
> > intended for the
> > above-mentioned recipient. If you have received
> this
> > e-mail in error, kindly
> > notify the sender and delete it immediately as it
> > contains information
> > relating to the official business of MGX Solutions
> > (Pty) Limited, which is
> > confidential, legally privileged and proprietary
> to
> > MGX Solutions (Pty)
> > Limited. MGX Solutions (Pty) Limited does not own
> > and endorse any other
> > content. The views and opinions expressed in this
> > e-mail are those of the
> > sender unless clearly stated as being those of MGX
> > Solutions (Pty) Limited.
> > 
> >  
> > 
> > 
> > This private and confidential e-mail has been sent
> > to you by Egg.
> > The Egg group of companies includes Egg Banking
> plc
> > (registered no. 2999842), Egg Financial Products
> Ltd
> > (registered
> > no. 3319027) and Egg Investments Ltd (registered
> no.
> > 3403963) which
> > carries out investment business on behalf of Egg
> and
> > is regulated
> > by the Financial Services Authority. 
> > Registered in England and Wales. Registered
> offices:
> > 1 Waterhouse Square,
> > 138-142 Holborn, London EC1N 2NA.
> > If you are not the intended recipient of this
> e-mail
> > and have
> > received it in error, please notify the sender by
> > replying with
> > 'received in error' as the subject and then delete
> 
=== message truncated ===


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com