[Veritas-bu] Thanks

[Weber, Philip]

Ladies and Gents,

As I'm changing jobs & moving out of the NetBackup world for a while, I
just wanted to say thanks for the sharing of information, advice and
help on this list.  And good luck with the "interesting times" ahead!

cheers, Phil
-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] ZFS Filesystem Backups - Tips and tricks

[Weber, Philip]

Thanks for highlighting this problem to the list, as we for one hadn't
even picked up that our zfs filesystems were no longer backing up.  We
now have the engineering binaries, and our account manager at Symantec
has kindly chased up the TechAlert which should have been issued.

cheers, Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark
Glazerman
Sent: 06 August 2008 22:20
To: [EMAIL PROTECTED]; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] ZFS Filesystem Backups - Tips and tricks

Fixed !!...

Symantec have outdone themselves (strange to say I know !!).
Engineering created two binaries to replace the bpbkar and bpmount files
in /usr/openv/netbackup/bin.  Once this was done I was able to
successfully backup ZFS filesystems on my test box with ALL_LOCAL_DRIVES
as the only backup selection.  No need to specify all the possible zfs
filesystems on all clients in the policy as I had been doing.  The real
test will come tonight when the policy will try and kick off proper but
I'm confident that they've fixed our issue without the need for
upgrading everything to 6.5.2 !!

Anyone who's had similar issues is advised (by engineering) to contact
support and to reference technote 303000
(http://seer.entsupport.symantec.com/docs/303000.htm) and ask to be sent
the engineering binaries that ARE available.  The binaries appear to
work on both 6.5 and 6.5.1 clients (at least they are on our systems).

Just thought I'd update everyone on a successful resolution to a very
annoying issue.

Mark Glazerman
Desk: 314-889-8282
Cell: 618-520-3401
P please don't print this e-mail unless you really need to

-Original Message-
From: bob944 [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 04, 2008 3:02 PM
To: veritas-bu@mailman.eng.auburn.edu
Cc: Mark Glazerman
Subject: RE: [Veritas-bu] ZFS Filesystem Backups - Tips and tricks

> I didn't say that Exclude lists don't work for directories.  
> I said that Include lists don't work for directories.  [...]

No.  Include lists work exactly the same way as exclude lists;
directories and/or files are valid.  Reference the Veritas NetBackup
System Administrator's Guide, Vol I for syntax rules.

This misunderstanding might be attributed to way the *_list rules are
applied.  Note that an exclude list can only exclude items that are in
the policy's selection list (obviously).  And that an include list can
only include items that were excluded by an exclude list.  (Perhaps
that's the logic in Symantec renaming the include list to "exceptions to
the exclude list.")  Stated another way, the selection list defines the
universe of data to be backed up.  Excludes subtract from the universe.
Includes reinstate only items from the set of excluded items.

You can see the processing steps in the client's bpbkar log.  Logging
level 0 will show each directive as it is encountered; level 1 and
higher will show the process more clearly via the PrintFile lines.  From
that I can infer the reason the rules are as they are (above):  bpbkar
processes the selection list and only mentions exclude_list items when
they match its current path; include_list entries are only mentioned
when they match the current exclude_list item.

___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas

Re: [Veritas-bu] ZFS Filesystem Backups - Tips and tricks

[Weber, Philip]

Urgh.  He's right, at least we are seeing this as well.  FWIW our zfs
filesystems backed up fine when we were running NetBackup version 5.1.
 
Our Advanced Client setup has been broken since we upgraded to 6.5.1 as
well :-(
 
Thanks for the heads up ... I haven't seen a Techalert for this.
 
cheers, Phil



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark
Glazerman
Sent: 01 August 2008 14:34
To: Veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] ZFS Filesystem Backups - Tips and tricks



Incase anyone is considering implementing any ZFS in their environment
which they want to back up using NetBackup we found out yesterday that
ALL_LOCAL_DRIVES as the backup selection does NOT cover ZFS filesystems.


 

We have a number of Sun boxes which have various test and development
oracle instances which are housed inside ZFS file systems.  We blew away
one of these test instances the other day (after doing a full OS backup
and the required RMAN backups) but when we went to restore the data from
the ZFS filesystems, NBU didn't have anything under the uppermost
directory.  A quick check of other systems with ZFS showed the same
issue.We spent the better part of 2 days playing around with the
include_list's and exclude_list's but nothing worked. 

 

In order to backup ZFS file systems you must explicitly add the ZFS
directories into the backup selections of the backup policy.  This "fix"
was also confirmed by Symantec support who were also happy to tell me
that ZFS isn't officially supported by NBU yet.

 

This on its own should work great if you have a single policy backing up
a single server with all it's ZFS under the same parent directory.
However, if like us, you have a backup policy which backs up multiple
servers, each with their own uniquely named ZFS file systems, you need
to get a bit creative.  

 

The policy in question backs up 15 Sun boxes  with a total of 6
differently named ZFS file systems spread amongst them.  If you just
list the file systems in the backup selections, NBU looks for each of
those different filesystems on each server and spits out an error code
71 (None of the files in the file list exist) for every directory it
can't find.  The only way we could work out to avoid these errors (and
there were a lot of them) was to create every missing directory on every
server and then touch a tiny file inside each of these directories.  Now
when the policy runs, it sees each directory (as listed in the backup
selection) on each server and doesn't moan about anything.  Perhaps not
the neatest of fixes but it works.

 

Apologies for the wordy post, just thought I'd put this info out there
in case anyone else is moving towards ZFS.

 

Mark Glazerman

Enterprise Storage Administrator

Spartech Corporation

Desk: 314-889-8282

Fax: 314-854-8282

Cell: 618-520-3401

[EMAIL PROTECTED]  

http://www.spartech.com  

P please don't print this e-mail unless you really need to

This e-mail and any files transmitted with it are confidential, are
intended solely for the use of the addressee, and may be legally
privileged. If you have received this email in error please notify the
sender immediately, and do not copy or forward it.

 



-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] UNIX Commands for Controlling SL48 StorageTek LibraryOPS

[Weber, Philip]

Is mtx any use to you (http://freshmeat.net/projects/mtx/).  We use this
with a StorageTek L700 and Bacula. 

regards, Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jonafc
Sent: 01 July 2008 17:49
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] UNIX Commands for Controlling SL48 StorageTek
LibraryOPS


I have looked everywhere for CLI UNIX lower level commands outside of
the backup software (Networker). To interrogate this type of Jukebox,
that's import/export tapes, list tapes loaded in drives and slots.
control slot to drive operations, inventory and so forth .. 

Anybody out there in the know?

+--
|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
-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Advanced Client

[Weber, Philip]

If you are using an existing media server, then you just need an
Advanced Client licence (NetBackup 5.1, as of 6+ now called Snapshot
Client I believe).

Phil 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
dmdelfini
Sent: 18 June 2008 15:04
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] Advanced Client


Does anyone know if backups over the SAN can be configured using just
the Advanced Client or does it also require a Media server license.
Thanks

+--
|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
-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NetBackup silently filters MS SQL datafiles w/oany warning

[Weber, Philip]

Sounds similar to this
http://seer.entsupport.symantec.com/docs/290900.htm which is definitely
a case of "scary".  Seems like there is a problem with the way MS DFS
Replication shares interacts with NetBackup.  I don't do Windows either
but my MS colleagues assure me that there is nothing "funny" about the
filesystems that NetBackup is "choosing" not to back up.  Personally I
think the fault likes with Microsoft/Windows though for telling
NetBackup not to back them up.  The end result is the same though
"scary".  I'd rather NetBackup got told about everything and I had to
sort out the code 1s and take responsibility for deciding what not to
back up.

cheers, Phil


Phil Weber MBCS CITP
Storage Technical Services - Senior UNIX Technologist
Business Technology

Phone: 01384 26 4136

Egg Banking plc

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of bob944
Sent: 21 April 2008 23:37
To: veritas-bu@mailman.eng.auburn.edu
Cc: [EMAIL PROTECTED]
Subject: Re: [Veritas-bu] NetBackup silently filters MS SQL datafiles
w/oany warning


> We encounter a stange thing with NetBackup as it backs up MS 
> SQL files on some of Windows hosts.
>  
> There are puzzling info messages in bpbkar.log on some 
> NetBackup clients: 
> 6:13:46.708: [7200.3120] <2> tar_base::V_vTarMsgW: INF - 
> Filtered 'Shadow Copy Components' Object: 
> D:\mssql\data\MSSQL\Data\master.mdf

I don't do Windows, but will take a stab at this:  isn't the log entry
clearly saying "this widget is backed up by Shadow Copy?"

You are doing a shadow copy components backup of your w2k3 systems,
correct?

> Even though NetBackup warns that it skips certain files, the 
> backup job finishes sucessfully (with zero status code).

Status 0 is correct.  It's a filesystem backup and it backed up all the
files and directories in the filesystem that it is supposed to.  

> It looks as if NetBackup silently filters certain files 
> without notifying an administrator about that. Till now we 

It handled it exactly the same way NetBackup handles excluded files:
recognizes it isn't _supposed_ to back it up (because Microsoft has
apparently categorized it as requiring Shadow Copy and says a filesystem
backup of it isn't good and/or useful for recovery) and puts a note in
the log so that a sharp admin can see it as you have and fully account
for everything on the system.

> supposed that as soon as Netbackup comes across a MS SQL file 
> it either backs it up if the file is closed or skips it and 
> ussues a warning in job log if the file stays open at the 
> moment of backup. In the latter case backup job finishes with 
> status code 1 (partial backup). 

Rather, it skips an open file if the writing process has acquired an
exclusive write lock (no readers allowed) or if OTM/VSP/VSS couldn't
capture a consistent image of the volume.  But this is neither case.

You might want to look at the FilesNotToBackUp key that Microsoft
populates with files they do not want you to back up.  There are MSKB
articles on this key and probably a lot on Shadow Copy as well.


___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Storage unit groups are not understood - yesI'mpuzzeld

[Weber, Philip]

Is this definitely correct?  I was under the impression that it would
join the storage unit unless there were already 4 streams from that
schedule already, i.e. that it would mpx higher than the schedule limit
so long as it was with streams from other policies.

I guess I should test this all out again, I have to admit that I did
test it once until I understood it but it's got muddled in my mind again
:-(

> i.e. a schedule with an mpx setting of 4 will not join a storage unit
> with Max Drives = 1 and Max MPX = 10 that's got 5 streams running,
even
> though the storage unit can take 5 more streams. 

cheers, Phil

Phil Weber MBCS CITP
Storage Technical Services - Senior UNIX Technologist
Business Technology

Phone: 01384 26 4136

Egg Banking plc

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tharp,
Trey
Sent: 29 April 2008 04:46
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Storage unit groups are not understood -
yesI'mpuzzeld

What's the multiplexing # set to on the schedule? Also, "Allow multiple
data streams" is checked on the policies, right?

You can have an unlimited number of policies using a storage unit group
as far as I know. We've got well over 100 policies using a storage unit
group with 2-4 storage units in it and we run over 1000 active jobs to
this storage units.

There are many enablers and limits for multiplexing and multistreaming
that all have to be turned on and turned up for it to work. The lowest
denominator is on the schedule itself, so if a new stream starts, it
will not join a mpx group that's got more jobs active than what it's set
to.

i.e. a schedule with an mpx setting of 4 will not join a storage unit
with Max Drives = 1 and Max MPX = 10 that's got 5 streams running, even
though the storage unit can take 5 more streams.

-Trey

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of fred
fred
Sent: Saturday, April 26, 2008 4:22 AM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Storage unit groups are not understood - yes
I'mpuzzeld

In the relms of the Top 20 (or so) misunderstood specifically #2.
Storage unit groups are not understood.  (version = 6.5.1)

I'm still puzzled. If you have policies pointing to the same storage
group with two policies running with the a couple of streams each.  Then
a third starts it ends up by queueing.  The only difference being its
not NT Windows but a Standard Unix policy.
Rentetion time and media pool the same.

Can only a limited number of Policies actually use the storage group at
any one time, even if the retention time and tape pool the same?

Does the same apply  for storage units?

If you have  a stroage unit like below I would expect you could have two
policies writng to it at the same time (with no queueing ) as long as
there less than a total of 10 streams. Policies with media multiplexing
of 10 and same retention and pool.

Storage Unit:
Multiplexing enabled
Maximum concurrent write drives: 1
Maximum streams per drive: 10
I have set it to one as I don't what to multistream to more that two
tapes drives in the storage unit group.

Storage Unit Group (set to "balance load" ) has two storage units of the
above i.e a max of 20 streams i.e it will do twice the work load
of my example  I'm assuming each stream is a "job".   In the manuals
what is a "job" seems to change with context.

Max client streams = 24 (for slow backups of small servers)

Am  I missing anything?

Cheers Fred
___
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
-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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 a

Re: [Veritas-bu] Master Server on a SUN Thumper?

[Weber, Philip]

We've using Clariion Cx300 with ATA drives for disk staging and
performance is awful; seems to deteriorate over time.  Currently RAID5
LUNs (tried RAID3 which had similar performance and even tested RAID0
which wasn't noticeably better).  I'm assuming the performance issue is
that with lots of different types of backups going to the array, we're
making them jump all over the place, but haven't really found a way of
improving it.




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Lightner
Sent: 14 April 2008 18:31
To: Ed Wilts; Jim Horalek
Cc: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Master Server on a SUN Thumper?



Actually we have some quite large (2TB+) Oracle Test/Trng databases
using ATA drives in a Clariion CX700 arrays and get decent performance
out of those.   Of course that is hardware RAID.   Not sure what the SUN
Thumper uses.

 

The database on NBU is relatively small by comparison though at the
moment we do still have ours on EMC Symmetrix (DMX3) but that is more
for the warm fuzzy we get from Symmetrix reliability.

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts
Sent: Monday, April 14, 2008 12:44 PM
To: Jim Horalek
Cc: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Master Server on a SUN Thumper?

 

On Mon, Apr 14, 2008 at 10:22 AM, Jim Horalek <[EMAIL PROTECTED]>
wrote:

Just as an aside, how many people are building Master servers on
SATA?


The master server is one big flat-file database.  Why would you want it
on SATA?  I don't imagine that many database operations are going to any
fun at all...

You could, on the other hand, put a DSSU or DSU on your master on SATA
but that would be providing media server functionality, not master
server functionality.  I'd be okay with doing that (and am doing it
here).



-- 
Ed Wilts, Mounds View, MN, USA
mailto:[EMAIL PROTECTED] 

--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
confidential information and is for the sole use of the intended
recipient(s). If you are not the intended recipient, any disclosure,
copying, distribution, or use of the contents of this information is
prohibited and may be unlawful. If you have received this electronic
transmission in error, please reply immediately to the sender that you
have received the message in error, and delete it. Thank you.
--



-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

[Weber, Philip]

If you're lucky enough to have a configuration management or asset
management system, you may be able to find a way to report on all the
servers that you aren't backing up, then you can hassle the admins who
have created those servers.  It's still not foolproof, as you end up
with a list of servers with "reasons" why they don't need to be backed
up ... and anyway, who maintains the configuration management system
(sigh) ... but it is another layer of protection for your back ;-)



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stuart
Liddle
Sent: 09 April 2008 22:41
To: Haskins, Steve; Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU



I think it all depends upon what you want to achieve.  I personally
don't have a problem with seeing status code 1's and ignoring them, but
some people don't like to see them which is why I suggested the exclude
lists.  BUT, it must be understood that the people responsible for those
servers are responsible for the exclude lists that are on them.  If
admins outside of the backup/restore group know this, then they are the
ones that are responsible for whether or not a file is getting backed
up.

 

Take that a step further...yes, you are responsible for recovery.  But,
if you are NOT told about a new server being added and given a specific
request to back it up (and what to back up on that server), then how can
YOU be responsible for its recovery?  Ultimately, the recovery depends
upon what the backup/restore team is TOLD about by the people who
administer the servers & appsyou can't read people's minds.

 

--stuart

 



