Re: [Veritas-bu] Tapeless backup environments?

[McCammont, Anderson (IT)]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Curtis Preston
> Sent: 01 October 2007 06:35
> To: [EMAIL PROTECTED]; veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Tapeless backup environments?
...
> 
> These are odds based on the size of the key space.  If you have 2^160
> odds, you have a 1:2^160 chance of a collision.

by saying that, the implication is that the keyspace is uniform.  It's
not.  The probablity of a hash collision is a function of the uniformity
of the keyspace as well as the number of items you've hashed and the
size of the key.  There's lots of research in the crypto field that's
relevant to de-dupe.

You also should consider the characteristics of the de-dupe software
when it encounters a hash collision.  Backups are the last line of
defence for many, when all else (personal copies, replication, snapshots
etc.) has failed.  The 'acceptable risk' of a hash collision is of
little comfort when you've got one.  Does it fail silently, throw it's
hands in the air and core dump, or handle the situation gracefully and
carry on without missing a beat.  Ask them what they do.  As Curtis
mentioned, not all de-dupe s/ware relies purely on hashes.  

Balance this with the /fact/ that there's already a chance of undetected
corruption in the components you buy today, which is why most
technologies that survive impose their own data validation checks
instead of relying purely on the underlying technology in the stack to
have checked it for them.  The multi-layered checks that go on improve
your overall confidence. 

At least one design in the SiS field also accepts that hashing
algorithms will improve over time and they've had the foresight to be
able to drop in new hashing schemes in future.

When picking de-dupe software you should also care about Intellectual
Property.  Who's got what isn't necessarily clear in this space, and the
patent lawyers won't be far away.  Picking the big boys help here, but
also look at people with a mature view to the marketplace (eg. some
companies are prepared to talk about licensing deals rather than court
cases when they encounter infringement)

There's lots of other things to consider in picking an algorithm,
including how well it handles patterns that don't fall naturaly on block
boundaries (think of the challenges involved in de-duping 'the quick
brown fox' and 'the quicker brown fox') that will affect de-dupe ratios,
and how that affects performance.  And the solution's not just about the
algorithm.

De-dupe is a great advance, and a disruptive technology not just for
backup but also for primary storage.  Look forward to it, but go in with
your eyes open.


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] HP LTO3 media on IBM 800GB LTO3 Tape drive?

[McCammont, Anderson \(IT\)]

http://www.ultrium.com/default.php 

compare who have passed compliance testing (Fuji, Imation, Maxell, Sony
and TDK) who manufacture their own media, with those in the licensee
section.

media fully compatible among compliant companies' media and drives.
Much as anyone hates being treated as a commodity, and th

media RW compatible to n-1 generation and RO compatible n-2 generations.
eg. LTO4 drives will read LTO{2-4} and write LTO{3,4}

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Curtis Preston
> Sent: 13 July 2007 17:56
> To: Martin, Jonathan; Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] HP LTO3 media on IBM 800GB LTO3 Tape drive?
> 
> As I recall, there's actually only two or three companies 
> that actually
> make LTO media, and everybody else just rebrands their tapes. 
>  I forgot
> what the three names were, but I believe that's the case.
> 
> ---
> W. Curtis Preston
> Backup Blog @ www.backupcentral.com
> VP Data Protection, GlassHouse Technologies 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Martin,
> Jonathan
> Sent: Friday, July 13, 2007 7:02 AM
> To: Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] HP LTO3 media on IBM 800GB LTO3 Tape drive?
> 
> 
> I don't presume to be the authority on LTO Media and Drive
> compatibility, but even if I was it wouldn't surprise me that media
> and/or drives from a company called "Wangtek Super 
> Technologies" screwed
> up my environment.  Seriously, don't judge a book by its 
> cover but have
> you been to www.wangtek.com?  It looks more like a used hardware
> reseller than a provider of enterprise class backup hardware.  I know
> back in the day things were different, but between the 
> company name and
> website I'm skeptical.
> 
> For my part I've got drives from HP and Certance working with 
> media from
> HP, Quantum and Fuji with no issues.
> 
> -Jonathan
> 
> PS: If you ever get to Miami, King Computers behind the airport "take
> care of you good." =P  Who needs a brand name, I just got a half price
> hard drive!
> 
> -Original Message-
> From: Jeff Lightner [mailto:[EMAIL PROTECTED] 
> Sent: Friday, July 13, 2007 9:44 AM
> To: Martin, Jonathan; VERITAS-BU@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] HP LTO3 media on IBM 800GB LTO3 Tape drive?
> 
> Not like the old DDS DAT is it?  I remember my frustration between the
> differences in implementation between vendors such as Wangtek and IBM
> when I first started using that.   This was despite the "standards" at
> the time.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Martin,
> Jonathan
> Sent: Thursday, July 12, 2007 5:35 PM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] HP LTO3 media on IBM 800GB LTO3 Tape drive?
> 
> Yes HP Media will work in an IBM drive and visa-versa. LTO is an
> independent hardware standard that all manufacturers must 
> adhere to and
> qualify for.  If you bought name brand media and it didn't work in a
> known working drive from a different manufacturer I'd return 
> that media
> to the manufacturer for a full refund immediately.
> 
> -Jonathan
> 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> hebeonline
> Sent: Tuesday, July 10, 2007 9:44 PM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: [Veritas-bu] Re: HP LTO3 media on IBM 800GB LTO3 Tape drive?
> 
> 
> So that means the IBM LTO3 Drive can even read/write HP LTO3 
> and HP LTO2
> tape but read only for HP LTO1.
> 
> My main concern here is becoz the tape drive is from IBM but the media
> is from HP.
> 
> +-
> -
> |This was sent by [EMAIL PROTECTED] via Backup Central.
> |Forward SPAM to [EMAIL PROTECTED]
> +-
> -
> 
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.

___

Re: [Veritas-bu] 5.1 Oct 2007 End of Support