From: Haskins, Steve [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 09, 2008 2:17 PM
To: Stuart Liddle; Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

 

  I agree with verifying with the application support techs on what
files are being skipped and how to address them as they are responsible
for their applications but as the backup and operating system
administrator I am held accountable for recovery. I don't like exclude
lists especially if it is just to make the reports look good for status
0. I have found that in too many cases an exclude list in created and
then another administrator or application support tech will make a
change and now important files are being skipped that shouldn't be. If
coordinated correctly with procedures and documentation this should not
be the case but there is still the reliance upon human intervention to
follow procedures and to document.

 

Regards

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stuart
Liddle
Sent: Wednesday, April 09, 2008 1:40 PM
To: Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

 

Yesvery true.  What I recommend doing is to check all backups
against a new client the first few times and see what is causing the
partial success.  Checking with the application support people on what
files are OK to skip is always a good idea and will definitely eliminate
problems in the future.  Then use this information to build an exclude
list for the client.

 

I used to treat databases as a special case for backups since they are
so temperamental.  I would do SQL databases by having the SQL DBA's do
their own backup of the db to the local filesystem (or a network share).
Then we would have the DBA's put together an exclude list for their SQL
servers to exclude the active DB files.  Then we would schedule our
backup jobs for a time AFTER the SQL local  backups.  Never had to worry
about restoring SQL DB's after that.   But, testing database restores is
very critical to ensuring that you are backing up the right thing(s).
And you definitely need the assistance of the DBA's for this.

 

-stuart

 



From: Jeff Lightner [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 09, 2008 1:31 PM
To: Stuart Liddle; VERITAS-BU@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

 

I'd amend point 3 to say "does NOT ALWAYS mean".  

 

There are many OS and filesystem level backups that are complete despite
status 1.   However, having a status 1 on a database backup can be a
real killer...

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stuart
Liddle
Sent: Wednesday, April 09, 2008 3:52 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

 

I think I would agree with all of what Ed has stated here.  However, I
think that these points would apply to ANY backup product and not just
NBU.

 

Since the question was about the "top 20 (or so) misunderstood things
about NBU", I'd have to ad

Re: [Veritas-bu] Failing Oracle Rman Backup

[Weber, Philip]

Make sure your NetBackup patch levels match between the master/media and
the client.  Check firmware levels on network cards / hba's throughout
the system.
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of rascal
Sent: 13 February 2008 16:51
To: Michael Graff Andersen
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Failing Oracle Rman Backup


This error message seems incomplete; can you please see if there are
more details.  Perhaps see where RMAN is piping out the log files?  A
couple of base things you may wish to check:

1.  Space:  Are you running out of space wherever your oracle
datafiles/logfiles/redo/tmp/etc... are stored?
2.  Media:  Do you got enough scratch?  Do you have enough in your tape
pool?
3.  Permissions:  Do you have the correct permissions (i.e. is the right
user running the job(s))?

Also, we could use more information on your environment to resolve this.
Please let us know when you get a minute some more detail like version
numbers, master/media details, how the db is setup to work with rman and
how rman is setup to work with netbackup.  Thanks!


On Wed, Feb 13, 2008 at 12:58 AM, Michael Graff Andersen
<[EMAIL PROTECTED]> wrote:


Hi

If it is a unix client you may need to recreate the link from
oracle
to the relevant netbackup libobk

Regards
Michael

2008/2/13, Karani, Mohamed <[EMAIL PROTECTED]>:

>
> Would some please shed some light how to address intermittent
failures on a
> Rman Oracle Backup.
>
> The client server has been reinstalled with netbackup and
network checked
> out.
>
> Below is the error:
>
>
>
> Below is the extract of backup error or Devmint
>
>
>
>
>
> channel ORA_SBT_TAPE_1: specifying datafile(s) in backupset
>
> input datafile fno=1
> name=/oracle/OraHome1/oradata/devmint/system01.dbf
>
> input datafile fno=00012
> name=/oracle/OraHome1/oradata/devmint/FNB_FLOW1.dbf
>
> input datafile fno=00010
> name=/oracle/OraHome1/oradata/devmint/xdb01.dbf
>
> input datafile fno=3
> name=/oracle/OraHome1/oradata/devmint/cwmlite01.dbf
>
> channel ORA_SBT_TAPE_1: starting piece 1 at 11-FEB-08
>
> RMAN-00571:
> ===
>
> RMAN-00569: === ERROR MESSAGE STACK FOLLOWS
===
>
> RMAN-00571:
> ===
>
> RMAN-03009: failure of backup command on ORA_SBT_TAPE_1
channel at
> 02/11/2008 19
>
> :05:13
>
> ORA-19506: failed to create sequential file,
name="/demint_bk_q7j8fcck_1_1",
> par
>
> ms=""
>
> ORA-27028: skgfqcre: sbtbackup returned error
>
> ORA-19511: Error received from media manager layer, error
text:
>
>VxBSACreateObject: Failed with error:
>
>Server Status:  cannot connect on socket
>
>
>
>  Mohamed S.Karani
>
>  Storage Management
>
> Cell :  079 523 4020
>
> Tel:  011 889 4728
>
> Fax:011 889 4679
>
>
> Email:   [EMAIL PROTECTED]
>
> "Quality is never an accident; it is always the result of high
intention,
> sincere effort, intelligent direction and skillful execution;
it represents
> the wise choice of many alternatives."
>
>
>
>
> To read FirstRand Bank's Disclaimer for this email click on
the following
> address or copy into your Internet browser:
> https://www.fnb.co.za/disclaimer.html
>
>
>
> If you are unable to access the Disclaimer, send a blank
e-mail to
> [EMAIL PROTECTED] and we will send you a
> copy of the Disclaimer.
>
>

> ___
> 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





-- 
Matthew MCP, MCSA, MCTS, OCA
[EMAIL PROTECTED]

Define Trouble: 
Why did you apply THAT patch?? 


-
Egg is a trading name of the Egg group of companies which includes:
Egg Financial Intermediation Ltd (reg no 3828289) and Egg Banking
plc (reg no 299984

Re: [Veritas-bu] Lets hear about your upgrade experience! 5.x - 6.5

[Weber, Philip]

We upgraded our environment a couple of weeks ago, from 5.1 to 6.5.1.
Follow the instructions, and make sure you have a call open with
Symantec well in advance so you can run all the database consistency
checks and pass the results back and forth to Symantec to resolve any
issues with media - we went through several cycles of this.  This
environment is Solaris 9 / Solaris 10 with 1 master and 4 media servers,
2 Spectralogic libraries with LTO2/LTO3 tapes & encryption.  Solaris &
Windows clients.
 
Issues during the upgrade :

*   
Still had problems with some LTO1 tapes imported from a previous
environment.  Easily resolved with a call to Symantec.
*   
Couldn't automatically upgrade the Solaris clients without going
to them all to create a symlink for gzip and gunzip, easily resolved but
a bit naff.
*   
Ongoing issues with Advanced Client where I can't get the
snapctl driver to work at all (Solaris).  See separate posting.

thanks, Phil
 


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WEAVER,
Simon (external)
Sent: 04 March 2008 15:35
To: Tony T.; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Lets hear about your upgrade experience! 5.x -
6.5


Id be interested to hear if anyone had a plan of action from any NBU
upgrade - I will be doing 5.1 to 6.5.1
 
Si



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony T.
Sent: Tuesday, March 04, 2008 3:32 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Lets hear about your upgrade experience! 5.x - 6.5


Hi all,

I am interested in hearing about any of the upgrades that you have done,
mainly going from 5.x to 6.5  
There seem to be quite a few environments (in my area) that are looking
to upgrade, and I am putting together some documentation
that asks questions to better prepare for it.  I am still learning the
ropes of NBU but I have a lot of experience with the server side
of things especially Sun and AIX systems with SAN storage.  

I have the Symantec upgrade guide "Upgrading to Veritas Netbackup 6.5"
and it appears to be pretty detailed, but it just covers the steps to
get from point A to point B.
Some of the things I am interested in finding out:

- is there anyway to estimate how long step X might take?  I realize
that there are so many variables that  it is not possible to say
"popluating the EMM will take X hours" but
if enough people chime in on what their experience was like, maybe we
can come up with  an average

- have there been any show stoppers that were unanticipated?  We could
all learn from this, knowing what questions to ask up front based on our
past...er...challenges.  NBU has so many options and is such a broad
product that I doubt any two environments are identical. 


Just sort of brain storming here, looking forward to hearing (seeing?)
what you all have to share.  If we get a good dialog going I will
attempt to compile it into something usable
and post it back here. 

T.



-- 
  )
 (
  )
[_]) 
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 and do not use
it
for any purpose or disclose its content to any person, but delete this
message and any attachments from your system. Astrium disclaims any and
all
liability if this email transmission was virus corrupted, altered or
falsified.
-
Astrium Limited, Registered in England and Wales No. 2449259
REGISTERED OFFICE:-
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England


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

Re: [Veritas-bu] NBU 6.5.1 Solaris Client Install

[Weber, Philip]

Ah yes, sorry I am a twit :$ I should have worked that out.  Time for a
break from this particular task I think.
 
Back to sorting out our disk staging which went a bit pear-shaped during
the install.
 
thanks, Phil
 

Phil Weber MBCS 
Storage Technical Services - Senior UNIX Technologist 
Business Technology 

Phone: 01384 26 4136 
Mobile: 07748 333503 
Jabber: [EMAIL PROTECTED] 

Egg Banking plc 

 



From: Ed Wilts [mailto:[EMAIL PROTECTED] 
Sent: 30 January 2008 19:41
To: Weber, Philip
Cc: VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 6.5.1 Solaris Client Install


You're pushing out a custom tarball anyway so edit client_config before
you do.  At the top of the script, add /usr/local/bin to PATH and you
should be okay.

I checked a couple of random systems here and a Solaris 10 system has
/usr/bin/gunzip and a Solaris 9 system had  /usr/bin/gunzip -> gzip.
Other Solaris 9 and 10 systems had the link to /usr/local/bin/gunzip.
I'm not sure what the real story is there or if our admins aren't being
very consistent in how/where gunzip is being made available...

   .../Ed


On Jan 30, 2008 12:42 PM, Weber, Philip <[EMAIL PROTECTED]> wrote:


And another thing! 

Both the update_clients and update_dbclients fail because they
can't find gunzip in the PATH on the client, saying PATH is set to
/usr/bin:/usr/sbin.  Gunzip is in /usr/local/bin.  I've tried setting
the path in /etc/profile, /.profile, /.kshrc but currently to no avail
and have had to bodge it by creating a symlink /usr/bin/gunzip on each
client for the duration of the upgrade.

Does anyone know a way around this?  Or am I missing something. 

Solaris 9 clients, Solaris 9 master.  (Our Solaris10 servers are
OK, having /usr/bin/gunzip). 

thanks,  Phil 


-- 
Ed Wilts, Mounds View, MN, USA
mailto:[EMAIL PROTECTED] 


-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5.1 Solaris Client Install

[Weber, Philip]

And another thing!

Both the update_clients and update_dbclients fail because they can't
find gunzip in the PATH on the client, saying PATH is set to
/usr/bin:/usr/sbin.  Gunzip is in /usr/local/bin.  I've tried setting
the path in /etc/profile, /.profile, /.kshrc but currently to no avail
and have had to bodge it by creating a symlink /usr/bin/gunzip on each
client for the duration of the upgrade.

Does anyone know a way around this?  Or am I missing something.

Solaris 9 clients, Solaris 9 master.  (Our Solaris10 servers are OK,
having /usr/bin/gunzip).

thanks,  Phil

> Phil Weber MBCS
> Storage Technical Services - Senior UNIX Technologist
> Business Technology
> 
> Phone: 01384 26 4136
> Mobile: 07748 333503
> 
> Egg Banking plc
> 


-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 6.5.1 Solaris Client Install

[Weber, Philip]

OK I've pretty much sorted this, but the client install is HUGE even
with the Java directory stripped out.  Talk about bloatware!

Surely, for example, these don't need to be on every client?!

$ ls -rlt /usr/openv/lib/vxfi/providers/
total 81392
-r-xr-xr-x   1 root bin  2218424 Nov 16 17:24
libemcclariionfi.so
-r-xr-xr-x   1 root bin  1425712 Nov 16 17:24 libdevicefi.so
-r-xr-xr-x   1 root bin  2665604 Nov 16 17:24 libemcsymfi.so
-r-xr-xr-x   1 root bin  1827668 Nov 16 17:24 libibmtsfi.so
-r-xr-xr-x   1 root bin  1801884 Nov 16 17:24 libhpevafi.so
-r-xr-xr-x   1 root bin  1152444 Nov 16 17:24 libvxfsfi.so
-r-xr-xr-x   1 root bin  1850656 Nov 16 17:24 libvxvmfi.so
-r-xr-xr-x   1 root bin  1060532 Nov 16 17:24 libgfspfi.so
-r-xr-xr-x   1 root bin  5958928 Nov 16 17:24 libnetappfi.so
-r-xr-xr-x   1 root bin  1020112 Nov 16 17:24 librawprtfi.so
-r-xr-xr-x   1 root bin  1369452 Nov 16 17:24 libdevicefiST.so
-r-xr-xr-x   1 root bin  2169512 Nov 16 17:24
libemcclariionfiST.so
-r-xr-xr-x   1 root bin  1748848 Nov 16 17:24 libhpevafiST.so
-r-xr-xr-x   1 root bin  2616792 Nov 16 17:24 libemcsymfiST.so
-r-xr-xr-x   1 root bin  1769652 Nov 16 17:24 libibmtsfiST.so
-r-xr-xr-x   1 root bin  1776000 Nov 16 17:24 libvxvmfiST.so
-r-xr-xr-x   1 root bin  1122440 Nov 16 17:24 libvxfsfiST.so
-r-xr-xr-x   1 root bin  1030620 Nov 16 17:24 libgfspfiST.so
-r-xr-xr-x   1 root bin   964540 Nov 16 17:24 librawprtfiST.so
-r-xr-xr-x   1 root bin  5879916 Nov 16 17:24 libnetappfiST.so

> _ 
> From:     Weber, Philip  
> Sent: 25 January 2008 15:20
> To:   'VERITAS-BU@mailman.eng.auburn.edu'
> Subject:  NBU 6.5.1 Solaris Client Install
> 
> For NetBackup 4.5 - 5.1 we had a script which let us install Solaris
> clients from a central admin server (not a NetBackup server).  This
> was because we have firewalls between the servers and clients, can't
> use ftp, can't ssh between the master and clients, etc.  So our script
> :
> 
> hacked the client ftp_to_client script (e.g. under
> client/Solaris/Solaris9) to copy the files locally to the master and
> build an image.
> scp the image back to the admin server
> scp the image over to the client
> run client_config within the transferred image, to install the client.
> 
> I can't remember where I got the idea/process for this originally but
> I'm sure it was a "standard" workaround, though the script is mine.
> Unfortunately it looks like the scripts have all changed now we've
> upgraded to 6.5.1.  Does anyone know if a similar process is possible
> or documented, while I wade thought the scripts trying to re-write
> mine?  I know there are options to transfer the client files via
> sftp/ssh now, but these still won't work for us.
> 
> Master/media :  Solaris 9 NBU 6.5.1.
> Clients :  Solaris 8/9/10.
> 
> thanks, Phil
> 
> 
> Phil Weber MBCS
> Storage Technical Services - Senior UNIX Technologist
> Business Technology
> 
> Phone: 01384 26 4136
> Mobile: 07748 333503
> 
> Egg Banking plc
> 


-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] NBU 6.5.1 Solaris Client Install

[Weber, Philip]

For NetBackup 4.5 - 5.1 we had a script which let us install Solaris
clients from a central admin server (not a NetBackup server).  This was
because we have firewalls between the servers and clients, can't use
ftp, can't ssh between the master and clients, etc.  So our script :

hacked the client ftp_to_client script (e.g. under
client/Solaris/Solaris9) to copy the files locally to the master and
build an image.
scp the image back to the admin server
scp the image over to the client
run client_config within the transferred image, to install the client.

I can't remember where I got the idea/process for this originally but
I'm sure it was a "standard" workaround, though the script is mine.
Unfortunately it looks like the scripts have all changed now we've
upgraded to 6.5.1.  Does anyone know if a similar process is possible or
documented, while I wade thought the scripts trying to re-write mine?  I
know there are options to transfer the client files via sftp/ssh now,
but these still won't work for us.

Master/media :  Solaris 9 NBU 6.5.1.
Clients :  Solaris 8/9/10.

thanks, Phil


Phil Weber MBCS
Storage Technical Services - Senior UNIX Technologist
Business Technology

Phone: 01384 26 4136
Mobile: 07748 333503

Egg Banking plc



-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] "piece handles" in Oracle RMAN backups..what are t

[Weber, Philip]

If you're using Advanced Client backups (proxy copy for Oracle), you'll
get straight filenames for the datafiles, and some pieces (Oracle RMAN
"pseudo" filenames) for the logs, control files etc.  (This is for NBU
5.1 which is the only version for which I have experience of proxy copy
backups).

I guess if you have written your RMAN script to do both proxy copy and
"normal" backups, you would get something like this - 2 backups of the
data effectively.

cheers, Phil


Phil Weber MBCS 
Storage Technical Services - Senior UNIX Technologist
Business Technology

Phone: 01384 26 4136
Mobile: 07748 333503
Jabber: [EMAIL PROTECTED]

Egg Banking plc

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: 23 January 2008 23:37
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] "piece handles" in Oracle RMAN backups..what
are t

That seems strange, I'm not sure you should have straight filenames from
RMAN, at least on a hot backup, just pieces.  Is this a cold image? 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Chris_Millet
Sent: Wednesday, January 23, 2008 11:37 AM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] "piece handles" in Oracle RMAN backups..what are t


Ok, but if I build a list from the file lists in each job submitted to
the master server during the RMAN backup, I will already have a list of
all of the actual data files PLUS a bunch of these piece handle files.
The total size is almost 2x the actual database like it is backing up
the entire thing twice.

+--
|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
-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] The NBU FAQ needs you

[Weber, Philip]

I'm about to upgrade to 6.5.1.  Probably also about to be made
redundant; so perhaps I can blame that on 6.5.1 :-O
 
I'm happy to help out with the FAQ.
 
cheers, Phil
 

Phil Weber MBCS 
Storage Technical Services - Senior UNIX Technologist 
Business Technology 

Phone: 01384 26 4136 
Mobile: 07748 333503 
Jabber: [EMAIL PROTECTED] 

Egg Banking plc 

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WEAVER,
Simon (external)
Sent: 23 January 2008 06:45
To: Randy Samora; Curtis Preston; VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] The NBU FAQ needs you


Divorced because of upgade to 6? Gosh, what will happen when going to
6.5 :-)
Saying that, I am not married, but due to be. so maybe I should hold
off the upgrade to 6.5 for another year ;-)
 
Si.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Randy
Samora
Sent: Wednesday, January 23, 2008 4:16 AM
To: Curtis Preston; VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] The NBU FAQ needs you



Curtis (as if we've known each other for years),

 

I'd be interested in hacking at the outdated FAQ's.  I've been
on NetBackup since 3.4, certified on 5, and divorced because of the
upgrade to 6.  Besides, I think it would be a great way to brush up on
the basics again by finding the answers to the questions I don't know.
If you think I could be of assistance, sign me up.

 

Thanks,

Randy

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curtis
Preston
Sent: Tuesday, January 22, 2008 4:47 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] The NBU FAQ needs you

 

Are you the type of person on this list that ANSWERS questions
more than

you ask them?  If so, the NetBackup FAQ needs you.  I don't want
to call

out any names, but you know who you are.

 

It's hosted on my site, backupcentral.com, and is WOEFULLY out
of date.

(I think it MIGHT have some 4.5 stuff in it, but that's about
it.)  It

can be found at the following URL:

 

http://tinyurl.com/yqff7j

 

I will be glad to help, but most of you use NBU much more
frequently

than I do, so the answers are better coming from YOU.

 

If you're interested, please reply to this message and I'll tell
you how

to get started.  Even one or two updated questions are worth a
lot to

the thousands of users that are perusing the FAQ for answers.

 

 

---

W. Curtis Preston

Backup Blog @ www.backupcentral.com

VP Data Protection, GlassHouse Technologies

 

 

___

Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu

http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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 and do not use
it
for any purpose or disclose its content to any person, but delete this
message and any attachments from your system. Astrium disclaims any and
all
liability if this email transmission was virus corrupted, altered or
falsified.
-
Astrium Limited, Registered in England and Wales No. 2449259
REGISTERED OFFICE:-
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England



-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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

Re: [Veritas-bu] Backups only writing to one storage unit groupmember

[Weber, Philip]

I'm not sure what you mean.  Doesn't "df" show how full the DSSU is?  Or
do you mean how "full" as in what % remains to be staged to tape?
 
I wrote my own disk staging script for NBU 4.5 which uses bpimmedia to
list all details of all images in the DSSU & then takes a minute or 2 to
check the status of each, i.e. disk only / disk & tape / various error
statuses.  Not what you'd want to run every 5 mins, but not too bad.
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts
Sent: 15 January 2008 12:37
To: Weber, Philip
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Backups only writing to one storage unit
groupmember


On Jan 15, 2008 5:35 AM, Weber, Philip <[EMAIL PROTECTED]> wrote:



I understand disk staging to be much improved in 6.5.1 & so am
hopeing
to get upgraded in the next month or so. 

 
It has certainly gotten better in each release.  5.1 wasn't all that
great, 6.0  was pretty good, and I don't think we've seen any issues at
all yet with 6.5.1.
 
My only complaint with the upgrade from 6.0 to 6.5.1 is that the .ds
files are no longer being created when an image has been destaged.  We
used that in our scripts to determine how "full" a DSSU really was.  Now
I believe the only way to do it is to look up each image in the catalog
and that takes a *LOT* longer - it's no longer practical to scan the
DSSUs every 5 minutes. 
 
   .../Ed

-- 
Ed Wilts, Mounds View, MN, USA
mailto:[EMAIL PROTECTED] 


-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Backups only writing to one storage unit group member

[Weber, Philip]

In our experience :
 
DSSUs don't work in Storage Unit Groups at NBU 5.1 as NBU isn't clever
enough to handle one unit being full and move onto another.  Having said
that, it shouldn't fail jobs when the DSSU is 100% full unless it hasn't
found any old images which can be expired from disk (because they are on
tape).  So it sounds like maybe there is a problem with your staging
jobs.

I have had problems with staging jobs where there has been some kind of
I/O error on the disk unit, which has caused the staging job to fail,
but NBU has not recovered the job nor cancelled it, so another job never
started (and the error wasn't picked up).

I understand disk staging to be much improved in 6.5.1 & so am hopeing
to get upgraded in the next month or so.

cheers, Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave
Lowenstein
Sent: 14 January 2008 19:05
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Backups only writing to one storage unit group
member

I'm on netbackup 5.1 mp4 on solaris.

I set up some storage unit groups using disk staging storage units 
(dssus). Backups that point to these groups are only writing to the 
first member in the storage unit group, there's nothing being written to

the second storage unit.

The first storage unit is 100% full as a bunch of staging jobs haven't 
completed yet, but at least one backup so far has failed due to no 
space, even though the second member of the storage unit group is 
sitting there with plenty of space.

After I created the storage unit groups I bounced the daemons.

What am I missing here?
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Sun compatible h/w and floating point

[Weber, Philip]

Not sure what you mean by "if floating point is required".  There are
compatibility matrices for OS & libraries on support.veritas.com.  We
are running NetBackup 5.1 on Sun T2000s and v880s.

cheers, Phil 


Phil Weber MBCS 
Storage Technical Services - Senior UNIX Technologist
Business Technology

Phone: 01384 26 4136
Mobile: 07748 333503
Jabber: [EMAIL PROTECTED]

Egg Banking plc

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of cavadif
Sent: 09 January 2008 16:17
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] Sun compatible h/w and floating point


Where can I find documentation per NetBackup compatability with server
hardware.  In particular, Sun (Solaris) servers.  I need to know if
floating point is required?  Is anyone running NetBackup on a Sun T1000,
T2000, 490, or 890?

+--
|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
-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] )([EMAIL PROTECTED])*(&@# Symantec Support

[Weber, Philip]

Interesting, I had that problem (with the restore) and gave up in the
end & did the database migration in a different way, didn't log a call,
tut tut...
 
I always find the support split between a pita getting to the right
people, then when you get a good engineer, they are fantastic.
 
Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin,
Jonathan
Sent: 06 September 2007 16:02
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] )([EMAIL PROTECTED])*(&@# Symantec Support


/rant on
 
So I'm working a Netbackup / Oracle support issue whereby we're having
trouble restoring an Oracle database from a full backup (RMAN keeps
asking for incremental tapes we don't have.)  The Support guy suggests
we backup the control file, database and archive logs in a different
order to solve the problem.  My DBA Runs this by Oracle and they agree
so we make the configuration change, run the backup, and then that
restore hangs after restoring the control files.  The Symantec tech
tells me now I've got a new issue and that I need to open a new ticket
because he's closed the original one!  I can't believe I pay for this as
"support!" _(*  &[EMAIL 
PROTECTED]&%_#@&%)@%#
 
/rant off
 
-Jonathan



-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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 does 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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tape encryption

[Weber, Philip]

Anybody any experience of Spectralogic's library-based encryption?  We
are about to start out no implementing this - basically the encryption,
and optionally compression, is carried out in the fibre cards in the
library.  We will be using LTO2 and LTO3 drives.
 
I have some concerns around impact on performance and media usage
especially with having to move the compression from the tape drives to
the library, and 101 questions for the supplier around key management
processes & procedures.
 
Doesn't seem as good as the Decru option, for one thing Decru as I
understand it is NetBackup-aware; I don't think Spectralogic is, so we
have to partition the library if we don't want to encrypt everything.
 
regards, Phil
Phil Weber 
Storage Technical Services - Senior UNIX Technologist 
Business Technology

Phone: 01384 26 4136 
Egg Banking plc 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cruice,
Daniel (US - Glen Mills)
Sent: 05 September 2007 21:33
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Tape encryption



Looking for some information regarding tape encryption, anyone out there
using it?  And if so what kind of tape degradation did you experience.
We are being asked to implement it and we are just trying to figure out
what we are going to need.  Our environment is mixed with Windows and
UNIX, all of our NBU servers are Windows (Master and Media) with a 20
drive LTO3 Library, over 900 clients.  About 90% of our environment is
running 6.0 MP4 and soon will be rolling out 6.5 w/ MP1.  Any gotchas we
need to be aware of.



Thanks

Dan







 
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and is
protected by law. If you are not the intended recipient, you should
delete this message and are hereby notified that any disclosure,
copying, or distribution of this message, or the taking of any action
based on it, is strictly prohibited. 



-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] VERITAS backup for Solaris zones

[Weber, Philip]

We install the NetBackup client in the global and local zones, i.e. we
back up the local zones locally as they will have the knowledge of their
application/DB status.  We don't use loopback filesystems in the local
zones for our data filesystems, we either use devices exported from the
global to local zones, or global filesystems mounted directly into local
zone.  Use of loopback filesystems may be causing your write protect
errors?
 
We use a bpstart_notify script to check for duplicate filesystems
between the global and local zones, and alert if any are found that
aren't in one or other exclude list.  This script also, when it runs in
the global zone, dumps out the zone configs to a flat file for backup as
part of the global zone backup.  Restore of whole server or zones should
be possible using the zone config dumps, and local zone backups.
 
All this seems a bit clunky but is the best way I've found for us, so
far.
 
cheesr, Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Day
Sent: 17 August 2007 20:38
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] VERITAS backup for Solaris zones



I ran into write protect errors when I tried to install the Solaris
client on some zones.  When I discussed this with the admin these were
his questions.  

 

Can someone answer them for me please?

 

Thanks,

Mike Day

 

"We need to know how to backup and restore a Solaris 10 server
configured with multiple non-global zones.

 

* How to install the client global zone

* How configure the backup job for the global and non-global
zones

* How to restore a zone/configuration on original or replacement
servers"

 

 



-
Egg is a trading name of the Egg group of companies which includes:
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:
Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] bpdbjobs -all_columns

[Weber, Philip]

I've got a script which I was going to post after checking it for
site-specific stuff, but I think the page at that link is far more
comprehensive!

Phil

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Dave Markham
> Sent: 20 July 2007 12:26
> To: Justin Piszcz
> Cc: Clooney, David; veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] bpdbjobs -all_columns
> 
> 
> I haven't got a script but you may find this useful
> 
> http://www.backupcentral.com/components/com_mambowiki/index.ph
p/How_do_you_decipher_the_output_of_%22bpdbjobs_-report_-all_columns%22%
3F



Justin Piszcz wrote:
> On Fri, 20 Jul 2007, Clooney, David wrote:
>
>   
>> Hi All
>>
>>
>>
>> Does anyone have some perl code, that they wouldn't mind sharing,
that
>> chops up  bpdbjobs -report -all_columns, with filelist count , number
of
>> tries etc,?
>>
>> 
>
> After field 31 its difficult to calculate if anyone has something like

> this I would be interested as well.
>
> Justin.
> ___
> 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

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] retentions

[Weber, Philip]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Ed Wilts
> Sent: 20 July 2007 01:29
> To: 'Brandon Zermeno'; Veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] retentions

> What we have actually done here is to push the failures back on to the
> server admins.  *EVERY* day that a backup fails, they get a 
> ticket generated
> by our Help Desk that they have to do something with.  So 
> your job is to

Now I'm jealous!  I still haven't managed to swing this - we
(storage/backup support) still get all these tickets.

> On top of this, we generate an "overdue" report every day.  
> It's not 100%
> accurate (it is really, really hard to duplicate the scheduler's
> calculations!), but it gives us a good idea as to what's 
> going on.  If we
> see that a full backup is overdue for too long, we investigate.

I'd like to do this as well.  We've got good reporting on
failures/successes but nothing clever yet that categorises the failures
in terms of "overdueness" or "jeopardy".

cheers, Phil

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] ALL_LOCAL_DRIVES not working?

[Weber, Philip]

I've had this issue where there's a problem with connectivity (e.g.
firewall) between the master and the client, but the (different) media
server and the client can talk to each other correctly.  It's like the
master can't query the client to find out what filesystems need backing
up, but the actual backup of what it knows can take place between the
client and media server.  Check port connectivity and check for timeout
messages in the bpsched (I think) log.  I'm using 5.1 MP5 though.

Phil

Phil Weber
Business Technology (Egg)
Storage Technical Services - Senior UNIX Technologist
Phone: 01384 26 4136


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Darren Dunham
> Sent: 17 July 2007 22:28
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] ALL_LOCAL_DRIVES not working?
> 
> 
> > Is there anyway to see how's responding to or processing the bpmount
> > information coming in from the client?
> 
> It's been a while since I did that.  If you turn on verbose 
> logging, one
> of the log files shows the retreival of the mounts and then the
> selection of the filesystems.  I'd probably look at bpcd on 
> the client,
> but I've forgotten which one on the server is most relevant here.
> 
> I assume you've already run bpmount -i on the client to 
> verify it looks
> reasonable?
> 
> -- 
> Darren Dunham   
> [EMAIL PROTECTED]
> Senior Technical Consultant TAOS
> http://www.taos.com/
> Got some Dr Pepper?   San Francisco, 
> CA bay area
>  < This line left intentionally blank to confuse you. >
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Windows flash-backup experiences (again)

[Weber, Philip]

I back up ALL_LOCAL_DRIVES using the cluster name, and ensure local
drives (only C: for us) are excluded.  Then back up C: only on the
individual nodes.  It's still a pain managing exclude lists; from time
to time someone changes the policy names which messes the exclude lists
up and we start getting duplicate backups.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of tburrell
> Sent: 11 July 2007 15:50
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: [Veritas-bu] Re: Windows flash-backup experiences (again)
> 
> 
> 
> 
> Leidy, Jason D wrote:
> > I backup ALL_LOCAL_DRIVES on a few of our clusters, it gets 
> everything.
> > For instance, I'll put both physical nodes that host the 
> cluster in a
> > policy that uses the ALL_LOCAL_DRIVES option. I'm new to the backup
> > world, is this not the best practice? It gets the quorum 
> and everything
> > (I'm able to restore the data).
> > 
> > Jason
> > 
> > 
> > Attached original message stripped from forum post
> 
> 
> Jason- you're kind of right- it will get everything, but at 
> the cost of lots of errors and problems down the line.  Since 
> Windows servers are still aware of drives that are owned by 
> the other nodes in the cluster, ALL_LOCAL_DRIVES will cause 
> Netbackup to try and back up disks which are not accessible 
> from the current node, and that will generate errors.  In 
> addition, every time a drive fails from one physical node to 
> another it's seen as needing a new full backup (assuming it's 
> been gone longer than the backup interval).  Plus- when you 
> want a restore, you have to figure out which node owned the 
> drive that day.  Not a problem in a small shop perhaps, but 
> get 3 or 4 decent size file clusters running for a year or so 
> and things quickly get out of hand.
> 
> Best practice (although it's a pain, I'll admit) is to use 
> the virtual node name, and specify the drives owned by that 
> cluster group.  The trick here then is to make sure that your 
> Windows Admins don't add/move drives without telling you.  
> The upside is: fewer bogus errors, and the backups follow the 
> disks around on the cluster maintaining your catalog continuity.
> 
> Tom
> 
> +-
> -
> |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
> 

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Windows client problem after MP7 update

[Weber, Philip]

Exactly the symptoms we were getting.

GUI --> master properties --> Client Attributes --> "Windows Open File
Backup" tab (naming may be different for v5.0, I can't remember now).

> -Original Message-
> From: Dave Markham [mailto:[EMAIL PROTECTED] 
> Sent: 06 July 2007 11:11
> To: Weber, Philip
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Windows client problem after MP7 update
> 
> 
> Thanks. Tried excluding *.wci and they are still behaving strangely. I
> haven't had this message as yet but they seem to get to different
> Percentages each time and then just grind to a halt.
> 
> On the Gui i cant see how to disable open file backup either for the
> client properties. There is a VSP item but that only says 
> "setting will
> only take place if vsp is installed"
> 
> Anyone know how i can turn off open file backups then for 
> these clients?
> From other environments i support i can just disable the OTC (i think)
> stuff.
> 
> Cheers
> 
> 
> 
> 
> Weber, Philip wrote:
> > Hi, we've been getting the same problem with 5.1 MP6.  See
> > http://seer.support.veritas.com/docs/247062.htm.
> >
> > My colleague has been working on this, it looks like with the
> > bpstart|end_notify scripts in place as described and the Content
> > Indexing service set to Manual (ours was disabled by a 
> security policy),
> > the problem is resolved.
> >
> > regards, Phil
> >
> > Phil Weber
> > Business Technology (Egg)
> > Storage Technical Services - Senior UNIX Technologist
> > Phone: 01384 26 4136
> >
> >
> >   
> >> -Original Message-
> >> From: [EMAIL PROTECTED] 
> >> [mailto:[EMAIL PROTECTED] On Behalf 
> >> Of Dave Markham
> >> Sent: 05 July 2007 17:36
> >> To: veritas-bu@mailman.eng.auburn.edu
> >> Subject: [Veritas-bu] Windows client problem after MP7 update
> >>
> >>
> >> Guys i have just updated our Netbackup 5.0 environment to 
> MP7. Master
> >> server is Solaris9. All stuff was fine with upgrade but now 
> >> some of the
> >> windows clients dont seem to backup correctly.
> >>
> >> They get a portion of the way through and then this message 
> >> appears and
> >> they grind to a halt until i cancel them
> >>
> >> bpbrm from client : WRN - Content Indexing Server: 
> >> unable to pause catalog: Web (some files may not get backed up)
> >>
> >>
> >> Anyone seen this before? No configuration has changed other than
> >> applying MP7.
> >>
> >> Clients are Windows2000 servers which were fine before.
> >> Thanks
> >> ___
> >> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> >> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >>
> >> 
> >
> > -
> > 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: Citigroup Centre, Canada Square, London E14 5LB.
> >
> > 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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Windows client problem after MP7 update

[Weber, Philip]

Hi, we've been getting the same problem with 5.1 MP6.  See
http://seer.support.veritas.com/docs/247062.htm.

My colleague has been working on this, it looks like with the
bpstart|end_notify scripts in place as described and the Content
Indexing service set to Manual (ours was disabled by a security policy),
the problem is resolved.

regards, Phil

Phil Weber
Business Technology (Egg)
Storage Technical Services - Senior UNIX Technologist
Phone: 01384 26 4136


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Dave Markham
> Sent: 05 July 2007 17:36
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] Windows client problem after MP7 update
> 
> 
> Guys i have just updated our Netbackup 5.0 environment to MP7. Master
> server is Solaris9. All stuff was fine with upgrade but now 
> some of the
> windows clients dont seem to backup correctly.
> 
> They get a portion of the way through and then this message 
> appears and
> they grind to a halt until i cancel them
> 
> bpbrm from client : WRN - Content Indexing Server: 
> unable to pause catalog: Web (some files may not get backed up)
> 
> 
> Anyone seen this before? No configuration has changed other than
> applying MP7.
> 
> Clients are Windows2000 servers which were fine before.
> Thanks
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Best practice to backup zones on Solaris 10

[Weber, Philip]

We backup both the global and local zones, with NetBackup installed in
all, because only the local zone will know its application status, but
it very much depends on how you set your zones up.  You can set up all
your filesystems in the global zone and mount them in the local zones as
loopback filesystems, in which case NetBackup won't back them up (unless
you muck around with the "follow nfs" settings).

We have standardised on exporting devices into the local zones or
mounting data filesystems directly into the zone.  These filesystems are
then available for backup in both the local and global zone, so we have
an exclude list on the global zone.  We use a bpstart_notify script to
run on the global zone backup & check and alert for filesystems missing
from the exclude list which will therefore be backed up twice.  It also
exports the local zone configs so they can be backed up as flat files.

This is a bit messy but seems the best way for us at the moment.

cheers, Phil

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of WALLEBROEK Bart
> Sent: 28 June 2007 08:14
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] Best practice to backup zones on Solaris 10
> 
> 
> What is the best way to backup zones on a Solaris 10 system?  
> Right now
> I just backup the host (zone master) and not the zones themselves (is
> this even possible) ?
> 
> Best Regards,
> 
> Bart WALLEBROEK
> 
> 
> Systems & Applications Management & Support Specialist 
> CustOPS - SDC Deployment
> Tel: + 32 2 655 30 75Mobile: + 32 478 31 61 77
> S.W.I.F.T. SCRL
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] [ORACLE] Backing up the "Control File" ...

[Weber, Philip]

Towards point 3, you can list the Oracle "files" backed up using bplist,
something like :
bplist -B -C hostname.dsto.defence.gov.au -S -t 4 -l -b
hostname.dsto.defence.gov.au -R /

cheers, Phil

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Wilkinson, Alex
> Sent: 22 June 2007 09:35
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] [ORACLE] Backing up the "Control File" ...
> 
> 
> Hi all,
> 
> Our RMAN template contains the following run block:
> 
>ALLOCATE CHANNEL ch00
>TYPE 'SBT_TAPE';
>SEND
>
> 'NB_ORA_CLIENT=hostname.dsto.defence.gov.au,NB_ORA_POLICY=EDN-
> hostname-ORA,NB_ORA_SERV=hostname.dsto.defence.gov.au,NB_ORA_S
> CHED=Default-Application-Backup';
>BACKUP
>FORMAT 'ctlfile_%d_u%u_s%s_p%p_t%t'
>CURRENT CONTROLFILE;
>RELEASE CHANNEL ch00;
>}
> 
> The only modification to this template has been the FORMAT strings.
> 
> The problem:
> 
> We never see any evidence of the control file being backed 
> via the output of the
> FORMAT string 'ctlfile_%d_u%u_s%s_p%p_t%t' in NetBackup's 
> activity monitor.
> 
> The Questions:
> 
> 1. From all my reading the Oracle policy type includes the 
> control file.
>Can someone please confirm this ?
> 
> 2. Why would we never see a string output of 
> 'ctlfile_%d_u%u_s%s_p%p_t%t' even
>though it has been defined within the RMAN template ?
> 
> 3. How can I confirm whether or not NetBackup is actually 
> backing up the control file ?
> 
> 
>  -aW
> 
> IMPORTANT: This email remains the property of the Australian 
> Defence Organisation and is subject to the jurisdiction of 
> section 70 of the CRIMES ACT 1914.  If you have received this 
> email in error, you are requested to contact the sender and 
> delete the email.
> 
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Identify drives in use

[Weber, Philip]

If I'm not mistaken, NetBackup will unload the tape (rewind offline it)
& then fail to move it from the drive back to the slot.  So although
vmoprcmd will list the tape, "mt -f ... status" will report "no tape
loaded or drive offline".  You could possibly periodically check each
drive & work out from this.  It's a bit messy though, what happens if
you catch a drive that NetBackup is in the process of successfully
unloading?

If Solaris, you should be able to check /var/adm/messages for relevant
messages to say it can't put the tape away.  (Doesn't NetBackup down the
drive anyway?).  Or somewhere in the NetBackup logs (sorry I don't know
where off the top of my head).

Sorry, only vague ideas.  I did something with a similar robot where I
ran a script from cron every hour to check and correct for any
mismatches between NetBackup and the tape robot, using various options
to vmupdate.  Also as the Ops changed the tapes by opening the robot &
moving tapes, part of the script to control that also checked that slots
were kept free for tapes currently in the drives.  Possibly not quite
what you're after but I'm happy to post the scripts if you think they
could be of use.

cheers, Phil

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Dave Markham
> Sent: 19 June 2007 14:33
> To: Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Identify drives in use
> 
> 
> Justin Piszcz wrote:
> > On Tue, 5 Jun 2007, Dave Markham wrote:
> >
> >   
> >> Justin Piszcz wrote:
> >> 
> >>> On Tue, 5 Jun 2007, Dave Markham wrote:
> >>>
> >>>   
>  Netbackup 5.0MP7 Solaris9
> 
>  Anyone know how to identify from command line what 
> drives are in use, or
>  what tapes are in use while a job is running.
> 
>  We have an issue where ops keep opening the jukebox and 
> changing tapes
>  while jobs are running. The job is fine as the L700 library just
>  suspends writes but the problem is they fill slots up which are
>  destination slots of tapes in use. Once the tapes have 
> finished and a
>  new tape is required to continue the job the old tape 
> cannot be put back
>  into its slot as it has some tape in it.
> 
>  I therefore sometimes need to manually move the tapes to 
> another slot
>  using robtest. Issue is a lot of the time the backup job is still
>  running and i dont want to unload the tapes in use so i 
> need to identify
>  them.
> 
>  I have been using iostat -xnd 2 10 |grep rmt and seeing which are
>  written to and then double checking with the gui the 
> tape ids, but i'd
>  like a nice netbackup command to just say tapes being 
> written to at that
>  moment in time.
> 
>  Cheers
>  ___
>  Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
>  http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 
>  
> >>> How to see what drives are in use? vmoprcmd -d ds
> >>>
> >>>   
> >> Thanks.
> >>
> >> Problem with this command is it shows tapes in all the 
> drives due to the
> >> problem i mentioned in my mail. Tapes are in drives due to 
> not being
> >> able to move back to destination slots. I need to confirm 
> the drives
> >> which are in use for the current job(s) running. Normally 
> its just one
> >> job running see and as im using ITC 2 drives will be in 
> use. I need to
> >> determine these so i can then safely move tapes out of the 
> other drives.
> >>
> >> Cheers
> >>
> >> 
> >
> >   
> >>> I therefore sometimes need to manually move the tapes to 
> another slot
> >>> using robtest. Issue is a lot of the time the backup job is still
> >>> running and i dont want to unload the tapes in use so i need to 
> >>>   
> > identify them.
> >
> > Read more closely, that is your problem!  If you do not 
> re-inventory in 
> > NetBackup -AND/OR- you put the tape in a slot that was 
> already kept vacant 
> > for a tape that's in the drive, you're going to have problems.
> >
> > Justin.
> > ___
> > Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >
> >   
> 
> I know exactly that if you dont inventory and put tapes in 
> you are going
> to have problems. I think you need to read more closely.
> 
> What i am saying is Operators do this while jobs are still running. Im
> 200 miles away supporting these systems.
> 
> Now as tapes cannot be moved back into the correct slots, as ops staff
> have filled them, they stay in the drive. If i have a job 
> still running
> then i have 4 tapes in use. How do i know which ones are being used by
> that job from the command line. i know vmoprcmd will show which tapes
> are in which drives but thats not what i require.
> 
> Thanks
> ___
> Veritas-bu maillist  

Re: [Veritas-bu] BPCLNTCMD -HN truncates IP address

[Weber, Philip]

I'd never seen this before but funnily enough just tripped over it on a
couple of clients I'm moving from NBU 4.5MP9 master to 5.1MP6 master.
Both clients are W2K3 & remaining at 4.5MP9 for now (because I can't
access them to upgrade).  bpclient -hn on the master fails to return the
IP address correctly.  I can't tell yet whether upgrading the client
would improve.  I suspect this is what's making the job run as 1 stream
as the master can't find out what filesystems exist on the client.

Unbelievable!!! What does the "Net" in NetBackup stand for?  You'd have
thought it could resolve addresses!