[McCammont, Anderson (IT)]

My understanding from our Symantec account team is that 3rd Oct 2007 is EOSS 
(End of Service Support?) for 5.1 - ie. no new maintenance packs, EBFs etc.
EOPS (End of Product Support) is 1 Dec 2008
 





From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott 
Jacobson
Sent: 14 May 2007 20:03
To: Simon (external) WEAVER; 'Paul Keating'; 
VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] 5.1 Oct 2007 End of Support


I also believe 5.1 MP4+ is the most rock solid product I've run (less 
DSSU issues) and would prefer to stay on that version and not be forced between 
choosing either 6.0 MP4+ or 6.5 GA

I would suggest for those in the group who are also wanting to wait for 
6.5 MP1+ to contact their Veritas/Symantec SE/Account Mgr's and let them know 
as a customer you're being placed between a rock and a hard place in terms of 
migration choices.
 
In talking with my former RTAM and current local Symantec SE, I'm 
starting to hear they maybe considering the Oct 2007 date as a "soft" and not a 
hard date.
 
Now maybe the time to put our voices behind this and tell them Oct 2007 
end of support for 5.1 is unacceptable.
 
Scott

>>> "WEAVER, Simon (external)" <[EMAIL PROTECTED]> 5/14/2007 8:47 AM >>>

Bit gutted really as I have personally found 5.1 to be rock solid here 
at both my sites!
 
Guess 6.5 is coming sooner than expected now then !?
 

Regards

Simon Weaver
3rd Line Technical Support
Windows Domain Administrator 

EADS Astrium Limited, B23AA IM (DCS)
Anchorage Road, Portsmouth, PO3 5PU

Email: [EMAIL PROTECTED]  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 
Paul Keating
Sent: 14 May 2007 15:42
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Taking the plunge to upgrade from 5.1 
MP4to6.0 MP4



http://ftp.support.veritas.com/pub/support/products/NetBackup_DataCenter/279039.pdf
 
 
-- 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
Behalf Of WEAVER, Simon (external)
Sent: May 14, 2007 9:59 AM
To: 'Forester, Jack L'; 
veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Taking the plunge to upgrade 
from 5.1 MP4to6.0 MP4


can I have confirmation of this please or a web site or 
link ??
 
 

Regards

Simon Weaver
3rd Line Technical Support
Windows Domain Administrator 

EADS Astrium Limited, B23AA IM (DCS)
Anchorage Road, Portsmouth, PO3 5PU

Email: [EMAIL PROTECTED]  




La version française suit le texte anglais.




This email may contain privileged and/or confidential 
information, and the Bank of
Canada does not waive any related rights. Any distribution, 
use, or copying of this
email or the information it contains by other than the intended 
recipient is
unauthorized. If you received this email in error please delete 
it immediately from
your system and notify the sender promptly by email that you 
have done so. 




Le présent courriel peut contenir de l'information privilégiée 
ou confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y 
rapportent. Toute diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il 
contient par une
personne autre que le ou les destinataires désignés est 
interdite. Si vous recevez
ce courriel par erreur, veuillez le supprimer immédiatement et 
envoyer sans délai à
l'expéditeur un message électronique pour l'aviser que vous 
avez éliminé de votre
ordinateur toute copie du courriel reçu.

This email (including any attachments) may contain confidential and/or 

Re: [Veritas-bu] Start NBU non-root

[McCammont, Anderson (IT)]

My point is that if it's your script then you can assess and to an
extent control/mitigate the security exposure, which is much more
preferable to messing with the permissions on other applications which
can expose you further.

You can still run the script in the context of the webserver
(apache/nobody) and use sudo to elevate the permissions of the script
accordingly if necessary to achieve the task at hand.  ie. the CGI
script calls sudo RunMyNetbackupCommand for the commands that require
elevated rights.

Good point on NOM though.  Personally I've no experience of it.