Anyone know of a workaround or fix?

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of ENAJ (Ena Jensen)
> Sent: 15 June 2007 08:40
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] BPCLNTCMD -HN truncates IP address
> 
> 
>  
> We have the same issue on HP-UX 5.1 MP6 and on windows clients running
> 5.1 MP5
> 
> Ena 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Carl
> Mathews
> Sent: 14. juni 2007 16:02
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] BPCLNTCMD -HN truncates IP address
> 
> Yes bpclntcmd -hn hostname cuts off the last digit when 
> issued from the
> 5.1MP6 Solaris 9 Master Server. I noticed it with MP6. 
> NB_5.1MP6 clients
> that I tested return the right IP address.
> 
> Carl Mathews
> University of Arkansas
> 
> ---Original Message
> 
> 
> Has anyone ever seen BPCLNTCMD -HN truncate the IP address?
> 
> For instance, the IP in the hosts file is 10.10.10.100 and BPCLNTCMD
> looks like this:
> /usr/openv/netbackup/bin  >
> ./bpclntcmd -hn hostname host hostname: hostname at 10.10.10.10
> (0xabcde0)
> checkhname: aliases:
> 
> I have at least two boxes that this is happening on, first 
> one is above,
> the other is .200 and comes out as .20 in bpclntcmd, and of 
> course they
> are failing with a 54. The only correlation I can draw 
> between these two
> is that they were new additions to the existing hosts file. 
> Other hosts
> entries are fine and backups are successful.
> 
> This is a new Solaris 10 media server that is barely in production and
> nsswitch.conf lists files first. NBU 5.1MP6. A quick internet search
> turned up nothing. Any ideas?
> 
> Rusty Major, MCSE, BCFP
> Sr. Data Assurance Engineer
> (281) 584-4693
> VeriCenter, Inc.
> 
> ___
> 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
> 

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tuning Solaris 10 for NetBackup Media Server

[Weber, Philip]

Off topic a bit, but does anyone know how to map the st device names to
rmt device names in the iostat output?  I've written a script to do it
but it seems a bit like hard work ... on my Solaris 9 boxes "iostat -xn"
lists the rmt device names.

thanks, Phil

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Peter DrakeUnderkoffler
> Sent: 14 June 2007 00:48
> To: Ed Wilts
> Cc: VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Tuning Solaris 10 for NetBackup Media Server
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> If your running the tapes on Solaris, the iostat utility will show the
> throughput on st devices as well as disks and ttys.  If thats 
> what your
> looking for, start with "iostat -xE" to list all the device 
> names as needed
> by the iostat utility.  Might show something like this:
> 
> st15  Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
> Vendor: HP   Product: Ultrium 2-SCSI   Revision: S33H Serial No:
> 
> You can then run that against iostat as in "iostat st15 2"
> 
> Thanks
> Peter
> 
> Peter DrakeUnderkoffler
> Xinupro, LLC
> 617-834-2352
> 
> 
> 
> Ed Wilts wrote:
> >>Our numbers vary greatly according to the clients.  We have very old
> >>Solaris machines that backup at 50+ MB/sec.  We have very 
> new Windows
> >>machines where throughput varies greatly between different 
> volumes on
> >>the same machine (e.g. a volume with 5 million tiny files 
> backs up at
> >>30 MB/sec via FlashBackup, while another volume on the same machine
> >>gets about 7 MB/sec backing up small files via FlashBackup).
> >>
> >>It's difficult to get good numbers because we use 
> multi-streaming and
> >>multiplexing like crazy.  So the actual throughput to the 
> drive is the
> >>sum of the jobs using the drive at that moment.  Individual 
> jobs vary
> >>between 5 MB/sec and about 65 MB/sec.  But the total 
> throughput to the
> >>tape heads is unknown.
> >>
> >>Anyone know an easy way to calculate that?
> > 
> > 
> > If your drives are fibre-attached, use something like MRTG 
> to grab the fibre
> > port stats and graph that.  That gives us a pretty good 
> idea as to what the
> > tape speeds are. 
> > 
> > --
> > Ed Wilts, Mounds View, MN, USA
> > mailto:[EMAIL PROTECTED]
> > I GoodSearch for Bundles Of Love:
> > http://www.goodsearch.com/?charityid=821118 
> > 
> > ___
> > Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> > 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.5 (FreeBSD)
> 
> iD8DBQFGcIISl+lekZRM55oRAgwPAKCwOXeHU66dOtdEevWstDSZ/Rv7owCfeAhb
> LnvzECvM4VkhddgjyBdj5n4=
> =k2DP
> -END PGP SIGNATURE-
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] REQUIRED_INTERFACE Problem?

[Weber, Philip]

We're using client-bk as the client name.  In our environment we have multiple 
firewall-segregated subnets, none of which are particularly different 
address-wise (i.e. not 10.x vs 192.x) but rather 10.x.y.z vs 10.x.z.z).  So the 
master/media (although multi-homed to allow backup of some subnets without 
going through a firewall) talks to the this client over its (the media 
server's) public IP.

Looks like Solaris is handling the routing back so although the request comes 
in to the client on the backup interface, Solaris routes it back over the most 
appropriate interface according to the routing table, which in this instance is 
the public interface.

cheers, Phil

> -Original Message-
> From: rcarlisle [mailto:[EMAIL PROTECTED] 
> Sent: 05 June 2007 15:01
> To: Weber, Philip; VERITAS-BU@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] REQUIRED_INTERFACE Problem?
> 
> 
>  
> REQUIRED_INTERFACE is only valid for client initiated 
> backups.  So, it is
> very important to use in multiple nic environments with database agent
> backups since, technically, they are client initiated.  With 
> non-database
> scheduled backup, the client will respond back over whatever 
> interface the
> request was initiated on.  Are you using client-bk or 
> client-pub as the
> client name in the policy?  If you specify client-bk as the 
> client name, the
> media server will go out the backup nic.  However, if the 
> media server name
> is associated with the public nic, all meta data will still go out the
> public interface.
> 
>  
>  
> Reneé Carlisle 
> ServerWare Corporation
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Weber,
> Philip
> Sent: Tuesday, June 05, 2007 9:31 AM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: [Veritas-bu] REQUIRED_INTERFACE Problem?
> 
> Master/Media Solaris9 NBU 5.1 MP6.
> Client Solaris10 NBU 5.1 MP6.
> 
> Client has two network interfaces client-pub & client-bk.
> 
> I want all backup traffic to go via the client-bk interface, 
> but unless
> I add a network route for the backup server subnet over the client's
> backup interface, backups fail with a 41.  I was under the impression
> that REQUIRED_INTERFACE was all I should need.
> 
> e.g. with bp.conf "CLIENT_NAME = client-bk" and "REQUIRED_INTERFACE =
> client-bk", but with no specific network route, client-initiated
> backup/restore requests appear to go OK.  When I snoop the various
> network interfaces during a server-initiated backup attempt, I see the
> media server talking to client-bk (and getting no response), client-bk
> sees incoming requests from media server, client (interface) sees
> outgoing requests from client-bk to the media server... so 
> responses are
> going back over the wrong interface (and never getting there due to
> firewalls).
> 
> Add the route "route add net media-server-subnet.0 
> subnet-defaultrouter"
> and backups work fine.
> 
> So I guess REQUIRED_INTERFACE only works for traffic 
> initiated from the
> client, and the OS handles routing of reply information?
> 
> Phil Weber
> Business Technology (Egg)
> Storage Technical Services - Senior UNIX Technologist
> Phone: 01384 26 4136
> Mobile: 07748 333503
> 
> 
> -
> 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: Citigroup Centre, Canada Square, London E14 5LB.
> 
> 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

[Veritas-bu] REQUIRED_INTERFACE Problem?

[Weber, Philip]

Master/Media Solaris9 NBU 5.1 MP6.
Client Solaris10 NBU 5.1 MP6.

Client has two network interfaces client-pub & client-bk.

I want all backup traffic to go via the client-bk interface, but unless
I add a network route for the backup server subnet over the client's
backup interface, backups fail with a 41.  I was under the impression
that REQUIRED_INTERFACE was all I should need.

e.g. with bp.conf "CLIENT_NAME = client-bk" and "REQUIRED_INTERFACE =
client-bk", but with no specific network route, client-initiated
backup/restore requests appear to go OK.  When I snoop the various
network interfaces during a server-initiated backup attempt, I see the
media server talking to client-bk (and getting no response), client-bk
sees incoming requests from media server, client (interface) sees
outgoing requests from client-bk to the media server... so responses are
going back over the wrong interface (and never getting there due to
firewalls).

Add the route "route add net media-server-subnet.0 subnet-defaultrouter"
and backups work fine.

So I guess REQUIRED_INTERFACE only works for traffic initiated from the
client, and the OS handles routing of reply information?

Phil Weber
Business Technology (Egg)
Storage Technical Services - Senior UNIX Technologist
Phone: 01384 26 4136
Mobile: 07748 333503


-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Identify drives in use

[Weber, Philip]

If NetBackup can't move a tape back from the drive to its slot, it will
down the drive (at least in our environment - & as the OS is Solaris
will log a message to /var/adm/messages).

We used to have a small robot where the OPs manually changed tapes by
opening the robot up & moving tapes.  As part of the script that told
them what to do I used tldtest to check which slots the tapes in the
drives came from, and make sure those slots were kept free.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Dave Markham
> Sent: 05 June 2007 11:16
> To: Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Identify drives in use
> 
> 
> Justin Piszcz wrote:
> >
> >
> > On Tue, 5 Jun 2007, Dave Markham wrote:
> >
> >> Netbackup 5.0MP7 Solaris9
> >>
> >> Anyone know how to identify from command line what drives 
> are in use, or
> >> what tapes are in use while a job is running.
> >>
> >> We have an issue where ops keep opening the jukebox and 
> changing tapes
> >> while jobs are running. The job is fine as the L700 library just
> >> suspends writes but the problem is they fill slots up which are
> >> destination slots of tapes in use. Once the tapes have 
> finished and a
> >> new tape is required to continue the job the old tape 
> cannot be put back
> >> into its slot as it has some tape in it.
> >>
> >> I therefore sometimes need to manually move the tapes to 
> another slot
> >> using robtest. Issue is a lot of the time the backup job is still
> >> running and i dont want to unload the tapes in use so i 
> need to identify
> >> them.
> >>
> >> I have been using iostat -xnd 2 10 |grep rmt and seeing which are
> >> written to and then double checking with the gui the tape 
> ids, but i'd
> >> like a nice netbackup command to just say tapes being 
> written to at that
> >> moment in time.
> >>
> >> Cheers
> >> ___
> >> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> >> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >>
> >
> > How to see what drives are in use? vmoprcmd -d ds
> >
> Thanks.
> 
> Problem with this command is it shows tapes in all the drives 
> due to the
> problem i mentioned in my mail. Tapes are in drives due to not being
> able to move back to destination slots. I need to confirm the drives
> which are in use for the current job(s) running. Normally its just one
> job running see and as im using ITC 2 drives will be in use. I need to
> determine these so i can then safely move tapes out of the 
> other drives.
> 
> Cheers
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Windows VSS Q

[Weber, Philip]

Yes I know all that thanks.  I just found it concerning that Windows or
NetBackup on the client could choose to ignore some files quietly and
the NetBackup server not know anything about it.  Concerning also that
the volume of data backed up would be different from the volume of data
on the server and the NetBackup master logs not know anything about it.
In the past any files that couldn't be backed up would result in
messages or errors on the master and a non-zero return code.  Makes me
wonder what else is being "hidden" that I might not know about until I
try to restore it.  But if that's the way W2K3 works then I guess I'll
have to live with it.

Only similary thing I came across was the Advanced Client for Oracle
taking account of exclude lists on the client (standard Oracle agent
ignores them) and this not backing things up, quietly.  Only discovered
that by restore testing.  It has finally been recognised as a data loss
issue to be fixed in a forthcoming MP.

-Original Message-
From: Anas Kayal [mailto:[EMAIL PROTECTED] 
Sent: 20 May 2007 05:38
To: Weber, Philip; veritas-bu@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Windows VSS Q

Phil,

You have an MSSQL Server running on this machine and theres a DB by the
name of RealSecureDBLog that cannot be "hot" backuped without an SQL
agent. To properly back this DB up (with the log file) you have to
either get the SQL Agent or schedule a regular DB dump from within MSSQL
and backup the dump file.

After making sure it works, just add the path to the exclude list so you
don't get any errors in the log.

Best regards,
 
Anas 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weber,
Philip
Sent: Friday, May 18, 2007 5:19 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Windows VSS Q

Master/media: Solaris 9 NBU 5.1 MP6
Cient: Windows 2003 NBU 5.1 MP6

Dear all,

Noticed a Windows 2003 full backup wasn't as big as expected, and found
messages similar to the below in the client's bpbkar log.  I get these
regardless of whether Windows Open File Backups are enabled :

2:04:56.126 PM: [3328.3068] <2> tar_base::V_vTarMsgW: INF - Filtered
'Shadow Copy Components' Object: D:\MSSQL\Database\SiteProtector\Site
Database\Data\RealSecureDB.mdf
2:04:56.126 PM: [3328.3068] <2> tar_base::V_vTarMsgW: INF - Filtered
'Shadow Copy Components' Object: D:\MSSQL\Database\SiteProtector\Site
Database\Data\RealSecureDBLog.ldf

I'm being told that these just mean that the file was open and couldn't
be backed up (I know it needs a SQL Agent) - but NetBackup usually
reports this and returns a status code 1.  These backups are exiting
with status code 0.  Seems a bit scary...

Can anybody thow any more light on this?

thanks, Phil

Phil Weber
Business Technology (Egg)
Storage Technical Services - Senior UNIX Technologist
Phone: 01384 26 4136
Mobile: 07748 333503

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@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

Re: [Veritas-bu] Tuning Windows backups

[Weber, Philip]

Sorry...should have been a new topic :-( I'll re-send this.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Weber, Philip
> Sent: 18 May 2007 15:08
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Tuning Windows backups
> 
> 
> Master/media: Solaris 9 NBU 5.1 MP6
> Cient: Windows 2003 NBU 5.1 MP6
> 
> Dear all,
> 
> Noticed a Windows 2003 full backup wasn't as big as expected, 
> and found
> messages similar to the below in the client's bpbkar log.  I get these
> regardless of whether Windows Open File Backups are enabled :
> 
> 2:04:56.126 PM: [3328.3068] <2> tar_base::V_vTarMsgW: INF - Filtered
> 'Shadow Copy Components' Object: D:\MSSQL\Database\SiteProtector\Site
> Database\Data\RealSecureDB.mdf
> 2:04:56.126 PM: [3328.3068] <2> tar_base::V_vTarMsgW: INF - Filtered
> 'Shadow Copy Components' Object: D:\MSSQL\Database\SiteProtector\Site
> Database\Data\RealSecureDBLog.ldf
> 
> I'm being told that these just mean that the file was open 
> and couldn't
> be backed up (I know it needs a SQL Agent) - but NetBackup usually
> reports this and returns a status code 1.  These backups are exiting
> with status code 0.  Seems a bit scary...
> 
> Can anybody thow any more light on this?
> 
> thanks, Phil
> 
> Phil Weber
> Business Technology (Egg)
> Storage Technical Services - Senior UNIX Technologist
> Phone: 01384 26 4136
> Mobile: 07748 333503
> 
> -
> 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: Citigroup Centre, Canada Square, London E14 5LB.
> 
> 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@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] Windows VSS Q

[Weber, Philip]

Master/media: Solaris 9 NBU 5.1 MP6
Cient: Windows 2003 NBU 5.1 MP6

Dear all,

Noticed a Windows 2003 full backup wasn't as big as expected, and found
messages similar to the below in the client's bpbkar log.  I get these
regardless of whether Windows Open File Backups are enabled :

2:04:56.126 PM: [3328.3068] <2> tar_base::V_vTarMsgW: INF - Filtered
'Shadow Copy Components' Object: D:\MSSQL\Database\SiteProtector\Site
Database\Data\RealSecureDB.mdf
2:04:56.126 PM: [3328.3068] <2> tar_base::V_vTarMsgW: INF - Filtered
'Shadow Copy Components' Object: D:\MSSQL\Database\SiteProtector\Site
Database\Data\RealSecureDBLog.ldf

I'm being told that these just mean that the file was open and couldn't
be backed up (I know it needs a SQL Agent) - but NetBackup usually
reports this and returns a status code 1.  These backups are exiting
with status code 0.  Seems a bit scary...

Can anybody thow any more light on this?

thanks, Phil

Phil Weber
Business Technology (Egg)
Storage Technical Services - Senior UNIX Technologist
Phone: 01384 26 4136
Mobile: 07748 333503

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Tuning Windows backups

[Weber, Philip]

Master/media: Solaris 9 NBU 5.1 MP6
Cient: Windows 2003 NBU 5.1 MP6

Dear all,

Noticed a Windows 2003 full backup wasn't as big as expected, and found
messages similar to the below in the client's bpbkar log.  I get these
regardless of whether Windows Open File Backups are enabled :

2:04:56.126 PM: [3328.3068] <2> tar_base::V_vTarMsgW: INF - Filtered
'Shadow Copy Components' Object: D:\MSSQL\Database\SiteProtector\Site
Database\Data\RealSecureDB.mdf
2:04:56.126 PM: [3328.3068] <2> tar_base::V_vTarMsgW: INF - Filtered
'Shadow Copy Components' Object: D:\MSSQL\Database\SiteProtector\Site
Database\Data\RealSecureDBLog.ldf

I'm being told that these just mean that the file was open and couldn't
be backed up (I know it needs a SQL Agent) - but NetBackup usually
reports this and returns a status code 1.  These backups are exiting
with status code 0.  Seems a bit scary...

Can anybody thow any more light on this?

thanks, Phil

Phil Weber
Business Technology (Egg)
Storage Technical Services - Senior UNIX Technologist
Phone: 01384 26 4136
Mobile: 07748 333503

-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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

[Weber, Philip]

We still have a fairly busy 4.5 environment due to older OS versions so
I can't see us moving off our 5.1 environment for a while ... this for
us is the "show-stopper" for not upgrading.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts
Sent: 15 May 2007 12:46
To: 'Scott Jacobson'; 'Simon (external) WEAVER'; 'Paul Keating';
VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] 5.1 Oct 2007 End of Support



I don't believe that customers are being placed between a rock and a
hard place - 6.0 MP4 is a stable release that works today.  I have not
heard of any show-stopper bugs in 6.0 that would prevent anybody from
upgrading.  You may need an engineering fix or two, and perhaps MP5 will
include those, but in general, the current release works for just about
everybody.

If you really feel that 5.1MP4 is rock solid, and there are no issues,
why are you concerned with Symantec continuing to support it?  You don't
*have* to upgrade - just don't log a call and expect it to get fixed.
If you have no issues, you'll have no calls to log and it won't matter
if it's supported or not.  I've got a non-Symantec product running that
we last logged a call on in 2000 (and our license agreement says that we
have to keep it under support as long as we're running it).

  .../Ed

--

Ed Wilts, Mounds View, MN, USA

mailto:[EMAIL PROTECTED]

 

I GoodSearch for Bundles Of Love

http://www.goodsearch.com/?charityid=821118 

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott
Jacobson
Sent: Monday, May 14, 2007 2:03 PM
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




-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] blib and exclude lists

[Weber, Philip]

It's not really an answer to your question :-O but Advanced Client
backups for Oracle RMAN (Proxy Copy) *DO* read exclude lists, which is
the opposite of normal operation with NetBackup Agent for Oracle RMAN
backups.
 
I think Symantec have addressed this as a potential data loss issue in
the latest MP for NBU 5.1.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Whelan,
Patrick
Sent: 16 May 2007 15:02
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] blib and exclude lists



Does anyone have a definitive answer as to whether blib backups will
read or not exclude lists? I have looked through the admin, advanced
client and oracle agent manuals with not success.

Patrick Whelan

NetBackup Specialist (Contractor)

COLT Telecom

Architect & Engineering

+44 20 7863 5243







*
The message is intended for the named addressee only and may not be
disclosed to or used by anyone else, nor may it be copied in any way. 

The contents of this message and its attachments are confidential and
may also be subject to legal privilege. If you are not the named
addressee and/or have received this message in error, please advise us
by e-mailing [EMAIL PROTECTED] and delete the message and any
attachments without retaining any copies. 

Internet communications are not secure and COLT does not accept
responsibility for this message, its contents nor responsibility for any
viruses. 

No contracts can be created or varied on behalf of COLT
Telecommunications, its subsidiaries or affiliates ("COLT") and any
other party by email Communications unless expressly agreed in writing
with such other party. 

Please note that incoming emails will be automatically scanned to
eliminate potential viruses and unsolicited promotional emails. For more
information refer to www.colt.net or contact us on +44(0)20 7390 3900.





-
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: Citigroup Centre, Canada Square, London E14 5LB.

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Curious Log Entry

[Weber, Philip]

I believe you can get this when resources (memory?) are overloaded on
the master/media.  Can't be more specific as only seen it very rarely &
so haven't investigated thoroughly.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Brooks, Jason
> Sent: 24 April 2007 14:49
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] Curious Log Entry
> 
> 
> 4/23/2007 11:21:15 PM masterA client1 Error   83645   Backup
> backup of client client1 exited with status 150 (termination 
> requested by
> administrator)
> 
> How do you end up with a 150 when no Admins are here?  Anyone 
> seen this one?
> I can't recall seeing it before, and at first blush, it makes me a bit
> nervous.  I'll be poking around to see what I can find.
> 
> Thanks,
> Jason
> 
> 
> Jason Brooks
> Computer Systems Engineer
> IITS - Longwood University
> voice - (434) 395-2034
> fax - (434) 395-2035
> mailto:<[EMAIL PROTECTED]> 
> 

-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NetBackup 5.1 on Solaris 10

[Weber, Philip]

I recently added a Solaris 10 media server/robot host to our existing
Solaris 9 master & medias environment.  If I recall, didn't really have
any problems.  NBU 5.1 MP6.  Not SSO (though we use SSO on the other
media servers).
 
You may need to run /usr/sbin/inetconv to convert the /etc/services
entries for NetBackup into Solaris 10 services.  I can't remember
whether the install did this for us or not.
 
Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Boris
Kraizman
Sent: 13 April 2007 01:22
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] NetBackup 5.1 on Solaris 10


Hi Gents,

I have to ask you for your assistance once again, I am trying to add a
new media server on the existing Netbackup 5.1 MP5 system, it is Solaris
10 and I am having a problem with it, I can see just vmd process
running. I have read a note about supporting NetBackup for Solaris 10
and it says I have to apply MP2 or higher, in my case it is MP5. I can
see tape drives on the OS level, no problem with it at all. It is our
first Solaris 10 with NetBackup, we have a few others on Solaris 9 and
no any problems at all. We have another server that controls the same
tape library, and it has SSO license and configured with shared drives. 
Your thoughts would be really appreciated.

Thank you,
Boris.





-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 5.1 Reports

[Weber, Philip]

I parse bpdbjobs -all_columns output, pull what fields we are interested
in into a MySQL database, from where I produce various email and HTML
reports are produced cutting the data by various criteria which
management are interested in.  It's taken quite a while to evolve but I
can now usually direct a lot of management queries at the web pages, or
reasonably easily pull the information out of the database.
 
Not sure if this is a yes or a no to your question, but it is one option
if you've got the time and programming skills ...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WEAVER,
Simon (external)
Sent: 29 March 2007 11:29
To: 'veritas-bu@mailman.eng.auburn.edu'
Subject: [Veritas-bu] NBU 5.1 Reports



All
Win2k3 NBU 5.1 Reports Module
I know the reports are limited in this version of NBU, and I do not want
to purchase additional reporting modules yet, as we may well be looking
at going to 6.0, but does anyone use any of the info from the Reports
Module and place it into Excel to create fancy graphs or charts on the
status of the backups.
 
Trouble I have, is that the status of backup reports advises the status
per stream, and thats an awful lot of raw data to place into Excel - And
to be honest management are not intersted in raw data just nice
simple charts.
 
Does anyone have any suggestions on what I could do or perform to either
take the data from NBU and create a fancy report? or something that is
simple on the eyes for management to see
 
Thank you
 

Regards

Simon Weaver
3rd Line Technical Support
Windows Domain Administrator 

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

Email:  
[EMAIL PROTECTED]

 
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 and do not use
it for any purpose or disclose its content to any person, but delete
this message and any attachments from your system.
Astrium disclaims any and all liability if this email transmission was
virus corrupted, altered or falsified.
-
Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
England





-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Oracle backup with or without Advance Client

[Weber, Philip]

I believe so.  If you use rman to take an Oracle incremental level 1+
backup, Oracle does the work to work out what data to send.  It sends
its data over the SAN rather than IP which should improve performance.
If you use block level incremental backups then it should improve
performance by only reading the changed blocks.  That's my understanding
anyway.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Priatna
Sent: 26 March 2007 04:35
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Oracle backup with or without Advance Client


If we are using Advance Client along with Oracle agent to take RMAN
incremental backup, does it reads the entire file or it reads only the
blocks that have changed? 
I didn't find the answer on the document.

Kai Stian Olstad wrote: 

Priatna wrote:

  

my question with regards oracle backup type :

- Is BLI - Advance Client still needed, to take incremental backup?





No, you do not need Advanced Client to take incremental backup.





  

- What is the additional benefit by using Advance Client BLI in the 

oracle type backup?





According to the Netbackup manual; saves time, less backup media,

reduces CPU and network overhead.



I recommend reading the manual

http://ftp.support.veritas.com/pub/support/products/NetBackup_Enterprise
_Server/279281.pdf





  





-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Netbackup Error 6 - RMAN logs no error

[Weber, Philip]

This means the script called by the rman policy returned a non-zero
status code, so could be rman returned an error which was returned to
the script, or something else in the script returned a non-zero code
(including a scripting error).  If there's no error in the log file
written to by the rman command, I'd put a "set -x" (Solaris) in the
script and redirect its output somewhere where you can check it
afterwards - this usually highlights the error/mistake/typo for me.
 
regards, Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Veritas
Netbackup
Sent: 26 March 2007 09:02
To: NB List Mail
Subject: [Veritas-bu] Netbackup Error 6 - RMAN logs no error


Hi List,

Of late we have been seen a number of backups end with error 6 for
parent stream, while the child streams end successfully.

The DBA has been able to restore the data too. But we cannot ignore the
error as it would be a confusion in event of a disaster. 

I have analyzed the DBClient logs and find the backup exit with 0 and no
indications of any failed messages.

Anyone seen similar problems.

Regards,
PP BIJU KRISHNAN





-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] 219 when number of jobs are high??

[Weber, Philip]

Ah, just logged a call for Veritas about a similar issue.  I hadn't tied it in 
with the no. of jobs, but we have recently significantly added to the no. of 
jobs going through this particular media server ... and are only just starting 
to load it up, which is a bit worrying.  I'll investigate the OS disks.  Thanks.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keating
Sent: 20 March 2007 12:54
To: nbu
Subject: Re: [Veritas-bu] 219 when number of jobs are high??


Started happening here early this year, only during the weekend fulls and 
always around the same time, 07:10, Saturday morning.
 
happened every couple of weekes for a while, then got to the point where it was 
every week.
 
After watching disk IO, I discovered there was a significant number of waits on 
the /opt/openv partition, so I've since changed the /opt/openv partition on my 
Master to a striped/mirrored (RAID-10) layout rather than the 
mirrored/concatenated layout that it had previously.it was originally built 
like that with only 2 disks in a mirror. As the data grew we added 2 disks and 
extended the volume, but didn't change the layout to striped, so it appears the 
problem started right around when the data grew out of the first pair of disks 
onto the second.
 
I also added forceload statements in /etc/system for the SCSI and FC drivers at 
the same time.
 
Haven't had it happen since.
 
Paul
 
 
-- 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Veritas Netbackup
Sent: March 20, 2007 5:24 AM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] 219 when number of jobs are high??


Hi,

Just wanted to know if anybody has faced the issue of jobs failing with 219 
when the total count of jobs on the system is high.

Re firing the jobs after a few minutes succeeds, but not immediately.

We are using 

Netbackup 5.1 MP4
on Solaris 9 Sparc 64 bit.

Regards,
PP BIJU KRISHNAN






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.




-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] 5.1: Backup stalls

[Weber, Philip]

Are you backing up through a firewall?  We have a similar issue where
the final acknowledgement isn't getting back from the client to the
media server, so the backup hangs at 100% complete.  Only for occasional
backups, and maybe those with more streams than others.  It isn't
clear-cut though, and the firewalls are not showing any drops.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Alexander Skwar
> Sent: 19 January 2007 14:56
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] 5.1: Backup stalls
> 
> 
> Hi.
> 
> I'm using NBU 5.1 to backup a few Solaris servers. Since recently,
> I'm experiencing problems with the backup. Specifically, on one
> server, the backup just stalls (at the last file?). Ie. it just
> doesn't go on.
> 
> Eg. right now, it hangs at:
> 
> [EMAIL PROTECTED] ~ $ ls -lah 
> /.backup/snapshots/u01/apps/oracle/oradata/RACEREF0/archive/1_
> 403_583919677.dbf
> -rw-r-   1 oracle   oinstall9.6M Mar 13  2006 
> /.backup/snapshots/u01/apps/oracle/oradata/RACEREF0/archive/1_
> 403_583919677.dbf
> 
> So it hangs at a file which is just a tiny 9.6M in size.
> 
> The file resides on a Solaris 9 Sparc server. It's on a snapshot
> of a UFS filesystem. Because of that, the file cannot change. Ie.
> it's impossible that something's changing the file while it's being
> backed up.
> 
> Anyone know what might be causing this?
> 
> Regards,
> 
> Alexander Skwar
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 

-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Yet another bpstart/bpend script question

[Weber, Philip]

I spent some time on this a year or two ago for backing up Oracle
without using the NetBackup Agent.  I found

1.  Do the "start of backup" work on the first stream that runs, which
isn't necessarily STREAM_NUMBER=1.  Set a flag to indicate it's
complete.  You'll have to do some checking to prevent two "first"
streams locking each other out.
2.  1st stream that runs should create lock files for all the expected
streams, using STREAM_COUNT, which each subsequent stream removes when
complete.  Otherwise, in a busy environment, some streams could complete
and none be running, the database get started back up, before some of
the streams have even begun.

There may be other things to address, I still get the occasional failure
but they have been infrequent enough not to merit any further work on
this yet.

Hope this helps,
Phil

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Ellis, Jason
> Sent: 19 January 2007 16:49
> To: Ed Wilts
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Yet another bpstart/bpend script question
> 
> 
> Actually I plan to create .lock files for each stream as they call the
> bpstart_notify script. For example:
> 
> Stream 1 starts and creates the stream_1.lock file.
> 
> Stream 2 starts and creates the stream_2.lock file.
> 
> Stream 3 starts and creates the stream_3.lock file.
> 
> Later:
> 
> Stream 2 completes and deletes its .lock file, but the bpend_notify
> script still finds the .lock file for stream 1 and 3.
> 
> Stream 1 completes and deletes its .lock file, but the bpend_notify
> script still finds the .lock file for stream 3.
> 
> Finally stream 3 completes and deletes its .lock file. The 
> bpend_notify
> script, not finding any more .lock files, runs the final tasks and
> completes.
> 
> In theory this should work.
> 
> Jason Ellis
> Technical Consultant, Data Protection Team
> IndyMac Bank, La Mirada Datacenter
> Phone: (714) 520-3414
> Mobile: (714) 889-8734
> 
> -Original Message-
> From: Ed Wilts [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, January 18, 2007 7:42 PM
> To: Ellis, Jason
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Yet another bpstart/bpend script question
> 
> On 1/18/2007 6:25 PM, Ellis, Jason wrote:
> > I really need to capture the STREAM_NUMBER if possible to help
> mitigate 
> > a job with multiple data streams. My idea is to use lock files to 
> > prevent the bpstart_notify from running once one stream has already 
> > started, and the bpend_notify script from kicking off until 
> the last 
> > stream has completed.
> 
> This is a lost cause so save yourself some work.  There is no 
> guarantee 
> that the last stream won't complete before an earlier stream 
> and unless 
> you disallow retries completely, the task gets harder and harders.
> 
> What are you going to do if stream 1 starts, gets partially 
> done, has a 
> tape error, and retries?  What are you going to do if the last stream 
> finishes early?  What are you going to do if the last stream dies 
> completely and can't finish?
> 
> The problem is much harder than it looks...
> 
>   .../Ed
> 
> -- 
> Ed Wilts, Mounds View, MN, USA
> mailto:[EMAIL PROTECTED]
> 
> 
> 
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> 

-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.aubur

Re: [Veritas-bu] LTO3 Drive Issues

[Weber, Philip]

I am perceiving a similar situation with my new LTO3 drives - slower
overall performance than LTO2, but haven't really got any evidence yet
and won't until a few weeks down the line (and many firewall changes)
when I can start loading them up.  I'm unfortunately well aware that we
haven't really got performant enough disk/network in front of them etc.
etc.  If I find/sort anything out I'll report back...

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave
Brown
Sent: 29 December 2006 18:29
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] LTO3 Drive Issues


 
I am fighting this one.
 
I have Quantum M1500 lib with 2 LTO2 drives.  Put in 3rd drive but it is
LTO3.  Logically to me (and confirmed by people here)  I should be able
to tell the drive to write hcat2 density and all should be well but it
is not.  The installation notes from the drive said M1500 required
firmware of 10.0 and I currently have 12.0 so that should not be an
issue.
 
I can get the drive to load a tape and even write files to it but is is
so slow and painful that it does not seem right.  I expected it to be
slow as the speed of the drive certainly out performs the rate at which
I can supply data.
 
I tried a policy with three clients listed.  One of the clients has
drive attached locally while other two are coming across a 100mb network
connection.  I set it to allow 8 streams and each client to allow
multiple streams as well.  I was getting 8 streams writing to it and
while the stream were reporting 3mb/sec or better,  the overall
performance of the jobs appeared much slower.  As a test,  I ran the
same job to my LTO2 drive and it just flew through.
 

NB60 MP4
Windows 2003
 
Thoughts, Ideas, suggestions ?
 
Dave
 
 
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. 




-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Backup of Large Windows Volume

[Weber, Philip]

It's a SAN-based volume so I'm not too worried about this, we do it
elsewhere.  Will have to keep an eye on it but current performance stats
indicate I should be able to get the data off the disks faster with
multiple streams.

-Original Message-
From: Steve Fogarty [mailto:[EMAIL PROTECTED] 
Sent: 21 December 2006 15:16
To: Weber, Philip; veritas-bu@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Backup of Large Windows Volume


I don't think you want to have seperate streams from the same physical
disk.  This is from the Admin Doc.
 
"For best performance, use only one data stream to back up each physical
device on the 
client. Multiple concurrent streams from a single physical device can
adversely affect 
backup times because the heads must move back and forth between tracks
containing files 
for the respective streams."
 
Your selections would probably "thrash" the disk pretty hard.
 
Steve
 
 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weber,
Philip
Sent: Thursday, December 21, 2006 10:45 AM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Backup of Large Windows Volume



NetBackup 5.1 MP5, Solaris 9 master/media servers. 

I have a Windows 2000 client with approx 900 Gb D: drive which I want to
split into multiple streams, e.g. 

Stream 1 : 
D:\Shares\shareddata\All Departments\folder1 (100 Gb) 

Stream 2 : 
D:\Shares\shareddata\All Departments (the rest - 130 Gb) 

Stream 3 : 
D:\Shares\shareddata\folder1 (160 Gb) 

Stream 4 : 
D:\Shares\shareddata\folder2 (52 Gb) 
D:\Shares\shareddata\folder3 (52 Gb) 

Stream 5 : 
D:\Shares\shareddata (the rest - 270 Gb) 

Stream 6 : 
D:\Shares (the rest - 130 Gb) 

As far as I can see I'll have to create separate policies for all of
these, in order to be able to use exclude lists to prevent duplication
of backups.  Is there some way that I have missed where I can add these
all to one policy using NEW_STREAM, and not get duplication of data?

thanks, Phil 

Phil Weber 
Business Technology (Egg) 
Storage Technical Services - Senior UNIX Technologist 



  _  






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: Laurence Pountney Hill, London EC4R 0HH.


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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] Backup of Large Windows Volume

[Weber, Philip]

NetBackup 5.1 MP5, Solaris 9 master/media servers.

I have a Windows 2000 client with approx 900 Gb D: drive which I want to
split into multiple streams, e.g.

Stream 1 :
D:\Shares\shareddata\All Departments\folder1 (100 Gb)

Stream 2 :
D:\Shares\shareddata\All Departments (the rest - 130 Gb)

Stream 3 :
D:\Shares\shareddata\folder1 (160 Gb)

Stream 4 :
D:\Shares\shareddata\folder2 (52 Gb)
D:\Shares\shareddata\folder3 (52 Gb)

Stream 5 :
D:\Shares\shareddata (the rest - 270 Gb)

Stream 6 :
D:\Shares (the rest - 130 Gb)

As far as I can see I'll have to create separate policies for all of
these, in order to be able to use exclude lists to prevent duplication
of backups.  Is there some way that I have missed where I can add these
all to one policy using NEW_STREAM, and not get duplication of data?

thanks, Phil

Phil Weber
Business Technology (Egg)
Storage Technical Services - Senior UNIX Technologist




-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Firewall setup

[Weber, Philip]

Run "bpclient -client $CLIENT -add -no_callback 1" on your master server
(replacing $CLIENT with your client's name).
 
Or from the GUI :
NetBackup Management --> Host Properties --> Master Servers (right click
on the relevant one) --> Properties --> Client Attributes --> Add.
Add your client & set BPCD Connect Back to VNETD port.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anas
Kayal
Sent: 21 December 2006 06:29
To: NB List Mail
Subject: Re: [Veritas-bu] Firewall setup



Guys, I have 2 servers in my DMZ. Now after reading this forum I opened
ports 13720 and 13724 and permitted access from my master server to both
servers in DMZ in both directions. Now how do I specify that this port
should be used by this client and the other port by the other client? 

 

Anas Kayal

IT Department

System Administrator


  _  


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hindle,
Greg
Sent: Monday, December 18, 2006 9:30 PM
To: Weber, Philip; NB List Mail
Subject: Re: [Veritas-bu] Firewall setup

 

OK. So on the firewall you only open ports 13782, 13724 and 13720? And
then configure the clients to use the same 3 ports? All other are
closed?

 

 

Greg 

 


  _  


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weber,
Philip
Sent: Monday, December 18, 2006 10:38 AM
To: NB List Mail
Subject: Re: [Veritas-bu] Firewall setup

We've gone firewall-mad over the last couple of years and now pretty
much all of our clients are behind at least one firewall from the
perspective of the NetBackup servers.  In general we open ports 13782,
13724 and 13720 in both directions, to make life simpler.  This can be
reduced so that only 13782 is open from the DMZ - which is what we do
for clients in the "real" DMZ.  Set the clients to use vnetd, in the
clients tab of the master server properties (or use bpclient).

 

We do occasionally have connection errors and currently have a big issue
in our NB 5.1 MP5 environment, with frequent but irregular "hanging
backups", where the backup has apparently completed but hangs at 99% or
100%.  Seems to be because the final call from the client back to bpbrm
is not being received by the media server.  Seems to be something in our
environment but we are in the process of trying to prove this between
Symantec and our Network support team.

 

Also in some cases have firewalls between media/master servers which is
a whole new problem...

 

Phil Weber 
Business Technology (Egg) 
Storage Technical Services - Senior UNIX Technologist 


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hindle,
Greg
Sent: 18 December 2006 13:06
To: NB List Mail
Subject: [Veritas-bu] Firewall setup

Nb 5.0 mp6 Solaris 9 

We have a DMZ zone setup that has 10 servers in it. We back up these
servers through our firewall. We occasionally get connection errors. I
would like to know if anyone else out there would be interested in
sharing their setup, port ranges etc on how they backup servers through
a firewall.  We currently do not use the firewall section in the host
properties and I am thinking that maybe I should be adding the servers
that are on the other side of the firewall to this tab.

 

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-IP2


  _  


 


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: Laurence Pountney Hill, London EC4R 0HH.


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 app

Re: [Veritas-bu] LTO Labels

[Weber, Philip]

NetBackup and the library don't seem to care...we started using our LTO3 tapes 
with L2 labels as we initially had no L3 labels.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin, Jonathan 
(Contractor)
Sent: 19 December 2006 19:39
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] LTO Labels


Two quick questions... one of our tape vendors prelabeled some of out LTO3 
tapes with ## L2 barcodes.  /sigh  Does Netbackup or the Library really 
care?  2ndly - is there anyway to get Netbackup to ignore the "L#" at the end 
of the barcode? I've got 700 some tapes that are AAA###L3 and Netbackup keeps 
inventorying w/ the last 6 digits.  Can I tell it to use the 1st six?
 
Thanks,
 
-Jonathan

  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keating
Sent: Tuesday, December 19, 2006 12:46 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO3 Read/Write LTO2


 
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Weber, Philip
Sent: December 19, 2006 12:30 PM
To: Wessam Aly; Dave Brown
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO3 Read/Write LTO2