> -Original Message-
> From: Curtis Preston [mailto:[EMAIL PROTECTED] 
> Sent: 14 May 2007 17:28
> To: McCammont, Anderson (IT); Clooney, David; Jeff Lightner; 
> Jones, Courtenay; Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] Start NBU non-root
> 
> Unfortunately, running cgi commands as anything other than nobody or
> apache is also considered dangerous.  
> 
> Sounds like you're screwed either way.
> 
> Have you taken a look at NetBackup Operations Manager?  It allows some
> management functionality via the web.
> 
> ---
> W. Curtis Preston
> Author of O'Reilly's Backup & Recovery and Using SANs and NAS
> VP Data Protection
> GlassHouse Technologies
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> McCammont, Anderson (IT)
> Sent: Monday, May 14, 2007 5:57 AM
> To: Clooney, David; Jeff Lightner; Jones, Courtenay; Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Start NBU non-root
> 
> I'm not sure what you want to achieve, but if you're looking 
> to provide
> a CGI script that exposes some netbackup functionality then 
> I'd suggest
> you  elevate the permissions of your CGI appropriately at the points
> necessary, eg. by running the netbackup commands you care about from
> within your CGI under sudo(8) or somesuch as suggested by another
> poster.  This way Netbackup and Apache stay appropriately permissioned
> and you retain control of the parts of your CGI script that get the
> elevated rights. 
> 
> > -Original Message-
> > From: Clooney, David [mailto:[EMAIL PROTECTED] 
> > Sent: 14 May 2007 13:16
> > To: McCammont, Anderson (IT); Jeff Lightner; Jones, 
> > Courtenay; Justin Piszcz
> > Cc: veritas-bu@mailman.eng.auburn.edu
> > Subject: RE: [Veritas-bu] Start NBU non-root
> > 
> > Much appreciated for your input Anderson,
> > 
> > Can you suggest a better scenario in which you would be able 
> > to run NBU
> > ,master/media server binaries to satisfy the requests 
> > initiated through
> > CGI ?
> > 
> > Dave
> > 
> > -Original Message-
> > From: McCammont, Anderson (IT)
> > [mailto:[EMAIL PROTECTED] 
> > Sent: 14 May 2007 12:55
> > To: Clooney, David; Jeff Lightner; Jones, Courtenay; Justin Piszcz
> > Cc: veritas-bu@mailman.eng.auburn.edu
> > Subject: RE: [Veritas-bu] Start NBU non-root
> > 
> > Really, this is a bad idea.  Putting suid on code that you 
> > don't own or
> > haven't reviewed the source code of is a substantial security 
> > exposure.
> > You're not only not buying yourself anything (the executables would
> > still be running with and effective UID of root), you're 
> also exposing
> > yourself to a large number of other issues - eg. binaries that would
> > have normally run in the user's context are now running as 
> > root, opening
> > yourself up to much more vulnarability.  
> > 
> > If there's any belief that Nebackup is suitably secure that 
> this is an
> > acceptable risk, spend 10 minutes with fuser/lsof + 
> > strace/truss and one
> > will be very suspect of their socket code and handling of file
> > descriptors (in 5.x at least - I can't speak to 6.x, anyone?).
> > Alternatively look at some of the Netbackup security advisories
> > published.  Note, that's for code they're expecting to run as root -
> > you've no idea what you're exposing yourself to elsewhere in the
> > application that you've just opened up.  Symantec wouldn't 
> > condone this
> > practise either I'm sure.   
> > 
> > Sorry for the rant, but you really are better running as root.
> > That said, if all you're interested in is the client portion of
> > Netbackup not running as root, AFAIK it's only using reserved 
> > ports for
> > outbound connections (that you could potentially turn off with
> > CONNEC

Re: [Veritas-bu] Start NBU non-root

[McCammont, Anderson (IT)]

I'm not sure what you want to achieve, but if you're looking to provide
a CGI script that exposes some netbackup functionality then I'd suggest
you  elevate the permissions of your CGI appropriately at the points
necessary, eg. by running the netbackup commands you care about from
within your CGI under sudo(8) or somesuch as suggested by another
poster.  This way Netbackup and Apache stay appropriately permissioned
and you retain control of the parts of your CGI script that get the
elevated rights. 

> -Original Message-
> From: Clooney, David [mailto:[EMAIL PROTECTED] 
> Sent: 14 May 2007 13:16
> To: McCammont, Anderson (IT); Jeff Lightner; Jones, 
> Courtenay; Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] Start NBU non-root
> 
> Much appreciated for your input Anderson,
> 
> Can you suggest a better scenario in which you would be able 
> to run NBU
> ,master/media server binaries to satisfy the requests 
> initiated through
> CGI ?
> 
> Dave
> 
> -Original Message-
> From: McCammont, Anderson (IT)
> [mailto:[EMAIL PROTECTED] 
> Sent: 14 May 2007 12:55
> To: Clooney, David; Jeff Lightner; Jones, Courtenay; Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] Start NBU non-root
> 
> Really, this is a bad idea.  Putting suid on code that you 
> don't own or
> haven't reviewed the source code of is a substantial security 
> exposure.
> You're not only not buying yourself anything (the executables would
> still be running with and effective UID of root), you're also exposing
> yourself to a large number of other issues - eg. binaries that would
> have normally run in the user's context are now running as 
> root, opening
> yourself up to much more vulnarability.  
> 
> If there's any belief that Nebackup is suitably secure that this is an
> acceptable risk, spend 10 minutes with fuser/lsof + 
> strace/truss and one
> will be very suspect of their socket code and handling of file
> descriptors (in 5.x at least - I can't speak to 6.x, anyone?).
> Alternatively look at some of the Netbackup security advisories
> published.  Note, that's for code they're expecting to run as root -
> you've no idea what you're exposing yourself to elsewhere in the
> application that you've just opened up.  Symantec wouldn't 
> condone this
> practise either I'm sure.   
> 
> Sorry for the rant, but you really are better running as root.
> That said, if all you're interested in is the client portion of
> Netbackup not running as root, AFAIK it's only using reserved 
> ports for
> outbound connections (that you could potentially turn off with
> CONNECT_OPTIONS in bp.conf) and if you've got read permission for all
> the files and ask NBU not to update the mtime/atime then I can't think
> what it may need to be root for, though I wouldn't be at all surprised
> to find out that it does.  It may be worth a call to support to
> determine why the client requires root if this is your usage case.
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On Behalf 
> > Of Clooney, David
> > Sent: 14 May 2007 09:47
> > To: Jeff Lightner; Jones, Courtenay; Justin Piszcz
> > Cc: veritas-bu@mailman.eng.auburn.edu
> > Subject: Re: [Veritas-bu] Start NBU non-root
> > 
> > All,
> > 
> > Thanks for everyone's response, I eventually have setuid on 
> > the binaries
> > and changed the group on the binaries to that of the service account
> > being used by apache which all seems to work fine. 
> > 
> > Suppose the downfall and my vulnerability would lie in the 
> > exploitation
> > of netbackup.
> > 
> > Regards
> > 
> > Dave
> > 
> > 
> > 
> > 
> > -Original Message-
> > From: Jeff Lightner [mailto:[EMAIL PROTECTED] 
> > Sent: 11 May 2007 15:21
> > To: Jones, Courtenay; Clooney, David; Justin Piszcz
> > Cc: veritas-bu@mailman.eng.auburn.edu
> > Subject: RE: [Veritas-bu] Start NBU non-root
> > 
> > I think his issue is that a PHB that doesn't understand 
> UNIX/Linux and
> > only (thinks he) knows that "root is bad" is trying to 
> eliminate root.
> > The issue isn't how it is starting but what user it is running as.
> > Since sudo would run it as root he'd still have the same 
> education of
> > PHB to do.
> > 
> > The reason it needs to be root is only root can read ALL 
> files.   Even
> > if it is a master it is assumed it would be backin

Re: [Veritas-bu] Start NBU non-root

[McCammont, Anderson (IT)]

Really, this is a bad idea.  Putting suid on code that you don't own or
haven't reviewed the source code of is a substantial security exposure.
You're not only not buying yourself anything (the executables would
still be running with and effective UID of root), you're also exposing
yourself to a large number of other issues - eg. binaries that would
have normally run in the user's context are now running as root, opening
yourself up to much more vulnarability.  

If there's any belief that Nebackup is suitably secure that this is an
acceptable risk, spend 10 minutes with fuser/lsof + strace/truss and one
will be very suspect of their socket code and handling of file
descriptors (in 5.x at least - I can't speak to 6.x, anyone?).
Alternatively look at some of the Netbackup security advisories
published.  Note, that's for code they're expecting to run as root -
you've no idea what you're exposing yourself to elsewhere in the
application that you've just opened up.  Symantec wouldn't condone this
practise either I'm sure.   

Sorry for the rant, but you really are better running as root.
That said, if all you're interested in is the client portion of
Netbackup not running as root, AFAIK it's only using reserved ports for
outbound connections (that you could potentially turn off with
CONNECT_OPTIONS in bp.conf) and if you've got read permission for all
the files and ask NBU not to update the mtime/atime then I can't think
what it may need to be root for, though I wouldn't be at all surprised
to find out that it does.  It may be worth a call to support to
determine why the client requires root if this is your usage case.


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Clooney, David
> Sent: 14 May 2007 09:47
> To: Jeff Lightner; Jones, Courtenay; Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Start NBU non-root
> 
> All,
> 
> Thanks for everyone's response, I eventually have setuid on 
> the binaries
> and changed the group on the binaries to that of the service account
> being used by apache which all seems to work fine. 
> 
> Suppose the downfall and my vulnerability would lie in the 
> exploitation
> of netbackup.
> 
> Regards
> 
> Dave
> 
> 
> 
> 
> -Original Message-
> From: Jeff Lightner [mailto:[EMAIL PROTECTED] 
> Sent: 11 May 2007 15:21
> To: Jones, Courtenay; Clooney, David; Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] Start NBU non-root
> 
> I think his issue is that a PHB that doesn't understand UNIX/Linux and
> only (thinks he) knows that "root is bad" is trying to eliminate root.
> The issue isn't how it is starting but what user it is running as.
> Since sudo would run it as root he'd still have the same education of
> PHB to do.
> 
> The reason it needs to be root is only root can read ALL files.   Even
> if it is a master it is assumed it would be backing itself up so
> Veritas/Symantec had no reason to write in the ability to run it as
> anything other than root even on a "master only" server.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jones,
> Courtenay
> Sent: Friday, May 11, 2007 9:44 AM
> To: Clooney, David; Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Start NBU non-root
> 
> Could you use sudo functionality? 
> 
> 
> Regards,
> 
>  
> -cj
> Courtenay Jones
> UNIX Systems Engineer, Raleigh Technology Centre
> 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Clooney,
> David
> Sent: Friday, May 11, 2007 5:42 AM
> To: Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Start NBU non-root
> 
> Thanks Justin,
> 
> Well I guess that's that then :-)
> 
> Dave
> 
> -Original Message-
> From: Justin Piszcz [mailto:[EMAIL PROTECTED] 
> Sent: 11 May 2007 10:40
> To: Clooney, David
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Start NBU non-root
> 
> NBU requires root.  End of story really.
> 
> Justin.
> 
> On Fri, 11 May 2007, Clooney, David wrote:
> 
> > Hi all,
> >
> >
> >
> > Scenario:  Linux RD 3 5.1 MP6
> >
> >
> >
> > Does anyone know if its possible to start netbackup as non 
> root? Know
> it
> > sounds strange however this server is used merely for info retrieval
> > from other masters through CGI, currently policy specifies 
> that apache
> > cannot be started as root understandably for security reasons.
> >
> >
> >
> > If I could start NBU as the same user as what apache does, it would
> make
> > my life a lot easier ?
> >
> >
> >
> > Regards
> >
> >
> >
> > Dave
> >
> > This email (including any attachments) may contain 
> confidential and/or
> > privileged information or information otherwise protected from
> > disclosure. If you are not the intended recipient, please notify the
> > sender immediately, do not copy this message or any 
> attachments 

Re: [Veritas-bu] LTO-2 LTO-3 mix

[McCammont, Anderson \(IT\)]

No - changing the media id generation rule (MEDIA_ID_BARCODE_CHARS in
vm.conf) affects the media id.  Changing the barcode rules (potentially)
changes the media type and volume pool.  Existing tapes won't be
reallocated to a new pool on a barcode change - if they did then every
inventory of the library would break netbackup.  vmupdate(1M) only
assigns attributes to new media.
 
If we could put regexps into vmrule e.g.
 
(made up vmrule -listall -b)
barcode  mediavolume max mounts/
tag  type pool cleanings description

--
*CU$ HC2_CLN  None50 LTO Cleaning Tapes
CLN  DLT2_CLN None20 DLT Cleaning Tapes

*L4$ HCART4   Scratch  0 LTO4 media
*L3$ HCART3   Scratch  0 LTO3 media
*L2$ HCART2   Scratch  0 LTO2 media
   DEFAULT  None 0 
DEFAULT  Scratch  0 --


then the world would be a better place.  A trivial code change I'd bet
and a feature request that's been outstanding for several years.
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bobby
Williams
Sent: 25 April 2007 18:21
To: McCammont, Anderson (IT); 'Martin, Jonathan (Contractor)';
'Spearman, David'; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO-2 LTO-3 mix


You can't change the bar code rules like that in mid stream.  It would
change the media id of every tape already in the library and put every
existing tape in scratch.
 
You are going to either have to partition the drives in separate
partitions (Yuk), or just pick your default tape type and add all of the
other types manually (not a big deal).  Existing tapes don't use the bar
code rules anyway, they are already known.  It is only NEW to the robot
tapes that need to have a bar code rule.
 
I have 2 i2K's with both LTO-3 and LTO-2.  No big deal.  I have them in
the same partition.  I use the LTO-3's mostly for tape to tape
duplication for offsite (LTO-2 duplicated to LTO-3 works great).  Most
of the clients can't push data fast enough to feed the LTO-3 tapes.
(Yes, I do multiplex some mid range x3 to feed tapes data).  I use
Staging disks to catch the really slow ones and do disk to tape staging
to the LTO-3 tapes.  If you put the LTO-3's in their own partition, you
could not use any tape duplication between partitions.
 
Another major headache that I have at a site with 2 separate libraries
(both ADIC 1k's) is when one runs out of media, everything fails with 96
errors and then moves to the other physical library.  Not a big issue
until failure stats are looked at.
 




Bobby Williams 
2205 Peterson Drive 
Chattanooga, Tennessee  37421 
423-296-8200 

 


____

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
McCammont, Anderson (IT)
Sent: Tuesday, April 24, 2007 10:24 PM
To: Martin, Jonathan (Contractor); Spearman, David;
veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO-2 LTO-3 mix


If you do this you need to take part of your six digit barcode range and
dedicate it to the particular media type.  
 
It's sad that Netbackup doesn't support proper regexps in the barcode
rules so that the 'L2', 'L3' (presumably) 'L4' last two digits of the
barcode can be used to select the media type.  We've had a feature
request in for years for this and it's gone nowhere (unless 6.x does it
and our rep hasn't mentioned it).
 
  why's there no feedback on feature requests - even when they do
make it into a release you're left to scrabble round to see if it made
it in there.  



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin,
Jonathan (Contractor)
Sent: 25 April 2007 03:42
To: Spearman, David; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO-2 LTO-3 mix


Use barcode rules and media types.  LTO2 media can be hcart2 and LTO3
can be hcart3 (I think hcart stands for Half-Inch Cartridge.)  NBU will
never put a hcart2 tape into an hcart3 tape device.  TO NBU that's as
incompatible as having LTO and DLT in the same library.
 
-Jonathan



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Spearman, David
Sent: Tuesday, April 24, 2007 3:17 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] LTO-2 LTO-3 mix


 

We will be getting an expansion cabinet to our scaler 2000 soon.
At the moment we have LTO-2 drives and tapes. When we add the expansion
cabinet we are also going to add 2 LTO-3 drives with a set of LTO-3
tapes. My question is how do I keep LTO-2 tapes going to LTO-2 drives
while the LTO-3 tapes go o

Re: [Veritas-bu] LTO-2 LTO-3 mix

[McCammont, Anderson \(IT\)]

If you do this you need to take part of your six digit barcode range and
dedicate it to the particular media type.  
 
It's sad that Netbackup doesn't support proper regexps in the barcode
rules so that the 'L2', 'L3' (presumably) 'L4' last two digits of the
barcode can be used to select the media type.  We've had a feature
request in for years for this and it's gone nowhere (unless 6.x does it
and our rep hasn't mentioned it).
 
  why's there no feedback on feature requests - even when they do
make it into a release you're left to scrabble round to see if it made
it in there.  



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin,
Jonathan (Contractor)
Sent: 25 April 2007 03:42
To: Spearman, David; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO-2 LTO-3 mix


Use barcode rules and media types.  LTO2 media can be hcart2 and LTO3
can be hcart3 (I think hcart stands for Half-Inch Cartridge.)  NBU will
never put a hcart2 tape into an hcart3 tape device.  TO NBU that's as
incompatible as having LTO and DLT in the same library.
 
-Jonathan



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Spearman, David
Sent: Tuesday, April 24, 2007 3:17 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] LTO-2 LTO-3 mix


 

We will be getting an expansion cabinet to our scaler 2000 soon.
At the moment we have LTO-2 drives and tapes. When we add the expansion
cabinet we are also going to add 2 LTO-3 drives with a set of LTO-3
tapes. My question is how do I keep LTO-2 tapes going to LTO-2 drives
while the LTO-3 tapes go only to LTO-3 drives. I suspect a combination
of storage units and tape pools but now that we are at NBU6mp4 expired
tapes just return to the scratch pool which would make them available to
anything.
 
present setup
 
W2K3 master/media with sso/ndmp to scaler 2000 (5 tape drives
allowed)
W2K3 media server sso to scaler 2000 and DSSU (4 tape drives
allowed)
W2K3 san media server sso to scaler 2000 
 
David Spearman
County of Henrico


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] iostat not showing tape stats - SLES 9...

[McCammont, Anderson \(IT\)]

Tape device stats aren't currently supported in the Linux distros that
I've seen - the instrumentation isn't there in many of the block device
drivers.  I beleive this is also a limitation on HP/UX and some other
BSD-derived O/S's but I'm not sure on this.
 
If you're using SAN attached tape drives you can pull per port
information from your switches as a workaround, or piece together the
stats from each multiplexed stream over time.
 
Push your vendor to provide patches to enable iostat for block devices,
and to get them incorporated back into the base. 
 

 


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hampus
Lind
Sent: 23 April 2007 16:33
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] iostat not showing tape stats - SLES 9...



Hi all,

 

I can't get any stats from my tape drives on my SLES9 media server with
iostat, I have tried most options to iostat... Is there other way to get
the tape stats? 

 

Thanks and regards,

 

Hampus Lind
Rikspolisstyrelsen
National Police Board
Tel dir: +46 (0)8 - 401 99 43
Tel mob: +46 (0)70 - 217 92 66
E-mail: [EMAIL PROTECTED] 


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Checking to see if millions of files are backed up?

[McCammont, Anderson \(IT\)]

As a colleague of mine once put it: 'BANANA - Backups Are Not Archives,
NOT ARCHIVES'.  Practise this mantra.  You should really think about
rearchitecting.

That said, if your data isn't important to your firm and you're
confident that you can restore from backups (you're making multiple
copies, probably not using removable media but if you are you're doing
full media verifies and sending them out the building to different
offsite facilities in different directions using different carriers
right?), and you're looking at this as an interim poor man's one-way HSM
(you know your data access patterns and want to keep things around on
disk as long as possible but manage your primary storage), then you
could 'trust' your backup app, find the last successful backup date at
the appropriate retlevel contains the file you want, and the script that
you trigger when your filesystem utilisation gets to a certain point is
free to remove anything before that date.  No, I wouldn't do that
either.  

The point is that you're either comfortable in your backup app or you're
not, and if you're not you can't get out of doing anything other than
reading the tape.  If you trust your backup app but not bparchive you
can get your backup app to dump a filelist.  If that's millions of files
and impacts on other uses of your backup plant then that's something you
need to deal with.

Alternatively, if you're not prepared to trust bparchive, or it's not
timely enough for you (I've never had occasion to use it so can't
comment on either point), you could always generate your own filelist
that you use to take the regular backup, check the success of the backup
and if it worked 'bless' the filelist.  Then at some point in the future
when you get into space pressure you can purge files in the blessed
filelists.  Be careful though to only bless fully successful backups
(not partials - think locked files etc), but this really falls into the
category of trusting the backup application, and hence becomes a
circular argument.  I'd be more inclined to test bparchive rather than
engineer my own, but remember, BANANA.


Separate solutions for separate problems:
Stretched HA for hardware failure/Disaster Recovery
CDP/Snapshots/Backups for User Error
Archives for Data Retention


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin
Piszcz
Sent: 27 March 2007 06:17
To: Whelan, Patrick
Cc: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Checking to see if millions of files are
backed up?

A nice idea; however, this is actually part of a much larger and
complicated system in which certain files have to kept for certain
retentions, both on disk and backed up to tape, think tape archival
with different retention rates.  If I were to change the entire
architecture behind it, this may be a good solution and is something
on my plate for the future.  However, in the interim, I just need a
solution to verify files have been backed up to tape and remove them
if they are older than N days if we are running low on space on any
particular server.

On 3/26/07, Whelan, Patrick <[EMAIL PROTECTED]> wrote:
> Why not have a script that runs a backup followed by an archive. Check
> the error code of the backup, if is not 0 then don't run the archive.
If
> it is 0 then run the archive which will automatically delete the files
> when it completes successfully. It will not delete antything if it
fails
> even with a 1.
>
> Regards,
>
> Patrick Whelan
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Justin
> Piszcz
> Sent: 26 March 2007 22:36
> To: [EMAIL PROTECTED]
> Cc: Veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Checking to see if millions of files are
> backed up?
>
>
> The problem with that is two-fold:
>
> 1. We backup multiple copies of the data, therefore, the archive
option
> will not work. 2. What if a tape has an I/O error half way through the
> archive process? Yikes.
>
> Justin.
>
> On 3/26/07, Bobby Williams <[EMAIL PROTECTED]> wrote:
> > Why not set up an archive schedule?  That way, the files can be
> > archived and NetBackup will ensure that they are on tape before
> > removing.
> >
> >
> >
> >
> > Bobby Williams
> > 2205 Peterson Drive
> > Chattanooga, Tennessee  37421
> > 423-296-8200
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
Justin
>
> > Piszcz
> > Sent: Monday, March 26, 2007 4:27 PM
> > To: Veritas-bu@mailman.eng.auburn.edu
> > Subject: [Veritas-bu] Checking to see if millions of files are
backed
> > up?
> >
> > If one is to create a script to ensure that the files on the
> > filesystem are backed upon before removing them, what is the best
> > data-store model for doing so?
> >
> > Obviously, if you have > 1,000,000 files in the catalog and you need
> > to check each of those, you do not want to bplist -B -C -R 99
> > /path/to/file/1.txt for each file.  However, y

Re: [Veritas-bu] Drive Cleaning Frequency for SSO Drives

[McCammont, Anderson \(IT\)]

NBU will clean on two tapealerts - 20+21 CLEAN_NOW and CLEAN_PERIODIC.
Check your drive firmware release notes though to make sure there's no
tapealert issues in the rev you're running.  There was a fix in 5.1MP4
to handle edge conditions that meant tapealerts could go unactioned.  

If you have IBM 3584's you need 5.1MP6 (IIRC, maybe MP5) for NBU to play
nicely with library based cleaning (ie. graciously handle the situation
when NBU wants to put a tape in the drive and there's a cleaning cart in
there - prior releases could result in mount timeouts)

Frequency based cleaning on SSO is a pain - you need to determine how
much time was clocked on each media server in the SSO environment - NBU
doesn't do this for you (in 4.x and 5.x minimally), you need to script
it yourself if you cant use tapealert or library cleaning.

Regards

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Kerrivan
Sent: 16 March 2007 02:10
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Drive Cleaning Frequency for SSO Drives

NB will only clean when the TapeAlert flag CLEAN_NOW is passed - there's
a technote about TapeAlert on the Symantec site. You might have to dig
for it - look under DataCenter, not Enterprise.

You need the library Vendor to instruct you on how to change this at the
library, some like Quantum, let you do it yourself, others will come
out, and change the appropriate bit in a controller. Then you make sure
you have properly defined cleaning media with cleanings left in the
library, and set the frequency for cleaning to 0 hours (tpclean will
show you how) or do it via the GUI.

No one recommends a time based cleaning nowadays because the newer drive
technology is self cleaning, and the cleaning tapes are essentially
abrasive, and will result in more frequent drive replacements, not to
mention ultimately unreadable tape.


 
...
 
David Kerrivan  |  Senior Technical Support Specialist  
Kanatek Customer Support
Tel:  1.800.526.2823  |  Fax: 613.591.1488
Support: [EMAIL PROTECTED]
KTI Kanatek Technologies Inc.  |  www.kanatek.com
535 Legget Drive, Suite 400, Kanata, Ontario, K2K 3B8 Canada
...


-Original Message-
From: Hindle, Greg [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 2:03 PM
To: David Kerrivan; veritas-bu@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Drive Cleaning Frequency for SSO Drives

 
Good point, never thought that netbackup did not know when the drives
were being cleaned. This explains allot! I have Storagetek L700 robots
and use hardware based cleaning. How can I switch this to get netbackup
to clean the drives after xx hours of use? 


Greg

Greg 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David
Kerrivan
Sent: Thursday, March 15, 2007 1:22 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Drive Cleaning Frequency for SSO Drives

Actually, flip that around.
Library based cleaning can cause NB to down drives if it tries to mount
a tape in a drive being cleaned by the robot. The robot doesn't tell NB
that it's cleaning the drive, so NB thinks the resource is avail,
discovers it's not, and downs the drive.

If you have a "dirty" environment and enough drives do this, you could
be faced with your backups not succeeding in their window. 

Of course, with Tape Alert (supported by pretty much all vendors) you do
have to keep an eye on your cleaning tapes so that they don't run out
and that is a manual process. (job security :-) )

David Kerrivan

 

-Original Message-
From: Mike Kiles [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 11:55 AM
To: Ellis, Jason; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Drive Cleaning Frequency for SSO Drives

Frequency based cleaning is not supported on SSO drives. Preferred
methods are in order of preference:

1. Library based cleaning
2. Tape Alert

Cheers

MK
--- "Ellis, Jason" <[EMAIL PROTECTED]>
wrote:

> Is there a why to specify the cleaning frequency on SSO drives? The 
> cleaning frequency setting under Device Monitor, accessed by 
> right-clicking on the drive and selecting Drive Cleaning > Set 
> Cleaning Frequency, is grayed out on all our SSO drives.
> Additionally there does
> not seem to be a way to change the attributes of the tape drive to 
> specify a cleaning frequency from the Change Drive dialogue box for 
> our SSO drives.
> 
>  
> 
> What is the recommended procedure for setting drive cleaning frequency

> on SSO tape drives? Have the library perform this function? Or do we 
> need to remove and re-add all out tape drives to specify the cleaning 
> frequency when first added?
> 
>  
> 
> Jason Ellis
> Technical Consultant, Data Protection Team IndyMac Bank, La Mirada 
> Datacenter
> Phone: (714) 520-3414
> Mobile: (714) 889-8734
> 
>  
> 
> > 

Re: [Veritas-bu] LTO3 Read/Write LTO2

[McCammont, Anderson \(IT\)]

Yes, we'd like to define relationships between media types too.  
 
I also want barcode tags that take regexps instead of just the first n chars of 
the label.  LTO media has L2,L3 etc. as the last 2 chars, I'd like to use that 
to determine whether it's hcart2, hcart3 media instead of having to derive it 
from some other part of the barcode namespace.  
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keating
Sent: 19 December 2006 14:53
To: Dave Brown; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO3 Read/Write LTO2


you got it.
 
You've got to configure it as the same "density", ie hcart2, as your 
existing drives and media.
 
I would LOVE to see Netbackup implement a proper hierarchical density 
structure to match the common drive types on the market, so it would 
automatically know that an LTO3 drive can read and write LTO2 media, and read 
LTO media.
 
Paul
 
 
-- 
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 
Dave Brown
Sent: December 19, 2006 9:29 AM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] LTO3 Read/Write LTO2


Well,  My boss just got me a new LTO3 drive to put in my 
library.  I asked for an LTO2 as I already have 2 of these in the lib and 100's 
of tapes but I have one nonetheless

The lib sees the drive as does NetBackup but it says that there 
are no tapes available...barcode reader I'm sure.  

Is there a way to make the LTO3 use the LTO2 tapes and write to 
them at the proper density ?

I tried changing the type to hcart2 as my others are but it did 
not take.  I may have to restart services but have to wait for some jobs to 
finish.  Figured I'd throw it up to the group while I wait.

NetBackup 6.0 MP4
Windows 2003
Quantum 1500 lib
 
 
This message (including any attachments) is intended for the 
sole use of the individual to whom it is addressed and may contain confidential 
information. You are hereby notified that any dissemination, distribution, or 
duplication of this message by someone other than the intended addressee or 
their designated agent is strictly prohibited. Information included in this 
message that does not relate to the specified business of Worknet shall be 
understood as neither given by nor endorsed by Worknet or its employees.  Any 
cost estimates or estimated quotes included in this message are considered 
non-binding estimates only and must not be considered final costs unless 
contained within an official proposal document. 



La version française suit le texte anglais.




This email may contain privileged and/or confidential information, and 
the Bank of
Canada does not waive any related rights. Any distribution, use, or 
copying of this
email or the information it contains by other than the intended 
recipient is
unauthorized. If you received this email in error please delete it 
immediately from
your system and notify the sender promptly by email that you have done 
so. 




Le présent courriel peut contenir de l'information privilégiée ou 
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute 
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il 
contient par une
personne autre que le ou les destinataires désignés est interdite. Si 
vous recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer 
sans délai à
l'expéditeur un message électronique pour l'aviser que vous avez 
éliminé de votre
ordinateur toute copie du courriel reçu.


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Query remote drives

[McCammont, Anderson \(IT\)]

You could use 'vmoprcmd -h mediaserver -autoconfig -t' 
Unsupported, may change/stop working across versions etc. etc.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Clooney,
David
Sent: 07 November 2006 17:31
To: Greenberg, Katherine A
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Query remote drives

Quick Idea, what do you all think ?

It would appear that retrieving device names and serial numbers remotely
can't be done through NBU so what about setting up a scheduled job on
each windows media server to run every 5 mins or so to run tpautoconf -t
, output it into the desired format and then bpgp the file into an
allocated area on the master, the master then has the relevent info it
needs. 

Question now is can drives be added remotely from the master on the
remote media server's? If not subject closed.

Regards

Dave

-Original Message-
From: Greenberg, Katherine A [mailto:[EMAIL PROTECTED]
Sent: 06 November 2006 17:40
To: Clooney, David
Subject: RE: [Veritas-bu] Query remote drives

I have a script that does vmoprcmd -h  that I can run
from any master against any media server...

I'm all UNIX, tho... not sure if it will work on Windows.

~Kate 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Clooney,
David
Sent: Monday, November 06, 2006 11:38 AM
To: Austin Murphy
Cc: Whelan, Patrick; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Query remote drives

Thanks Austin

 /usr/openv/volmgr/bin/scan -all locally supplys the info however I am
tryiing to gather the same info remotely from the master.

Dave

-Original Message-
From: Austin Murphy [mailto:[EMAIL PROTECTED]
Sent: 06 November 2006 16:33
To: Clooney, David
Cc: Whelan, Patrick; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Query remote drives

On 11/6/06, Clooney, David <[EMAIL PROTECTED]> wrote:
> Yeah I know of the below, what I'm trying to achieve is putting a
script together to check drives  across the SSO environment and
re-organise accordingly by adding/deleting as necessary. To do this I
would need serial number info on the drives per media server in order to
add them correctly  into the SSO env.
>
> Any ideas would be grateful.

   vmglob -listall -java

This reads the globDB and shows the serial number (and other info) of
each drive connected to each media server.I think your goal of
rearranging the drives actually changes the globDB so this may not suit
you.

This will show you everything on your SCSI/FibreChannel buses attached
to your Solaris master server.  It includes serial numbers.

  /usr/openv/volmgr/bin/scan -all

Austin



Notice to recipient:
The information in this internet e-mail and any attachments is
confidential and may be privileged. It is intended solely for the
addressee. If you are not the intended addressee please notify the
sender immediately by telephone. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted to
be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in
this internet e-mail are subject to the terms and conditions expressed
in any applicable governing terms of business or client engagement
letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America,
N.A., London Branch and Banc of America Securities Limited are
authorised and regulated by the Financial Services Authority.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

-
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna




Notice to recipient:
The information in this internet e-mail and any attachments is
confidential and may be privileged. It is intended solely for the
addressee. If you are not the intended addressee please notify the
sender immediately by telephone. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted to
be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in
this internet e-mail are subject to the terms and conditions expressed
in any applicable governing terms of business or client engagement
letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America,
N.A., London Branch and Banc of America Securities Limited are
authorised and regulated by the Financial Services Authority.

___
Veritas-bu maillist  -  Veritas-bu@

RE: [Veritas-bu] Bpsched crashing

[McCammont, Anderson \(IT\)]

Title: Bpsched crashing




if you have a hang, truss bpsched main and see 
whether it's blocked doing a msgsnd().  Do the ipcs -qA and look for CBYTES 
being close to QBYTES.  If it is truss the rest of the bpscheds and see if 
any are attempting to do a msgrcv().
 
Increasing the queue varies depending on OS release.  
For Sol 9 check http://docs.sun.com/app/docs/doc/806-7009/6jftnqsjp?a=view.
msgsys:msginfo_msgtql  is the pertinant one for sol9 iirc.  
msgsys:msginfo_msgmnb and others used to be relevant on previous 
versions.
 
Apparently the 
message passing routines have been reworked in NBU6 - I haven't seen this 
myself, but it would be welcome as they're sorely in need of 
it.
 


  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Hindle, 
  GregSent: 15 May 2006 15:06To: Len Boyle; 
  veritas-bu@mailman.eng.auburn.eduSubject: RE: [Veritas-bu] Bpsched 
  crashing
  
  We had the shared memory setting set to use all available 
  memory and were told by Symantec to lower that figure to 6 gig and 
  leave 2 gig for Solaris 9 (we jave 8 gig ram). We have not adjusted 
  any msg queues. Where would I look and what should 
  they be? 
   
  Greg
  
  
  From: Len Boyle [mailto:[EMAIL PROTECTED] 
  Sent: Monday, May 15, 2006 9:48 AMTo: Hindle, Greg; 
  veritas-bu@mailman.eng.auburn.eduSubject: RE: [Veritas-bu] Bpsched 
  crashing
  
  Good Morning Greg, 
   
  Have you changed setting in the /etc/system file to 
  increased things such as shared memory and msg queues? 
   
  len
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Hindle, 
  GregSent: Monday, May 15, 2006 9:04 AMTo: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] Bpsched 
  crashing
  
  Nb 5.0 mp6 Solaris 9 
  We are having an on going issue with bpsched 
  crashing/stopping. When this happens all the jobs go 150. Sometimes it 
  recovers and restarts the jobs and other times we have to stop and start the 
  services. Has any one else had this issues and what you did to fix? We have a 
  open ticket with Symantec and they have recommend some tuning changes, which 
  we have done, but it still went down over the weekend. Symantec thinks it is a 
  resource issue. We have 8 gig of ram in the master server and it seems to 
  crash most often about 15 minutes in the main backup window. We would have 
  around 200 jobs running, with 800 queued. This has not been an issue in the 
  past. Any ideas?
  Greg >>> This e-mail and any attachments are confidential, may contain legal, professional or other privileged information, and are intended solely for the addressee.  If you are not the intended recipient, do not use the information in this e-mail in any way, delete this e-mail and notify the sender. CEG-IP1




NOTICE: If received in error, please destroy and notify sender.  Sender does not waive confidentiality or privilege, and use is prohibited.