I've also heard that once you've used LTO2 media in an LTO3 drive, you can't 
then read it in an LTO2 drive.  Not sure where I got this from though. 
 
Absolutely 100% false.
I was worried of the same, so I test the hell out of my LTO3 drives before 
putting them into prod. I've got 4x LTO2 drives, and 5x LTO3 drives in each of 
my two libraries, and 100% LTO2 media.been running like that almost a year 
with no problems.
 
I've also got some new LTO3 drives having asked for LTO2...so far they seem to 
be running slower than the LTO2s as I can't supply data to them fast enough 
:-(... time to play with mpx and buffer sizes... 
 
MPX and number of buffers, yeah, but buffer size should be the same (256k) for 
both. 
Get yourself some fast DSUs, VTLs, or use SAN media servers to prestage your 
data..pushing it over 100Meg ethernet isn't going to  do you any favours.
 
Paul




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.



-
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: Laurence Pountney Hill, London EC4R 0HH. 

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  -  

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

[Weber, Philip]

I've also heard that once you've used LTO2 media in an LTO3 drive, you
can't then read it in an LTO2 drive.  Not sure where I got this from
though.
 
I've also got some new LTO3 drives having asked for LTO2...so far they
seem to be running slower than the LTO2s as I can't supply data to them
fast enough :-(... time to play with mpx and buffer sizes...
 
Phil Weber 
Business Technology (Egg) 
Storage Technical Services - Senior UNIX Technologist 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wessam
Aly
Sent: 19 December 2006 17:04
To: Dave Brown
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO3 Read/Write LTO2


Dave.. AFAIK, LTO3 will surely read LTO2 and LTO1 tapes no problem. but
it is not recommended to write with an LTO3 drive on an LTO2 tape. The
densities do make a difference in operation.
 
Some manufacturers also do not officially support it, but either way,
technically you should be able to read/write LTO2 tape with an LTO3
drive, but you'll be limited to the normal LTO2 capacity.
 
Regards,
 
Wessam Aly 
Senior UNIX & Storage Systems Admin. 
HPUX-CSA Certified Systems Administrator 

 

  _  

From: Dave Brown [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 19 December, 2006 16:29
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. 

***
IMPORTANT

Confidentiality: This e-mail communication and any attachments thereto
contain information which is confidential and are intended only for the
use of the individuals or entities named above. If you are not the
intended recipient, you are hereby notified that any disclosure,
copying, distribution or the taking any action in reliance on the
contents of these documents is strictly prohibited and may be illegal.
Please notify us of your receipt of this e-mail in error and delete the
e-mail and any copies of it.

Monitoring/Viruses: Mobinil may monitor all incoming & outgoing e-mails
in line with current legislation. Although we have taken steps to ensure
that this e-mail and attachments are free from any Virus, we advise that
in keeping with good computing practice the recipient should ensure they
are actually virus free.

The Egyptian Company for Mobile Services (Mobinil) 
www.mobinil.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: Laurence Pountney Hill, London EC4R 0HH. 

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
chec

Re: [Veritas-bu] Firewall setup

[Weber, Philip]

We've gone firewall-mad over the last couple of years and now pretty
much all of our clients are behind at least one firewall from the
perspective of the NetBackup servers.  In general we open ports 13782,
13724 and 13720 in both directions, to make life simpler.  This can be
reduced so that only 13782 is open from the DMZ - which is what we do
for clients in the "real" DMZ.  Set the clients to use vnetd, in the
clients tab of the master server properties (or use bpclient).
 
We do occasionally have connection errors and currently have a big issue
in our NB 5.1 MP5 environment, with frequent but irregular "hanging
backups", where the backup has apparently completed but hangs at 99% or
100%.  Seems to be because the final call from the client back to bpbrm
is not being received by the media server.  Seems to be something in our
environment but we are in the process of trying to prove this between
Symantec and our Network support team.
 
Also in some cases have firewalls between media/master servers which is
a whole new problem...
 
Phil Weber 
Business Technology (Egg) 
Storage Technical Services - Senior UNIX Technologist 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hindle,
Greg
Sent: 18 December 2006 13:06
To: NB List Mail
Subject: [Veritas-bu] Firewall setup



Nb 5.0 mp6 Solaris 9 

We have a DMZ zone setup that has 10 servers in it. We back up these
servers through our firewall. We occasionally get connection errors. I
would like to know if anyone else out there would be interested in
sharing their setup, port ranges etc on how they backup servers through
a firewall.  We currently do not use the firewall section in the host
properties and I am thinking that maybe I should be adding the servers
that are on the other side of the firewall to this tab.


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-IP2




-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Storage unit number of drives

[Weber, Philip]

You can set the "Maximum Concurrent drives used for backup" in the
storage unit, but that doesn't give you any control over WHICH drives
are used, which sounds like what you want.  I think you could use
tpconfig to manually set which drives (that the OS can see) are
available to NetBackup, but I'm not sure you could then create a 2nd
storage unit to use the other drives.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave
Markham
Sent: 24 November 2006 11:12
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Storage unit number of drives


Guys is there anyway to create a storage unit and use only a certain
number of drives?

Im Netbackup 5.0mp4 on sol9. I have 5 drives available in a L700 3 of
which are Shared SSO. I want to create a storage unit of 3 drives ( 1
shared and 2 not ) so that a network based job doesnt tie up 2 of the
shared drives and cause my media servers using SSO to fail. Im running
ITC so need 2 drives at a time.

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

-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Upgrade to NBU 6.0 or wait for 6.5...

[Weber, Philip]

Due to the emails I've seen on this list about 6.0 issues, I plan to
stay on 5.1 until I have a pressing need to upgrade or 6.0 seems to have
settled down.  Apparently 6.5 may be multithreaded, which might
influence my decision based on some hardware that is also coming in the
door.  Mind you, that suggests a re-write, so maybe we'll expect lots of
problems with 6.5 when it comes out?
 
Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hampus
Lind
Sent: 23 November 2006 10:44
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Upgrade to NBU 6.0 or wait for 6.5...



Hi all,

 

We run NBU 5.1 and are considering to upgrade to 6.0 in Q1 next year..
But what I have understood Symantec will release NBU 6.5 in summer time
2007. 

Of course there can be delays in 6.5 delivery and it may or may not bee
unstable.. But anyhow, what are your plans if you run 5.1?

 

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]

 




-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] Multithreaded / Multicore CPUs

[Weber, Philip]

Hi,

Does anyone have any experience of running NetBackup on Multithreaded /
Multicore CPUs, or knowledge of whether NetBackup can multithread to
take advantage of such hardware?  Maybe more important is how the OS
would allocate CPU resources to the tape drives & NICs ... any
ideas/experience would be helpful.

Thinking of upgrading media servers to Sun T2000s, but getting
conflicting opinions of whether it would perform.
Would be NetBackup 5.1, Solaris 10.

thanks, Phil

Phil Weber
Business Technology (Egg)
Storage Technical Services - Senior UNIX Technologist



-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Recognise Media from NBU

[Weber, Philip]

We take tapes out regularly, using a script that checks which tapes
aren't going to expire until a certain month.  When the script ejects
these, it changes the volume group for the tape to be the month name.
The tape then goes in the box similarly labelled with the month name.

When a restore requests a tape that is out of the library, the device
monitor (vmoprcmd -d pr) will show what volume group is allocated to it,
and hence which box it is in, so it can easily be found.

Of course this is still dependent on people putting the tapes in the
right boxes, and I've had problems with that :-) - it's great fun going
through all the boxes comparing the tapes with where NetBackup thinks
they are!

hope this helps... ours is all on UNIX & so possibly easier to script.

Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WEAVER,
Simon
Sent: 09 November 2006 06:30
To: 'Darren Dunham'
Cc: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Recognise Media from NBU



Darren
Ok to prevent any further confusion..

Tapes are in an ESL Robotic Library WITH barcodes :-)

Now, each month at least 40 - 50 tapes are taken out of the library,
placed
in cases and stored in a safe.
On the outside case, they label the tape "MONTH XX" - So they know a
backup
was performed at the end of each month.

The trouble they appear to be having.. When a restore is needed from
a
month end tape, they have to go searching for the tape or tapes that are
needed.

Now. My argument to this would be to "Label the tape with the Month
number
PLUS the volume pool it came from" - for example if it's a file server,
the
volume would come from the "File_Server_Month_Pool" - However they
cannot do
this as it's a time consuming task.

Now, my other argument was to "start a restore" which would then say in
the
Activity Monitor "tape L3 required" - then they could load the tape.
I
thought this would be ok, but again seems to be a problem for them.

So My question was "Is there an EASIER method or command that could
be
used to identify what tape is needed for a restore BEFORE you actually
start
the restore"? If not, then I see 2 options:

1) Use Activity Monitor and when prompted, load the applicable tape or
tapes
2) Label the tape from the corresponding pool number

I should point out, this is not just a safe, its more like a vault with
THOUSANDS of tapes. Maybe the issue lies within the site (ie: better
organisation of tapes perhaps)? 

Anyhow, that was the question I may have answered it myself, but if
there is another easy method ?

Thanks

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: Darren Dunham [mailto:[EMAIL PROTECTED] 
Sent: 08 November 2006 18:41
To: Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Recognise Media from NBU


> One of our libraries has over 40 tapes taken out each and every month 
> to be stored in a safe.
>  
> Trouble is, it is a time consuming process to label each tape (not 
> that I mind too much!).

But they do or don't have barcodes?  What type of label do you put on
the
tape?

> Anyhow, is there an EASY method or way to tell What data is on a tape 
> via a command line without the need to load the single tape into the 
> library?
>
> I could go through tapes one by one, but is there an easier method I 
> am overlooking?

I'm not sure I understand what information you want.  

What information goes on your labels?  Many sites just track all tapes
by
barcode.

There's lots of information to gather on the command line, but I
wouldn't
normally put it on the tape itself.

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://www.taos.com/
Got some Dr Pepper?   San Francisco, CA bay area
 < This line left intentionally blank to confuse you. >
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

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 and do
not use it for any purpose or disclose its content to any person, but
delete this message and any attachments from your system. Astrium
disclaims any and all liability if this email transmission was virus
corrupted, altered or falsified.
-
Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
England
___
Ve

Re: [Veritas-bu] How to get SSO SAN Media Server LTO Drives back*without* rebooting ?

[Weber, Philip]

Haven't got SAN Media Servers but have got SSO & I have had some luck
getting drives back by unloading and reloading the sg driver.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Wilkinson, Alex
Sent: 06 November 2006 03:07
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] How to get SSO SAN Media Server LTO Drives
back*without* rebooting ?


Hi all,

We are consistently having to reboot our servers (both windows and unix)
to get
our LTO3 SSO drives back (after they mysteriously disappear).

Scenario:

For one reason or another we loose a drive and to get it back for
example we
powercycle our library and our NB master can now see the drive(s),
however, our
SAN Media servers cannot see the drives unless we reboot them. This is
*bad* -
_really_ bad. These are production servers and cannot be rebooted on a
whim.

So the question:
=-=-=-=-=-=-=-=

Can anyone recommend how to get SAN Media Servers to see their SSO
drives again
*without* having to reboot ?

We are running NB-6.0-MP3 both Solaris and Windows 2003 Masters.

Regards

 -aW

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

-
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: Laurence Pountney Hill, London EC4R 0HH. 

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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Running bpbkar32 from the command line

[Weber, Philip]

Bit of a problem if you've got icmp (and ftp, and...) disabled between
most servers & clients like we have.  Is there anything similar that can
work over the NetBackup ports which obviously will be open?

Phil

-Original Message-
From: Martin, Jonathan (Contractor) [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 18, 2006 11:25 AM
To: Ellis, Jason
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Running bpbkar32 from the command line




When doing performance analysis Veritas has given me a utility called
SAS which runs with a few options and creates an .xml file which they
then run through some program which spits out a .pdf.  The tool utilizes
ICMP so its much easier to use than anything port based and its given me
some very good feedback when trying to utilize 100% of our gigabit
pipes.  Between the bpbkar utility and SAS utility I've been able to
identify many bottlenecks and it assists greatly when performance tuning
your network options.  For my money its much better to isolate the local
disk with bpbkar32 > null then the network pipe w/ SAS than to use
bpbkar32 in an actual backup setting and try to read log files.

-Jonathan
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ellis,
Jason
Sent: Monday, October 16, 2006 7:03 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Running bpbkar32 from the command line

Got a good one for the group...

We're trying to do some bottleneck testing and are running into a
problem with the FTP ports being closed down on our Windows systems,
thus we cannot really test the network between the clients and media
servers. We're trying to see if we can kick off bpbkar32 manually to
just move a single file to disk on the media server to test the network
like and FTP would.

I know we test the client side locally by running:

bpbkar32 -nocont [file_path_to_test] 1> nul 2> nul

I also know that bpbrm is the process responsible for starting bpbkar32
and passes all the information bpbkar32 needs to start the backup. One
thought is to enable the bpbrm log file and see what options are being
passed, however if anybody out there has already done this and can give
me a breakdown of running bpbkar32 manually that would be great!

Thanks in advanced!

Jason Ellis
Technical Consultant, Backup & Recovery
Corp-IT Operations, La Mirada Datacenter IndyMac Bank
Phone: (714) 520-3414



___
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

-
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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] Solaris 10 Zones

[Weber, Philip]

Title: Solaris 10 Zones






Hi all,


I'm fairly new to Solaris 10 & trying to work out the best way to back up a Solaris 10 server with local zones (NetBackup 5.1).  Any suggestions or pointers to best practice?

It seems that by default :

1.  the global backup will include nearly everything, including lofs filesystems mounted in the local zones, and ufs filesystems mounted in the local zone (by the global) or mounted in the local zone on devices exported from the global zone.

2.  the local zone backup will include next to nothing, only non-inherited package directories (e.g. /) and ufs filesystems (duplicate - also backed up from the global).

So I think we have several options :

1.  Treat global and local zones as "normal" servers in "normal" polcies, so global zone does majority of the backup.  Use exclude lists to exclude any ufs filesystems from local zone backup.  Downside is global zone won't know about local zone application status e.g. Oracle (without RMAN).

2.  Use ufs f/s in the local zones for data directories so they can be backed up locally.  Exclude these from the global backup.  Downside is dependent on people remembering to exclude new filesystems.

3.  Exclude f/s or directory containing the local zones, from the global zone backup.  Schedule the backups from the local zone or use bpstart_notify to generate backup streams for the f/s you want including lofs.  One downside is can't do incrementals to user schedules.

Or is there a way of telling NetBackup to back up lofs filesystems?

Or have I missed something?


thanks, Phil


Phil Weber

Business Technology (Egg)

Storage Technical Services - Senior UNIX Technologist

Phone: 01384 26 4136

Mobile: 07748 333503

Jabber: [EMAIL PROTECTED]







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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] renaming a media server

[Weber, Philip]

Title: Message



I 
think you could build a new media server (new name), before removing the 
media server from the app server.  Then use "bpmedia -movedb" to change 
ownership of all backup images owned by the old media server, to the new media 
server.  Then decommission the app server media server.
 
I 
haven't tried this though and am waiting for someone to shoot me down in 
flames...

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  Haskins, SteveSent: 17 October 2006 21:16To: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] renaming a 
  media server
  
  My application support person, if 
  all of their wisdom, wants to have their app server rebuilt but remove media 
  server from it. Originally it was made a media server coexisting with the app 
  because of the TBs of data it was to house. They want to keep the same host 
  name for their app so I would have to change the host name for the “new” media 
  server. Is there any way of keeping all previous backups in renaming a media 
  server WITHOUT importing the media afterward?
   
  Thanks in 
  advance.




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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU_SNAP issue

[Weber, Philip]

Title: Message



Does 
nbu_snap support ufs filesystem?

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  Evsyukov, SergeySent: 16 October 2006 09:47To: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] NBU_SNAP 
  issue
  Hello, we have business important issue with 
  advanced client.
   
  OS - Solaris 
  9
  NBU - 
  5.1MP2
  SNAPSHOT METHOD - 
  NBU_SNAP
  Backup failed with STATUS = 156 In 
  ~/log/online_util/log.101606 we have found: 11:57:43.833 [24864] <2> 
  onlfi_vfms_logf: INF - nbu_snap_freeze: Cannot turn on snapshot; snapshot 
  source=/export, cache =/dev/vx/rdsk/bishouse_dg_01/bishouse_vol_01, snap 
  error=5 11:57:43.834 [24864] <4> delete_mount_point: INF - Deleted 
  mount point /tmp/_vrts_frzn_img__export_24864 11:57:43.834 [24864] 
  <32> onlfi_freeze_fim_fs: FTL - VfMS error 11; see following messages: 
  11:57:43.834 [24864] <32> onlfi_freeze_fim_fs: FTL - Fatal method 
  error was reported 11:57:43.834 [24864] <32> onlfi_freeze_fim_fs: 
  FTL - vfm_freeze: method: nbu_snap, type: FIM, function: nbu_snap_freeze 
  11:57:43.834 [24864] <32> onlfi_freeze_fim_fs: FTL - VfMS method 
  error 5; see following message: 11:57:43.834 [24864] <32> 
  onlfi_freeze_fim_fs: FTL - nbu_snap_freeze: Cannot turn on snapshot; snapshot 
  source=/export, cache=/dev/vx/rdsk/snapshot_dg/snapshot_vol, snap error=5 
  
   
  When we have tryed to create snapshot from CLI, 
  we have got: [EMAIL PROTECTED] # 
  /usr/openv/netbackup/bin/driver/snapon /export 
  /dev/vx/rdsk/bishouse_dg_01/bishouse_vol_01 matched /export to mnttab 
  entry /export mount device: /dev/vx/dsk/exportdg/export fstype: ufs snapon 
  on /export failed err=11 snerrno=5 
   
  In /var/adm/messages we have found: Oct 16 
  12:18:40 sf6800a snapctl: [ID 803675 kern.warning] WARNING: addcache: id 22604 
  cache path = /dev/vx/rdsk/bishouse_dg_01/bishouse_vol_01 Oct 16 12:18:45 
  sf6800a snapctl: [ID 389476 kern.warning] WARNING: addcache: sn_freecache 
  failed, cache path = /dev/vx/rdsk/bishouse_dg_01/bishouse_vol_01, err = 5, 
  block 16777216 Oct 16 12:18:45 sf6800a snapctl: [ID 470943 kern.warning] 
  WARNING: addsnap: sn_addcache failed err=5 
  snc_path=/dev/vx/rdsk/bishouse_dg_01/bishouse_vol_01 Oct 16 12:18:45 
  sf6800a snapctl: [ID 576187 kern.warning] WARNING: ioctl_snapon: ioctl_snapon 
  failed error 5 Oct 16 12:18:45 sf6800a snapctl: [ID 209424 kern.warning] 
  WARNING: ioctl_snapon: son_snapof=/dev/vx/rdsk/exportdg/export 
  son_cache=/dev/vx/rdsk/bishouse_dg_01/bishouse_vol_01 
   
  /dev/vx/rdsk/bishouse_dg_01/bishouse_vol_01 seems 
  good:
   
  [EMAIL PROTECTED] # 
  dd if=/dev/zero of=/dev/vx/rdsk/bishouse_dg_01/bishouse_vol_01 bs=65536 
  count=10241024+0 records in1024+0 records out
   
  What can be reason 
  of problem?
   
  Thanks for any 
  help, Sergey




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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Log Files filling disk space

[Weber, Philip]

Title: Message



These 
are log files for the robot services.  If I recall, they will create a log 
file for each day.  You can create under debug the directories tpcommand, 
reqlib, ltid and daemon and different logs will be written to each.  You 
should be able to delete old log files, but if you want to delete the current or 
turn off logging by deleting or renaming the debug directory, you will have to 
bounce the services, otherwise they will fall over when they get to midnight and 
try to cycle the logs.

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of WEAVER, 
  SimonSent: 13 October 2006 08:24To: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] Log Files 
  filling disk space
  Guys
  I have been running an applet to check the folder / file structure for 
  a drive where NBU 5.1 is installed on a Win2k3 
  Server
   
  I came across program files\veritas\netbackup\volmgr\debug and folders 
  called Daemon and ltid which is holding 1GB of log 
  files.
   
  reading these, they look safe to delete - they go back from 2005 to 
  present.
   
  Could I please get clarification this is not going to impact anything 
  within NBU - they end in .log so I believe I am safe, but nice to get 
  confirmation of this.
   
  Thank you
   
  Regards
  Simon 
  Weaver3rd Line Technical SupportWindows Domain 
  Administrator 
  EADS Astrium 
  Limited, B23AA IM (DCS)Anchorage Road, Portsmouth, PO3 
  5PU
  Email: 
  [EMAIL PROTECTED]
   
  


  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 and do not use it for any purpose or 
disclose its content to any person, but delete this message and any 
attachments from your system. Astrium disclaims any and all liability if 
this email transmission was virus corrupted, altered or 
falsified.-Astrium 
Limited, Registered in England and Wales No. 2449259Registered 
Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, 
England




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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Client Hostnames

[Weber, Philip]

We couldn't get that to work.  Wanted to back up Exchange on our host
"host" using its backup IP "host-bk", because it was behind a firewall.
Always got error 71 or 69 (sorry, can't remember which was in which
circumstance now).  Eventually created a local host alias on the
master/media servers to set "host" to IP of "host-bk" and it worked.
Doesn't seem to make any sense in the context of NetBackup but I can
only assume that Exchange somehow knows what name it has been called
with & is looking for databases with that name.

Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ed Wilts
Sent: 30 September 2006 15:24
To: Hillman, Eric
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Client Hostnames


On 9/29/2006 11:44 AM, Hillman, Eric wrote:
> I may have found one issues when using aliases however. Can anyone
> confirm that you CANNOT use an alias of the server name when backing
> up an Exchange server/cluster?

I will confirm that you CAN use an alias.  We have a separate backup
interface on our Exchange servers and we're backing them up just fine
using that interface.  Different interface and different DNS entry to
point to it.

> From what I'm reading, the netbackup client needs to reference the
> Exchange application using the actual hostname used when installing
> Exchange in order to successfully access the specified storage
> groups.  This would mean that the actual hostname of the box needs to
> be added to the Netbackup Policy and not a "-backup" hostname.

This is false.

Almost everything in our environment is backed up via DNS entries
pointing to interface on a dedicated backup network.  The only
exceptions are very small, very old systems that don't have an extra nic
available and no room to put one.

 ../Ed
-- 
Ed Wilts, Mounds View, MN, USA
mailto:[EMAIL PROTECTED]

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

-
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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] LTO3 and Disk Staging

[Weber, Philip]

Title: Message



Trouble acquiring decent hardware.
 
Interested though, is that concurrent operation, i.e. writing at these 
speeds and reading at these speeds concurrently?  I'm not familiar with 
bonnie++.
 
cheers, Phil

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Tim 
  BergerSent: 27 September 2006 22:37To: Joe 
  RoyerCc: veritas-bu@mailman.eng.auburn.eduSubject: Re: 
  [Veritas-bu] LTO3 and Disk StagingOn 9/25/06, Joe Royer <[EMAIL PROTECTED]> 
  wrote:
  
  As 
one of the others to ask this question, here are my findings so 
far:- Most people aren't keeping their LTO3 happy, some even falling 
victimto the marketing crap that "LTO technology isn't harmed by 
shoeshining." I have personally seen a 20-25% (per month) drive failure 
rate in anenvironment of constant shoeshining on LTO1.- Software 
striping of multiple LUNs may be a good quick fix or stop 
gapsolution.  Especially if you can aggregate your FC 
interfaces this way. - A few have mentioned that they started using FC 
disk because SATA wastoo slow.
  I have no trouble at all keeping LTO3 streaming with SATA R5 or R0 
  array staging areas.Here's a bonnie++ report from such a raid 
  (R0).  197MB/sec writes, 240MB/sec reads.  Fast enough for LTO3 or 
  LTO4, for that matter. Version  
  1.03  --Sequential Output-- --Sequential 
  Input- 
  --Random-    
  -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
  --Seeks--Machine    Size K/sec %CP 
  K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP 
  fiik 
  4G   197803  67 
  95682  24   
  240898  23 589.0   1Oridnary 7200 RPM 300GB disks on a 
  3ware 9k series raid controller.Maybe some people are having touble 
  acquiring decent hardware or configuring their raids. 7200 RPM 
  SATA drives will never be as fast as 1 RPM SCSI drives, but IMHO they're 
  perfect for staging because they're fast enough when striped and cheap.  
  Using FC for staging area seems wrong somehow.  They're crazy expensive 
  for use as scratch space. -snip--- -Tim 





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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Netbackup for Unix - Code 11 - Call Failures

[Weber, Philip]

You can still get error 11 if you're using some other kind of snapshot
technology e.g. Advanced client with nbu_snap.  We had a bespoke binary
from Veritas/Symantec to fix this, which is resolved in 5.1 MP5.

Otherwise I've not had error 11 with our RMAN backups.  A good thing to
check is that the NetBackup client and NetBackup for Oracle client are
up to date at the same maintenance pack level as the master/media.

cheers, Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WEAVER,
Simon
Sent: 26 September 2006 14:45
To: 'Justin Piszcz'
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Netbackup for Unix - Code 11 - Call Failures



Justin
Yed, Ed Wilts emailed me directly on this.

Sorry guys, was trying to help! Never claimed I knew anything about
Unix,
but wanted to try and help!

Apologies in advance

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: Justin Piszcz [mailto:[EMAIL PROTECTED] 
Sent: 26 September 2006 14:44
To: WEAVER, Simon
Cc: '[EMAIL PROTECTED]';
veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Netbackup for Unix - Code 11 - Call Failures


Simon, there is no OTM for UNIX :)



On Tue, 26 Sep 2006, WEAVER, Simon wrote:

>
> Rob
> Are you using Veritas Snapshot Provider or OTM as it was known in the 
> early days.
>
> Also check this out
>
> http://forums.veritas.com/discussions/thread.jspa?messageID=4451718
> 
>
> May or May Not help! Also, what if you try to perform the backup 
> manually? same issues?
>
>
>
> 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]
> Sent: 26 September 2006 12:54
> To: veritas-bu@mailman.eng.auburn.edu
> Subject: [Veritas-bu] Netbackup for Unix - Code 11 - Call Failures
>
>
>
> I'm running Veritas Netbackup v5.0 MP6 on a Sun V880 OS Solaris 9 
> server configured and used solely as the Master Server and I am 
> getting irregular Status Code 11 - Call Failures when running Oracle 
> rman online backups on various Client servers.  Sometimes they work Ok

> and sometimes they don't. Does anyone know why or have any ideas that 
> might resolve this problem?
>
> Regards
> Robert Anderson
> Unix Administrator
> Work: 01283 502522
> Email: [EMAIL PROTECTED]
>
> DISCLAIMER:
>
> This e-mail contains proprietary information some or all of which may 
> be legally privileged. It is for the intended recipient only.
>
> If an addressing or transmission error has misdirected this e-mail, 
> please notify the author by replying to this e-mail.
>
> If you are not the intended recipient you must not use, disclose, 
> distribute, copy, print, or rely on this e-mail.
>
> E-mail is an informal method of communication and is subject to 
> possible data corruption.
>
> For these reasons it will normally be inappropriate to rely upon 
> information contained in an e-mail without obtaining tangible written 
> confirmation of it.
>
>
>
>
>
> This email is for the intended addressee only.
> If you have received it in error then you must not use, retain, 
> disseminate or otherwise deal with it. Please notify the sender by 
> return email. The views of the author may not necessarily constitute 
> the views of Astrium Limited. Nothing in this email shall bind Astrium

> Limited in any contract or obligation.
>
> Astrium Limited, Registered in England and Wales No. 2449259 
> Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 
> 2AS, England

This email is for the intended addressee only.
If you have received it in error then you must not use, retain,
disseminate or otherwise deal with it.
Please notify the sender by return email.
The views of the author may not necessarily constitute the views of
Astrium Limited.
Nothing in this email shall bind Astrium Limited in any contract or
obligation.

Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
England
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

-
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 
resp

Re: [Veritas-bu] LTO3 and Disk Staging

[Weber, Philip]

I've done lots of dd tests to/from the disk outside of NetBackup, using
individual LUNs and various filesystems configured in various RAID
configurations.  Also going by the manufacturer's spec sheets sa to what
I can expect max (150 Mb/s).  Performance issues manifest themselves as
soon as I try to write multiple streams to a disk staging filesystem
whilst also reading off it, though the attempted speed of the writes is
probably greater (from /dev/random) than I would expect from my
NetBackup clients.  But it's only got ATA drives.  Because the
performance is bad before I bring NetBackup into the mix, I haven't
looked much at tuning NetBackup yet.

My fastest backups are across the SAN fabric using Advanced Client & 4
streams will run to 1 tape driving it at about 50 Mb/s which may be the
drive limit (LTO2).

-Original Message-
From: Ed Wilts [mailto:[EMAIL PROTECTED] 
Sent: 22 September 2006 12:37
To: Weber, Philip
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO3 and Disk Staging


On 9/22/2006 4:19 AM, Weber, Philip wrote:
> What sorts of disk systems are people using as disk staging to keep
> LTO3s happy?  

We're using HP EVA with FATA (Fibre ATA) drives.  We don't drive the 
LTO3s at full speed, but I do not believe it's an EVA issue.

> 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.

What sorts of benchmarks have you done to prove that it's a disk issue? 
  Have you done something like a dd to see how fast you can read data 
from the disk?  Have you monitored your switch ports?  I've witnessed 
our NetBackup environment hit 150MB/sec on our master server's 2Gbps 
switch port doing a dd from the DSSU to /dev/null.  My destaging 
performance to LTO-3 is normally quite poor so I know I've got a 
NetBackup issue somewhere.

> We have pretty much a 24*7 backup window with lots of slow & small,
> slow & big, and some fast, clients.

I think that describes most of us...  Do your fast clients drive the LTO

directly at a good speed?

.../Ed

-- 
Ed Wilts, Mounds View, MN, USA
mailto:[EMAIL PROTECTED]


-
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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] LTO3 and Disk Staging

[Weber, Philip]

I meant splitting a mirrored DSU & keeping the mirror on the same media
server, just mounted separately.  I haven't really thought it through
:-) & it would probably need expensive SAN options to enable the mirrors
to have separate I/O paths to the server.  And NetBackup would still
have problems over the changing paths to the disk images.  Maybe a
non-starter.

I've been through most of the performance stats & my CX is definitely
the bottleneck at the moment.  The media servers are adequate though
if/when I have adequate performance out of the CX or its replacement
(possibly VTL) they will need further HBAs & NICs to stop those becoming
bottlenecks.

I've been through the archives... a separate CX for each media server
would help more than more media servers... hence trying to get a feel
for what disk systems people are having success with.

cheers, Phil

-Original Message-
From: Peter DrakeUnderkoffler [mailto:[EMAIL PROTECTED] 
Sent: 22 September 2006 10:48
To: Weber, Philip
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO3 and Disk Staging


-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: [EMAIL PROTECTED]
> 
> -
> 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 
>

Re: [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout

[Weber, Philip]

My understanding of CentricStor is that NetBackup only knows about 
CentricStor's virtual tape devices.  CentricStor offlines virtual tapes to 
physical tape as and when the virtual tapes become full, and NetBackup knows 
nothing about where the data is on physical tapes.

Interested, because we're looking at CentricStor.

What happens with the tape mount timeout?  Does the restore request go into a 
"waiting for operator to load tape" state and have to be manually resubmitted 
once the VTL has finished pulling the data back?

Phil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keating
Sent: 21 September 2006 19:01
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media Mount Timeout


My point, I suppose, is that if your data isn't on the VTL, it should be on 
tape.
Netbackup should already know this, and pull the data direct from the tape.

A higher timeout would treat the symptom, but this whole idea of pulling the 
data back from tape to the VTL exacerbates the problem which most people 
implement VTL to curenamely time to restore.

Paul

-- 


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: September 21, 2006 1:55 PM
> To: Paul Keating
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, 
> Media Mount Timeout
> 
> 
> Paul,
> 
> I wonder too :-( Mainly a timeout of more than 5 minutes 
> would help, but as explained, the NBU internal timeout does 
> not seem to work... 
> 
> Help appreciated :-)
> 
> 
> Cheers, 
> 
> Mirko
> 
> 
>  
> On Thursday, September 21, 2006, at 07:43PM, Paul Keating 
> <[EMAIL PROTECTED]> wrote:
> 
> >I'm wondering what kind of (mis)configuration is responsible 
> for media
> >having to be pulled back to the VTL to do a restore.
> >
> >Sounds painful.
> >
> >Paul
> >
> >-- 
> >
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED] 
> >> [mailto:[EMAIL PROTECTED] On Behalf 
> >> Of [EMAIL PROTECTED]
> >> Sent: September 21, 2006 12:46 PM
> >> To: veritas-bu@mailman.eng.auburn.edu
> >> Subject: [Veritas-bu] Windows 2003, NBU 6.0MP3, VTL, Media 
> >> Mount Timeout
> >> 
> >> 
> >> Hi all,
> >> 
> >> another kind of a problem, that may be a bug in NBU? Expert help 
> >> appreciated! 
> >> 
> >> We're using NetBackup 6.0 on a Windows 2003 Server Master Server. 
> >> The Server is connected to a FJS CentricStore VTL, emulating 
> >> 8 Exabyte 
> >> Mammooth drives with a capacity of 20Gb each. The drives are 
> >> integrated 
> >> into a NBU logical library using TL8 as the drive 
> controlling type... 
> >> 
> >> The problem: 
> >> Whenever a media is requested, that does not reside in the 
> >> VTL cache, the 
> >> media content has to be staged in transparently by the VTL 
> >> software, leading 
> >> to an NBU robot error media timeout message! We tried to 
> >> increase the MEDIA_MOUNT_TIMEOUT using the GUI, but the 
> >> timeout still appears after 6 minutes, 
> >> regardless of the setting... the windows system log complains 
> >> about a sempahore 
> >> timeout! To me it seems like the MEDIA_MOUNT_TIMEOUT is not 
> >> working correctly or 
> >> is it only suitable for ACS managed or other drive? Maybe 
> >> there is also some different configuration setting on the 
> >> Windows or TL8 side? 
> >> 
> >> Besides this we wonder about the fact, that mounting of the 
> >> tape media is beeing retried using another tape drive. Is 
> >> there any configuration value that controls this? We already 
> >> experimented with "Restore Retries = 0" & "Retry Interval =1"...
> >> 
> >> Thanks for help! 
> >> 
> >> Kind regards, 
> >> 
> >> Mirko 
> >> 
> >> 
> >> ___
> >> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> >> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> >> 
> >=
> ===
> >
> >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 destina

[Veritas-bu] LTO3 and Disk Staging

[Weber, Philip]

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: [EMAIL PROTECTED]

-
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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] NBU 5.1 MP5 Flashbackup using nbu_snap

[Weber, Philip]

Title: Message



We're 
using advanced client for offhost backups, using nbu_snap (using the media 
server as the data mover, not doing Flashbackup).  Currently only on MP4, 
haven't got around to MP5 yet though it is supposed to include fixes for some of 
the issues we have had, namely :
 
1.  Doesn't work properly with vnetd, so some traffic still attempts 
to go over random ports.  A problem if you have a firewall between your 
media server and client.
2.  Cache size was limited to < 1 Tb (not sure why we found this, 
we're not using anything like this size cache now).
3.  Filesystem size was limited to < 2 Tb (may still 
be).
4.  Backups were failing when files changed in size during the 
backup (rather than ending with a status code 1).
 
I have 
found that occasionally the cache will not be cleared down if a backup fails, 
though haven't bottomed out exactly how it has to fail for this to be the 
case.  So it may be worth writing some scripts to monitor the status of the 
cache & snapshotted filesystems.
 
So in 
your example, A, B and C should all run but sometimes if B fails it won't clear 
up properly ... and if the cache is then not empty enough for C, it will also 
fail.  It should start, because as I understand it the cache is only used 
as changes are made to the original filesystem.
 
cheers, Phil

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Dyck, 
  JonathanSent: 28 August 2006 15:17To: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] NBU 5.1 MP5 
  Flashbackup using nbu_snap
  
  All,
  Anyone have any "gotchas" to report using block level, copy-on-write 
  backups using the nbu_snap (Solaris only) method with NBU 5.1 MP5's 
  Advanced Client?
   
  I'm 
  getting closer to implementation time here, and my biggest concern is the 
  cache size at the moment.  
   
  One 
  thing I'm concerned about is using a single job to back up all raw disk 
  devices on the system.  In the event of a full cache and subsequent 
  failed backup on a particular stream, can anyone confirm that the cache will 
  clear prior to the next stream in the file list for the job?  Or does the 
  job have to be restarted completely?
   
  Here's the scenario...
   
  Job 
  list is:
   
  /dev/rdsk/A
  
  /dev/rdsk/B
  
  /dev/rdsk/C
   
  Where A is successful,  B fills up 
  the cache and craps out.  Does C start?
   
  Thanks,
  Jon 
   
  (in an environment where I can't just plug 
  in a cache that's as big as my largest disk 
  unfortunately)
   
   This message may contain privileged and/or 
  confidential information.  If you have received this e-mail in error or 
  are not the intended recipient, you may not use, copy, disseminate or 
  distribute it; do not open any attachments, delete it immediately from your 
  system and notify the sender promptly by e-mail that you have done so.  
  Thank you. 




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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] waiting....

[Weber, Philip]

Title: Message



Sort of related ... when I try to shut down 
NetBackup 5.1 there are almost invariably disk duplication jobs running.  
If I kill these from the GUI they immediately spawn new jobs.  Even after 
bp.kill_all there are processes running because the duplication jobs have 
respawned ... is there a clean way to kill duplication?  Normally I have to 
kill the processes manually.
 
thanks, Phil

  
  -Original 
  Message-From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  [EMAIL PROTECTED]Sent: 24 August 2006 02:19To: 
  [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
  veritas-bu@mailman.eng.auburn.eduSubject: Re: [Veritas-bu] 
  waiting
  You can make this a lot 
  cleaner by adding a pre-shutdown job that cancels all running backup jobs and 
  waits for them to go away.  If there's no active jobs, the daemons drop 
  pretty quick.  I wrote a utility called "nice_shutdown" that does 
  this.
   
  Kill -9 will stray 
  tapes in drives and lead to all sorts of other happy 
  problems.
   
  -M
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Bob 
  StumpSent: Wednesday, August 23, 2006 5:49 AMTo: Simon 
  WEAVER; veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] 
  waiting
  
  The question is when I attempt to shutdown NetBackup I get 57 lines 
  of:
  Waiting for active bpsched/bptm processes to terminate
  How can I tell which bpsched/bptm process that it is waiting 
  on.
  How can I tell if the bpched/bptm process it is waiting on will 
  eventually terminate via the shutdown.
   
  It's kind of like the question "How many licks does it take to get to the 
  center of a Tootsie Roll pop"? no one knows. 
  No one knows the answer to this question because we all get impatient and 
  just start doing a mass kill -9 on any bpsched/bptm we see.
   
  I am asking this to see if there may be a better way than 
  # kill -9 `bpps | awk '{print $2}'`
   
  The cleanup after the kill gets annoying and also is very time 
  consuming.
  logging onto the ACSLS server and doing dismounts of the 
tapedrives.
  yuk...
   
  >>> "WEAVER, Simon" 
  <[EMAIL PROTECTED]> 8/23/2006 1:36 AM >>>
  
  Bob
  not sure what you are after, but what 
  about stopping all services / processes or rebooting perhaps??
  Was there any more info to add to the 
  message? Or am I missing something?
   
   
  Regards
  Simon Weaver3rd Line Technical SupportWindows Domain 
  Administrator 
  EADS Astrium Limited, 
  B23AA IM (DCS)Anchorage Road, Portsmouth, PO3 5PU
  Email: [EMAIL PROTECTED]
  

-Original Message-From: Bob Stump 
[mailto:[EMAIL PROTECTED] Sent: 22 August 2006 
17:30To: veritas-bu@mailman.eng.auburn.eduSubject: 
[Veritas-bu] waiting
What is actually happening and how can you tell if it is actually waiting or forever hung?Waiting for active bpsched/bptm processes to terminateWaiting for active bpsched/bptm processes to terminateWaiting for active bpsched/bptm processes to terminateWaiting for active bpsched/bptm processes to terminateWaiting for active bpsched/bptm processes to terminateWaiting for active bpsched/bptm processes to terminateWaiting for active bpsched/bptm processes to terminateWaiting for active bpsched/bptm processes to terminate
  


  This email is for the intended 
addressee only.If you have received it in error then you must not 
use, retain, disseminate or otherwise deal with it.Please notify the 
sender by return email.The views of the author may not necessarily 
constitute the views of Astrium Limited.Nothing in this email shall 
bind Astrium Limited in any contract or obligation.Astrium 
Limited, Registered in England and Wales No. 2449259Registered 
Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, 
England




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 

Re: [Veritas-bu] Is this possible ....

[Weber, Philip]

We use the Advanced Client add-on for 5.1 (another licence - name may be
changed in v6.0).  One of our media servers is configured to see the
same SAN disks as the servers which we want to back up.  Throughput
seems to be very roughly twice what we would get over the 1 GB LAN.
Nothing is mounted to the media server but the Advanced Client client
effectively passes over the network to the media server a list of
locations of blocks to back up, which the media server then sources
directly from the SAN.

There are a lot of different options in Advanced Client and dependencies
over what volume management, switches etc. etc. you can use, so read up
on it first.  It's also might be an issue that all the SAN disks are
visible from multiple places.  There are also differences in the way
RMAN backups work using Advanced Client, which advise thorough testing.
Works quite well for us though.

cheers, Phil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew
Stier
Sent: 27 July 2006 16:34
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Is this possible 


Back in January, I replace my old SCSI attached tape library. I now have

an Overland Storage NEO8000 with 6 drives, plus a REO9000 which is 
sliced into multiple 1TB partitions which I have mounted on my media 
server (Sun Microsystems Ultra Enterprise 450 running Solaris 8 and 
NetBackup 5.1mp5) to use as DSSU's.

In the next two months, I will be switching from systems with direct 
attached drives, (which I backup over the network) to a full SAN.

Do I continue as I have? Backing up the clients over the (1000Base-T) 
network?

Can the DSSU partition be shared between the client and the media 
server, and client write directly to the DSSU, and the media server 
write it to tape?

Can the media server mount the clients (SAN) volume, and back it up to 
the DSSU directly.  (Although I see this option fought with backup 
management issues.)



-
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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Solais 10 client on 4.5?

[Weber, Philip]

Title: Message



We are 
backing up Solaris 10 clients to a NetBackup 4.5 master (using the NBU 4.5 
client).  Only problem is, they end with status 1 as the client doesn't 
understand the fs type of /system/contract and /system/object - putting these or 
/system in the exclude list doesn't help.  So potentially this will mask 
any other files that are failing & would normally cause a status 
1.
 
There's more thinking to be done if you are using Solaris zones, around 
what you want to back up in each zone - I haven't really played with that 
yet.
 
Phil

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Major, 
  RustySent: 27 July 2006 23:55To: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] Solais 10 
  client on 4.5?
  Has anyone had 
  success with a Solaris 10 client on a 4.5 Master? We are attempting to do one 
  with a 5.1MP3 client but I'm running into problems. I'm currently not sure if 
  it's due to Solaris 10, the newer client version, or something else (I'm 
  betting on something else as we've used a newer version on 64bit clients 
  with success).
   
  Thanks!
   
  
  Rusty Major, MCSE, BCFP
  Data Assurance Engineer
  (281) 584-4693
  VeriCenter, Inc.
   




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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Updating UNIX clients from the master server.

[Weber, Philip]

Title: Message



I 
don't think so.  With versions of Oracle previous to 8i the libobk.so 
libraries were linked into Oracle which might have been a problem for updating 
the NetBackup Agent for Oracle from the master server, but I have not had 
problems with the UNIX client update and the Oracle linking is simpler from 8i 
up.
 
Phil

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Whelan, 
  PatrickSent: 17 July 2006 13:55To: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] Updating 
  UNIX clients from the master server.
  All,
  One more question. Is 
  anyone aware of a problem updating UNIX clients running Oracle 8 from the 
  master server? I have been told that Oracle holds some of the lib 
  files open so the update can not succeed. Is this true?
  Regards,
  Patrick Whelan
  NetBackup 
  Specialist
  Architect & 
  Engineering
  +44 20 7863 5243
  Of all the things I've lost, I 
  miss my mind the most! - Unknown
  There are only 10 kinds of people 
  on earth - those who understand binary
  and those who 
  don't.
  *The 
  message is intended for the named addressee only and may not be disclosed to 
  or used by anyone else, nor may it be copied in any way. The contents 
  of this message and its attachments are confidential and may also be subject 
  to legal privilege. If you are not the named addressee and/or have received 
  this message in error, please advise us by e-mailing [EMAIL PROTECTED] and 
  delete the message and any attachments without retaining any copies. 
  Internet communications are not secure and COLT does not accept 
  responsibility for this message, its contents nor responsibility for any 
  viruses. No contracts can be created or varied on behalf of COLT 
  Telecommunications, its subsidiaries or affiliates ("COLT") and any other 
  party by email Communications unless expressly agreed in writing with such 
  other party. Please note that incoming emails will be automatically 
  scanned to eliminate potential viruses and unsolicited promotional emails. For 
  more information refer to www.colt.net or contact us on +44(0)20 7390 
3900.




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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] status 1 (was: Typical success rates?)

[Weber, Philip]

I did once look into all of our Status 1 results and had several along
the lines of "it's a WINS server and the WINS DB failed" ... sounded
important to me.  Unfortunately, Status 1 is still at the bottom of my
list of things to look at in terms of priority, because there are too
many things above it :-)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Lightner
Sent: 30 June 2006 12:49
To: WEAVER, Simon; [EMAIL PROTECTED];
veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] status 1 (was: Typical success rates?)


Status 1 is not a failure UNLESS it's a database backup.  For
filesystems everywhere I've been we've shown that a status 1 is not a
failure but a warning.  Unfortunately you won't get Veritas to
officially confirm that.

Some things I've seen cause a status 1: 
Open files.
Files changed between the time the list for backup and the actual write
to tape occurred.
Sun "Door" files.

We verified extensively at a job that required FDA Validation that
restores from such backups were indeed complete to the point in time the
backup was started.  At that job we simply had to document that a status
1 was a success for all but database backups.

Note that due to the status 1 scheduling tools Tivoli Work Scheduler
(Maestro) that show abends for non zero exit status need to be massaged.
You basically have to have the Maestro job script check for status 1 and
mark exit the script with status 0 to prevent this.  "exit 0" is all you
have to do in a script to make this work.  It took me a while to get our
schedulers to understand this concept but once they did and I gave them
the syntax they were able to avoid reported abends for this.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WEAVER,
Simon
Sent: Friday, June 30, 2006 4:16 AM
To: '[EMAIL PROTECTED]'; veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] status 1 (was: Typical success rates?)


Bob
As the image is stored in the DB, I still see Status 1 as a good backup.

As long as you can get the data that needs to be backed up, and you
identify
the reason for the "1" you have 2 options in my view:

1) exclude the file/files that are causing the status code
2) Investigate and if not relevant, revert to point 1.

Anything higher is what I class a failure.
Regards

Simon Weaver
3rd Line Technical Support
Windows Domain Administrator 

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

Email: [EMAIL PROTECTED]



-Original Message-
From: bob944 [mailto:[EMAIL PROTECTED] 
Sent: 30 June 2006 08:13
To: veritas-bu@mailman.eng.auburn.edu; WEAVER, Simon
Subject: RE: [Veritas-bu] status 1 (was: Typical success rates?)


> Exclude the "1"'s as I dont class them as failures :-)

Which might be why NetBackup defines stat 1 as "partial success" _and
keeps
the image_.  Final status <= 1 yields a restorable image; status > 1
does
not (archives excluded).  I think we agree that stat 1 beats the heck
out of
stat > 1.

That said, Operations can not accept a stat 1 without investigation.
What is
a status 1--is it one of the 15-odd conditions in the Status 1 section
of
the NetBackup Troubleshooting Guide?  Is it "just another goofy Windows
busy
perfdat file?"  The definition Ops must apply is "of all the files which
were to be backed up, some were and some were not."


Example A:
Files to be backed up (seletion minus excludes plus includes:  1,000,000
Files backed up:  999,999 Files not backed up:  1
Status:  1

Example B:
Files to be backed up (seletion minus excludes plus includes:  1,000,000
Files backed up:  1 Files not backed up:  999,999
Status:  1

Hence the BBP requirement that intelligence, artificial or human, be
applied
to stat 1s every time.


This email is for the intended addressee only.
If you have received it in error then you must not use, retain,
disseminate or otherwise deal with it.
Please notify the sender by return email.
The views of the author may not necessarily constitute the views of EADS
Astrium Limited.
Nothing in this email shall bind EADS Astrium Limited in any contract or
obligation.

EADS Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
England
___
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

-
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 enter

Re: [Veritas-bu] Typical success rates?

[Weber, Philip]

Title: Message



We get 
around 4% failures, and that is only due to continuing focus on backups.  
The product is not at fault though, more our infrastructure as a whole (i.e. 
networks and firewalls) and hetrogeneous server estate.

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Tristan 
  BallSent: 30 June 2006 08:15To: Whelan, Patrick; 
  veritas-bu@mailman.eng.auburn.eduSubject: Re: [Veritas-bu] Typical 
  success rates?
  For me it depends on the site. And at the moment, on the 
  netbackup version.
   
  At my small sites, backing up 3-5 clients, we get 100% 
  success 80-90% of nights. On the nights that we see failures, it's usually one 
  stream that fails, not a whole server. These are fairly static 
  sites.
   
  At my "large" site, with about 30 clients, I get a 
  failure or two most night - but this is mostly environmental rather 
  than NB itself. It's machines that have been moved, changed or disconnected. 
  But of those 30 machines, many are secondary machines, development servers or 
  workstations - basically, subject to a reasonably large amount of 
  change.
   
  And I have to say that 5.1mp2+ is a lot more reliable 
  than 6.0mp?, especially when it comes to the scheduler.
   
  Regards,
      
  T.
   
  ---
  Tristan Ball
  System Administrator
  Vision Systems
  +61-3-9211-7064
   
   
  
  
  From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Whelan, 
  PatrickSent: Friday, 30 June 2006 3:48 AMTo: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] Typical 
  success rates?
  
  All,
  Do 
  you usually have a 100% success every backup session? If not what is a 
  typical success rate?
  Regards,
  Patrick Whelan
  NetBackup 
  Specialist
  Architect & 
  Engineering
  +44 20 7863 5243
  Of all the things I've lost, I 
  miss my mind the most! - Unknown
  There are only 10 kinds of people 
  on earth - those who understand binary
  and those who 
  don't.
  *The 
  message is intended for the named addressee only and may not be disclosed to 
  or used by anyone else, nor may it be copied in any way. The contents 
  of this message and its attachments are confidential and may also be subject 
  to legal privilege. If you are not the named addressee and/or have received 
  this message in error, please advise us by e-mailing [EMAIL PROTECTED] and 
  delete the message and any attachments without retaining any copies. 
  Internet communications are not secure and COLT does not accept 
  responsibility for this message, its contents nor responsibility for any 
  viruses. No contracts can be created or varied on behalf of COLT 
  Telecommunications, its subsidiaries or affiliates ("COLT") and any other 
  party by email Communications unless expressly agreed in writing with such 
  other party. Please note that incoming emails will be automatically 
  scanned to eliminate potential viruses and unsolicited promotional emails. For 
  more information refer to www.colt.net or contact us on +44(0)20 7390 
3900.




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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Policy Time Grapher

[Weber, Philip]

Title: Message



I 
wrote a perl script some time ago which parsed the output from "bppllist -U 
-allpolicies" into a CSV file, to give to management as something which listed 
all of our backup definitions.  It could be a starting point for something 
like this, with a bit of work in VBA I expect to create an Excel macro, to 
"prettify" it some more.

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Locke, 
  MatSent: 27 June 2006 16:56To: 
  'veritas-bu@mailman.eng.auburn.edu'Subject: [Veritas-bu] Policy 
  Time Grapher
  Hi all. I'm a first time submitter. I haven't seen 
  anything come through since I've been watching this subscription but our team 
  needs a little help. 
   
  I'm looking for a 
  product or application that can take all of our policy start and finish 
  windows and graphically present them to us so when we make new policies or add 
  clients, it makes it easier. We are also trying to split out our production, 
  test, and dev environments so prod gets a higher priority. 

   
  Here is an 
  example of something we did in excel but it's a manual process and takes a 
  huge amount of time.  
  (not sure if the screen shot will come 
  through) 
   
  
  
   
  Here is what we 
  have in our environment.
  Veritas NetBackup 5.1 MP4
  Solaris 9 / 64 bit
   
  Any 
  help or direction would be greatly appreciated.
   
  Thanks,
  Mathew 
  LockeSystems Engineer, Data Center Storage ManagementThe TriZetto 
  Group, Inc.
  Denver, 
  Colorado




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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Fronting backups with disk then bleeding off to tape.

[Weber, Philip]

Issues we have had using disk staing at 5.1MP4 include
   o disk staging jobs returning with errors if
  - no images are found (i.e. staging is complete)
  - an image listed for duplication is not found (maybe it was
expired during the staging activity)
  - configured to do more staging jobs concurrently than there are
drives available (continually produces jobs which fail in error).
   o Exchange backups failing because staging f/s runs out of space &
isn't cleared quickly enough (NBU clears the two oldest duplicated
images regardless of their size).  Not *proved* that this was the
problem...
   o Performance issues due to backup window overrun (out backups often
run on into the day) - and the disk array not being able to cope with
multiple writes and reads.  Still struggling with this one

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin
Piszcz
Sent: 20 June 2006 17:06
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] Fronting backups with disk then bleeding off to
tape.


Does anyone do this with a massive amount of data?  Also, I noticed with

5.1MP4 its possible to use multiple streams to bleed from disk->tape but
I 
was wondering how well this worked practice.

How many people bleed off to tape using 5.1MPx?
Using 6.0?

How well does it work under 6 vs. 5? I know there is a watermark
feature. 
Also, how come when I bled data off to tape under 5.1MP4, it did not 
remove the images from disk?  Must I manually purge that data?

Thanks,

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

-
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@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Netbackup Device Configuration problems :-(

[Weber, Philip]

Title: RE: [Veritas-bu] Netbackup Device Configuration problems :-(






I've occasionally found it necessary to delete everything NetBackup knows about the attached robots and drives, and re-scan from scratch, using the steps below.  Seems a bit drastic, but it does the job and the configuration ends up clean.

Re-map Drives and Robots into NetBackup


For example, after moving drives or PCI cards around in media servers you will need to go through this process to ensure all the paths match, between the OS, robotic tools and Net Backup : 


Do the necessary to get the OS up to date, i.e. remove /dev/rmt entries and reconfigure reboot. 

Check how many drives can be seen using sgscan tape. Depending, it may not be necessary to reinstall the sg driver. 

Re-install the (Veritas) sg driver. 



rem_drv sg 

rm /kernel/drv/sg.conf 

/usr/openv/volmgr/bin/driver/sg.install 

Check all drives can now be seen using sgscan tape. 


On each media server, delete all drive definitions from the Media Manager. 



List Net Backup drive numbers using tpconfig -d 

Delete each using tpconfig -delete -drive {n} e.g. tpconfig -delete -drive 0. 


ON each media server, delete all robot definitions from the Media Manager. 



List Net Backup robot numbers using tpconfig -d 

Delete each using tpconfig -delete -robot {n} e.g. tpconfig -delete -robot 0. 0 for gorilla, baboon, 1 for lemur, gibbon, grivet. 


At this point vmglob -listall -java on any media server should return nothing, indicating that the Global Device Database has been synchronised after everything has been deleted. If not, try to delete remaining entries manually using vmglob -delete -drive -name , etc. - from the master server. 

Get Net Backup to scan for all attached devices using tpautoconf -a. Or use the GUI "Configure Storage Devices" wizard. 

At this point tpconfig -d will show all devices with default names e.g. DLT70001. 

stopltid 

ltid -v 

Use the tpreq command to test mount as many tapes as possible, then tpunmount to unmount them. 


regards, Phil


Phil Weber

Egg plc, Senior UNIX Technologist



-Original Message-

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of WEAVER, Simon

Sent: 06 June 2006 06:18

To: 'veritas-bu@mailman.eng.auburn.edu'

Subject: [Veritas-bu] Netbackup Device Configuration problems :-(



Guys

After now removing all storage units for my old media servers that were totally destroyed, I have installed NBU on the newly named media servers and attempted to run the device configuration utility from my Master.

I have attempted to scan both new hosts but each one comes up with the following message


The error message reported is "Could not get device configuration. Cannot discover devices. see the troubleshooting guide for details (44)." I received an OK box.

When clicking this, the Device Configuration Wizard asks "Device discovery failed on host Server001 do you wish to proceed - I say NO. Saying YES brings up the 1st message and the device configuration fails to continue as it cannot see the robot.

This occurs whether I scan a single host, multiple hosts or ALL 3 hosts (Master as well).


Under Media & Device Management, Devices, Robots and hosts I can see entries for SERVER001 and 002 - I wonder if someone has tried to configure the devices, and its failed somewhere along the lines and now NetBackup cannot understand what is happening?

Currently doing a backup of my SAN devices over LAN for now.


Regards

Simon Weaver

3rd Line Technical Support

Windows Domain Administrator 

EADS Astrium Limited, B32AA IM (DCS)

Anchorage Road, Portsmouth, PO3 5PU

Email: [EMAIL PROTECTED]


This email is for the intended addressee only.

If you have received it in error then you must not use, retain, disseminate or otherwise deal with it.

Please notify the sender by return email.

The views of the author may not necessarily constitute the views of EADS Astrium Limited.

Nothing in this email shall bind EADS Astrium Limited in any contract or obligation.


EADS Astrium Limited, Registered in England and Wales No. 2449259

Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England << File: ATT765405.txt >> 







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

[Veritas-bu] Windows Scripting of bprestore

[Weber, Philip]

Title: Message





Hi all, has anyone tried using bprestore from a Windows 
client?
 
A colleague wants to use bprestore to restore 
permissions only, for a set of files, restoring to a new directory.  We are 
having trouble getting the renaming to work.
 
NetBackup 4.5 FP 9, Solaris master & media servers 
 I will probably try running the restore from the master but am interested in 
getting the Windows command line to work.
 
thanks, Phil




Egg is a trading name of the Egg group of companies which includes: Eggplc (reg no2448340), 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.

RE: [Veritas-bu] NetBackup Reporting

[Weber, Philip]

Title: Message





I 
report off the output from bpdbjobs -all_columns which shows the eventual status 
code together with the number of attempts (plus all the other information 
available as in the activity monitor).  bperror will have separate entries 
for each attempt, which I guess is what you are using?

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Piszcz, 
  JustinSent: 13 December 2005 12:23To: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] NetBackup 
  Reporting
  
  Does anyone have a script that 
  will ONLY report clients that REALLY failed?
  I have retries set to 12, even 
  though they never usually go past this number (maybe one or two retries on a 
  few clients) – I have two/three scripts that show them as failures, while in 
  reality they are error(41s) or file read failed(13) which retry and run 
  successfully.
  Does anyone have a full-proof 
  reporting script?
   
  Justin.




Egg is a trading name of the Egg group of companies which includes: Eggplc (reg no2448340), 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.

RE: [Veritas-bu] Multiple data streams

[Weber, Philip]

Title: Message





A lot 
of our clients are on 100 meg interfaces & we get better performance out of 
our tape drives if we do not multistream, but do multiplex.  Otherwise the 
streams aren't coming from the clients fast enough to keep the tape drives 
streaming nicely, without increasing the multiplexing levels too 
high.

  
  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Piszcz, 
  JustinSent: 11 November 2005 14:27To: Hindle, Greg; 
  veritas-bu@mailman.eng.auburn.eduSubject: RE: [Veritas-bu] Multiple 
  data streams
  
  There are reasons in 
  certain instances.
   
  Example: You want the 
  fastest restore’s possible, then you would not want to use 
  multiplexing.
  Example: If you mean 
  multiple data streams per client, you only want to run one stream per physical 
  device or else the heads would be going nuts if you do more than one per 
  disk.
   
   
  
  
  
  
  From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Hindle, GregSent: Friday, November 11, 2005 8:55 
  AMTo: 
  veritas-bu@mailman.eng.auburn.eduSubject: [Veritas-bu] Multiple data 
  streams
   
   
  Is there a time or situation where 
  you would NOT want to use multiple data streams?   Greg 
  Hindle Constellation Energy 
  Data Management & Recovery 
  Front St. 
  410-291-5715 [EMAIL PROTECTED] 
    
    
  >>> This e-mail and any attachments are confidential, may contain legal,professional or other privileged information, and are intended solely for theaddressee.  If you are not the intended recipient, do not use the informationin this e-mail in any way, delete this e-mail and notify the sender. CEG-IP2




Egg is a trading name of the Egg group of companies which includes: Eggplc (reg no2448340), 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.