Re: [Veritas-bu] Suspend or Freeze media

[WEAVER, Simon (external)]

Hi Matt,
My understanding is this
 
If a volume is SUSPENDED the system will not write to it until all the
backup images on that volume have expired. (either automatically or if
manual expiry which can be carried out using the command tool BPEXPDATE)

If a volume is frozen the system will not write to it even after all the
backup images on that volume have expired. This means there could well be a
problem with the Media. When expired the media report in Netbackup will say
Frozen Expired. If I get too many frozen tapes, I can unfreeze and use them
again. But if they continually fail, remove them from the library.
 

Regards

Simon Weaver
3rd Line Technical Support
Windows Domain Administrator 

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

Email:   [EMAIL PROTECTED]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weathers,
Matt
Sent: Wednesday, November 21, 2007 7:52 PM
To: 'Veritas-bu@mailman.eng.auburn.edu'
Subject: [Veritas-bu] Suspend or Freeze media


We are trying to phase our our LTO 2 tapes as we go to LTO 3. My thought is
that I will freeze or suspend the tapes and when they expire we can remove
them from service. Does this seem logical? Also, is there a way to freeze a
range of tapes? I do not have a good understanding of freezing/suspending
media. From what I read it appears that once a frozen tape expires it comes
back into service and a suspended tape never expires. I am interested in
knowing thoughts on the best way to remove the media from service.
 
Matt Weathers
Senior Systems Programmer
Farm Bureau Insurance of Michigan
  
[EMAIL PROTECTED]  
Office: (517) 391-5021
Fax: (517) 323-6793
 



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] T2000 vaulting performance with VTL/LTO3

[Peters, Devon C]

For our SAN media servers, we do see restore performance gains with this
setting.  The difference between the default setting, and 512 has been
around 20% for us.  We haven't done a whole lot of tuning or analisys on
this - I just set it to match NUMBER_DATA_BUFFERS.  :)

For our less high-performance backups (i.e. anything going over the
network) I've never looked into it.

-devon

-Original Message-
From: Justin Piszcz [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 21, 2007 4:05 PM
To: Peters, Devon C
Cc: Mike Andres; VERITAS-BU@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

Has anyone here done benchmarks to see what type of potential speed up
is 
gained with the NUMBER_DATA_BUFFERS_RESTORE directive?

On Wed, 21 Nov 2007, Peters, Devon C wrote:

> I just did a test, and it looks like the duplication process uses
> NUMBER_DATA_BUFFERS for both read and write drives.  I'm guessing that
> there's just a single set of buffers used by both read and write
> processes, rather than a separate set of buffers for each process...
>
> Config on the test system:
>
> # cat /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS
> 256
> # cat /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS_RESTORE
> 128
>
>
> Here's the bptm io_init info from the duplication - PID 22020 is the
> write process,  PID 22027 is the read process:
>
> 10:43:20.523 [22020] <2> io_init: using 262144 data buffer size
> 10:43:20.523 [22020] <2> io_init: CINDEX 0, sched Kbytes for
monitoring
> = 2
> 10:43:20.524 [22020] <2> io_init: using 256 data buffers
> 10:43:20.524 [22020] <2> io_init: child delay = 20, parent delay = 30
> (milliseconds)
> 10:43:20.524 [22020] <2> io_init: shm_size = 67115012, buffer address
=
> 0xf39b8000, buf control = 0xf79b8000, ready ptr = 0xf79b9800
> 10:43:21.188 [22027] <2> io_init: using 256 data buffers
> 10:43:21.188 [22027] <2> io_init: buffer size for read is 262144
> 10:43:21.188 [22027] <2> io_init: child delay = 20, parent delay = 30
> (milliseconds)
> 10:43:21.188 [22027] <2> io_init: shm_size = 67115060, buffer address
=
> 0xf39b8000, buf control = 0xf79b8000, ready ptr = 0xf79b9800, res_cntl
=
> 0xf79b9804
>
>
> Also, there are no lines in the bptm logfile showing
> "mpx_setup_restore_shm" for these PIDs...
>
> -devon
>
> 
>
> From: Mike Andres [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 21, 2007 9:49 AM
> To: Justin Piszcz
> Cc: Peters, Devon C; VERITAS-BU@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>
>
> Thanks.  I guess my question could be more specifically stated as
"does
> the duplication process utilize NUMBER_DATA_BUFFERS_RESTORE or
> NUMBER_DATA_BUFFERS."   I don't have a system in front of me to test.
>
> 
>
> From: Justin Piszcz [mailto:[EMAIL PROTECTED]
> Sent: Wed 11/21/2007 8:58 AM
> To: Mike Andres
> Cc: Peters, Devon C; VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>
>
>
> Buffers in memory to disk would be dependent on how much cache the
raid
> controller has yeah?
>
> Justin.
>
> On Wed, 21 Nov 2007, Mike Andres wrote:
>
>> I'm curious about NUMBER_DATA_BUFFERS_RESTORE and duplication
> performance as well.  Anybody know this definitively?
>>
>> 
>>
>> From: [EMAIL PROTECTED] on behalf of Peters,
> Devon C
>> Sent: Tue 11/20/2007 1:32 PM
>> To: VERITAS-BU@mailman.eng.auburn.edu
>> Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>>
>>
>>
>> Chris,
>>
>> To me it looks like there's a 1Gb bottleneck somewhere (90MB/s is
> about all we ever got out of 1Gb fibre back in the day).  Are there
any
> ISL's between your tape drive, your switch, and your server's HBA?
> Also, have you verified that your tape drives have negotiated onto the
> fabric as 2Gb and not 1Gb?
>>
>> When we had 2Gb LTO-3 drives on our T2000's, throughput to a single
> drive toped out around 160MB/s.  When we upgraded the drives to 4Gb
> LTO-3, throughput to a single drive went up to 260MB/s.  Our data is
> very compressible, and these numbers are what I assume to be the
> limitation of the IBM tape drives.
>>
>> Regarding buffer settings, my experience may not apply directly since
> we're doing disk (filesystems on fast storge) to tape backups, rather
> than VTL to tape.  With our setup we see the best performance with a
> buffer size of 1048576 and 512 buffers.  For us these buffer sizes are
> mostly related to the filesystem performance, since we get better disk
> throughput with 1MB I/O's than with smaller ones...
>>
>> I'm also curious if anyone knows whether the
> NUMBER_DATA_BUFFERS_RESTORE parameter is used when doing duplications?
> I would assume it is, but I don't know for sure.  If it is, then the
> bptm process reading from the VTL would be using the default 16 (?)
> buffers, and you might see better performance by using a lar

Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

[Justin Piszcz]

Has anyone here done benchmarks to see what type of potential speed up is 
gained with the NUMBER_DATA_BUFFERS_RESTORE directive?

On Wed, 21 Nov 2007, Peters, Devon C wrote:

> I just did a test, and it looks like the duplication process uses
> NUMBER_DATA_BUFFERS for both read and write drives.  I'm guessing that
> there's just a single set of buffers used by both read and write
> processes, rather than a separate set of buffers for each process...
>
> Config on the test system:
>
> # cat /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS
> 256
> # cat /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS_RESTORE
> 128
>
>
> Here's the bptm io_init info from the duplication - PID 22020 is the
> write process,  PID 22027 is the read process:
>
> 10:43:20.523 [22020] <2> io_init: using 262144 data buffer size
> 10:43:20.523 [22020] <2> io_init: CINDEX 0, sched Kbytes for monitoring
> = 2
> 10:43:20.524 [22020] <2> io_init: using 256 data buffers
> 10:43:20.524 [22020] <2> io_init: child delay = 20, parent delay = 30
> (milliseconds)
> 10:43:20.524 [22020] <2> io_init: shm_size = 67115012, buffer address =
> 0xf39b8000, buf control = 0xf79b8000, ready ptr = 0xf79b9800
> 10:43:21.188 [22027] <2> io_init: using 256 data buffers
> 10:43:21.188 [22027] <2> io_init: buffer size for read is 262144
> 10:43:21.188 [22027] <2> io_init: child delay = 20, parent delay = 30
> (milliseconds)
> 10:43:21.188 [22027] <2> io_init: shm_size = 67115060, buffer address =
> 0xf39b8000, buf control = 0xf79b8000, ready ptr = 0xf79b9800, res_cntl =
> 0xf79b9804
>
>
> Also, there are no lines in the bptm logfile showing
> "mpx_setup_restore_shm" for these PIDs...
>
> -devon
>
> 
>
> From: Mike Andres [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 21, 2007 9:49 AM
> To: Justin Piszcz
> Cc: Peters, Devon C; VERITAS-BU@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>
>
> Thanks.  I guess my question could be more specifically stated as "does
> the duplication process utilize NUMBER_DATA_BUFFERS_RESTORE or
> NUMBER_DATA_BUFFERS."   I don't have a system in front of me to test.
>
> 
>
> From: Justin Piszcz [mailto:[EMAIL PROTECTED]
> Sent: Wed 11/21/2007 8:58 AM
> To: Mike Andres
> Cc: Peters, Devon C; VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>
>
>
> Buffers in memory to disk would be dependent on how much cache the raid
> controller has yeah?
>
> Justin.
>
> On Wed, 21 Nov 2007, Mike Andres wrote:
>
>> I'm curious about NUMBER_DATA_BUFFERS_RESTORE and duplication
> performance as well.  Anybody know this definitively?
>>
>> 
>>
>> From: [EMAIL PROTECTED] on behalf of Peters,
> Devon C
>> Sent: Tue 11/20/2007 1:32 PM
>> To: VERITAS-BU@mailman.eng.auburn.edu
>> Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>>
>>
>>
>> Chris,
>>
>> To me it looks like there's a 1Gb bottleneck somewhere (90MB/s is
> about all we ever got out of 1Gb fibre back in the day).  Are there any
> ISL's between your tape drive, your switch, and your server's HBA?
> Also, have you verified that your tape drives have negotiated onto the
> fabric as 2Gb and not 1Gb?
>>
>> When we had 2Gb LTO-3 drives on our T2000's, throughput to a single
> drive toped out around 160MB/s.  When we upgraded the drives to 4Gb
> LTO-3, throughput to a single drive went up to 260MB/s.  Our data is
> very compressible, and these numbers are what I assume to be the
> limitation of the IBM tape drives.
>>
>> Regarding buffer settings, my experience may not apply directly since
> we're doing disk (filesystems on fast storge) to tape backups, rather
> than VTL to tape.  With our setup we see the best performance with a
> buffer size of 1048576 and 512 buffers.  For us these buffer sizes are
> mostly related to the filesystem performance, since we get better disk
> throughput with 1MB I/O's than with smaller ones...
>>
>> I'm also curious if anyone knows whether the
> NUMBER_DATA_BUFFERS_RESTORE parameter is used when doing duplications?
> I would assume it is, but I don't know for sure.  If it is, then the
> bptm process reading from the VTL would be using the default 16 (?)
> buffers, and you might see better performance by using a larger number.
>>
>>
>> -devon
>>
>>
>> -
>> Date: Fri, 16 Nov 2007 10:00:18 -0800
>> From: Chris_Millet <[EMAIL PROTECTED]>
>> Subject: [Veritas-bu]  T2000 vaulting performance with VTL/LTO3
>> To: VERITAS-BU@mailman.eng.auburn.edu
>> Message-ID: <[EMAIL PROTECTED]>
>>
>>
>> I'm starting to experiment with the use of T2000 for media servers.
> The backup server is a T2000 8 core, 18GB system.  There is a Qlogic
> QLE2462 PCI-E dual port 4Gb adapter in the system that plugs into a
> Qlogic 5602 switch.  From there, one port is zoned to a EMC CDL 4400
> (VTL) and a few HP LTO3 tape drives.  The connecti

Re: [Veritas-bu] Suspend or Freeze media

[Marianu, Jonathan]

Part 1 of 2

Matt,

This applies to 5.1 and below.

Also, triple check all advice because I could be wrong. I don't have access to 
production NBU systems so this is from memory and my notes. Also I am writing 
without providing a full explanation. So I will include some notes at the 
bottom for you to review.

And learn some basic awk. A few days of learning awk will save you weeks of 
typing. I train other NBU admins and that is one of the first things they learn.


--My comments--

Freezing and suspending are media attributes stored in the media database on 
the media server.
See field 15 of bpmedialist -l.

This is important because it means it does not impact the image db on the 
master.
The images will expire regardless of the media's attribute unless you change 
the image expiration (bpexpdate)

A frozen media is never put back into service unless you manually unfreeze it.
I think suspended moves back when the images expire, but I'm not 100% certain.

Another thing to remember is you can only freeze assigned media because only 
assigned media is stored in a media database. 

So to phase out LTO2:
 
-Make a copy of volDB on the master and the mediaDB on the media servers so 
that you can roll back.

-identify which LTO2 media is assigned (storing images) and which media is not 
assigned.
# vmquery -pn SCRATCH -l | awk '{print $1}'
This should list the unassigned media

-remove the Scratch LTO2 media from the library and sync the volDB.

-If you have expired tapes outside the library, use vmdelete to remove them 
from volDB.

-freeze the remaining LTO2 media using "bpmedia -m MEDIAID -h MEDIA_SERVER_NAME"


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

Re: [Veritas-bu] Suspend or Freeze media

[Marianu, Jonathan]

Part 1 of 2

 

Matt,

 

This applies to 5.1 and below.

 

Also, triple check all advice because I could be wrong. I don't have
access to production NBU systems so this is from memory and my notes.
Also I am writing without providing a full explanation. So I will
include some notes at the bottom for you to review.

 

And learn some basic awk. A few days of learning awk will save you weeks
of typing. I train other NBU admins and that is one of the first things
they learn.

 

 

--My comments--

 

Freezing and suspending are media attributes stored in the media
database on the media server.

See field 15 of bpmedialist -l.

 

This is important because it means it does not impact the image db on
the master.

The images will expire regardless of the media's attribute unless you
change the image expiration (bpexpdate)

 

A frozen media is never put back into service unless you manually
unfreeze it.

I think suspended moves back when the images expire, but I'm not 100%
certain.

 

Another thing to remember is you can only freeze assigned media because
only assigned media is stored in a media database. 

 

So to phase out LTO2:

 

-Make a copy of volDB on the master and the mediaDB on the media servers
so that you can roll back.

 

-identify which LTO2 media is assigned (storing images) and which media
is not assigned.

# vmquery -pn SCRATCH -l | awk '{print $1}'

This should list the unassigned media

 

-remove the Scratch LTO2 media from the library and sync the volDB.

 

-If you have expired tapes outside the library, use vmdelete to remove
them from volDB.

 

-freeze the remaining LTO2 media using "bpmedia -m MEDIAID -h
MEDIA_SERVER_NAME"

 

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

Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

[Marianu, Jonathan]

My recollection is that during duplication from VTL to tape , it uses
the mpx originally set in the policy unless it is throttled down by the
vault policy but you can't increase it. The MPX is what is so
interesting to examine in truss because I observed that any multiplexing
will impact the duplication speed.

 

This is impact more pronounced though when you are mixing slow and fast
clients together because the fragments are not spread out evenly on the
virtual tape and bptm has to rewind the virtual tape and reread, causing
a delay to physical library which is torture on the physical tape drive

 

Then I observed that a higher MPX led to a slight improvement in
duplication speed. I would use 24-32

However there are other tradeoffs. In the end we decided to not use VTL
for network client backups for the new master server environment model. 

A problem with VTLis that a slow client backup will hold onto the
vritual media preventing me from using it for duplication. This impacts
the RPO of other clients backups. DSU does not have that issue.

We use 64TB EVA file systems per network media server which give pretty
even performance and we use vxfs.

One outstanding issue with file systems that you don't have with VTL is
fragmentation Another benefit of VTL is that I have a media server
dedicated to writing the backups and another media server dedicated to
duplicating backups.

.


__
Jonathan Marianu (mah ree ah' nu)
AT&T Storage Planning and Design Architect
(360) 597-6896
Work Hours 0800-1800 PST M-F

Manager: David Anderson
(314) 340-9296

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

Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

[Peters, Devon C]

I just did a test, and it looks like the duplication process uses
NUMBER_DATA_BUFFERS for both read and write drives.  I'm guessing that
there's just a single set of buffers used by both read and write
processes, rather than a separate set of buffers for each process...
 
Config on the test system:
 
# cat /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS
256
# cat /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS_RESTORE
128

 
Here's the bptm io_init info from the duplication - PID 22020 is the
write process,  PID 22027 is the read process:
 
10:43:20.523 [22020] <2> io_init: using 262144 data buffer size
10:43:20.523 [22020] <2> io_init: CINDEX 0, sched Kbytes for monitoring
= 2
10:43:20.524 [22020] <2> io_init: using 256 data buffers
10:43:20.524 [22020] <2> io_init: child delay = 20, parent delay = 30
(milliseconds)
10:43:20.524 [22020] <2> io_init: shm_size = 67115012, buffer address =
0xf39b8000, buf control = 0xf79b8000, ready ptr = 0xf79b9800
10:43:21.188 [22027] <2> io_init: using 256 data buffers
10:43:21.188 [22027] <2> io_init: buffer size for read is 262144
10:43:21.188 [22027] <2> io_init: child delay = 20, parent delay = 30
(milliseconds)
10:43:21.188 [22027] <2> io_init: shm_size = 67115060, buffer address =
0xf39b8000, buf control = 0xf79b8000, ready ptr = 0xf79b9800, res_cntl =
0xf79b9804

 
Also, there are no lines in the bptm logfile showing
"mpx_setup_restore_shm" for these PIDs...
 
-devon



From: Mike Andres [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 21, 2007 9:49 AM
To: Justin Piszcz
Cc: Peters, Devon C; VERITAS-BU@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] T2000 vaulting performance with VTL/LTO3


Thanks.  I guess my question could be more specifically stated as "does
the duplication process utilize NUMBER_DATA_BUFFERS_RESTORE or
NUMBER_DATA_BUFFERS."   I don't have a system in front of me to test.



From: Justin Piszcz [mailto:[EMAIL PROTECTED]
Sent: Wed 11/21/2007 8:58 AM
To: Mike Andres
Cc: Peters, Devon C; VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3



Buffers in memory to disk would be dependent on how much cache the raid
controller has yeah?

Justin.

On Wed, 21 Nov 2007, Mike Andres wrote:

> I'm curious about NUMBER_DATA_BUFFERS_RESTORE and duplication
performance as well.  Anybody know this definitively?
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Peters,
Devon C
> Sent: Tue 11/20/2007 1:32 PM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>
>
>
> Chris,
>
> To me it looks like there's a 1Gb bottleneck somewhere (90MB/s is
about all we ever got out of 1Gb fibre back in the day).  Are there any
ISL's between your tape drive, your switch, and your server's HBA?
Also, have you verified that your tape drives have negotiated onto the
fabric as 2Gb and not 1Gb?
>
> When we had 2Gb LTO-3 drives on our T2000's, throughput to a single
drive toped out around 160MB/s.  When we upgraded the drives to 4Gb
LTO-3, throughput to a single drive went up to 260MB/s.  Our data is
very compressible, and these numbers are what I assume to be the
limitation of the IBM tape drives.
>
> Regarding buffer settings, my experience may not apply directly since
we're doing disk (filesystems on fast storge) to tape backups, rather
than VTL to tape.  With our setup we see the best performance with a
buffer size of 1048576 and 512 buffers.  For us these buffer sizes are
mostly related to the filesystem performance, since we get better disk
throughput with 1MB I/O's than with smaller ones...
>
> I'm also curious if anyone knows whether the
NUMBER_DATA_BUFFERS_RESTORE parameter is used when doing duplications?
I would assume it is, but I don't know for sure.  If it is, then the
bptm process reading from the VTL would be using the default 16 (?)
buffers, and you might see better performance by using a larger number.
>
>
> -devon
>
>
> -
> Date: Fri, 16 Nov 2007 10:00:18 -0800
> From: Chris_Millet <[EMAIL PROTECTED]>
> Subject: [Veritas-bu]  T2000 vaulting performance with VTL/LTO3
> To: VERITAS-BU@mailman.eng.auburn.edu
> Message-ID: <[EMAIL PROTECTED]>
>
>
> I'm starting to experiment with the use of T2000 for media servers.
The backup server is a T2000 8 core, 18GB system.  There is a Qlogic
QLE2462 PCI-E dual port 4Gb adapter in the system that plugs into a
Qlogic 5602 switch.  From there, one port is zoned to a EMC CDL 4400
(VTL) and a few HP LTO3 tape drives.  The connectivity is 4Gb from host
to switch, and from switch to the VTL.  The tape drive is 2Gb.
>
> So when using Netbackup Vault to copy a backup done to the VTL to a
real tape drive, the backup performance tops out at about 90MB/sec.  If
I spin up two jobs to two tape drives, they both go about 45MB/sec.   It
seems I've hit a 90MB/sec bottleneck somehow.  I have v240s per

Re: [Veritas-bu] Suspend or Freeze media

[Martin, Jonathan]

Actually, the other way around.  Suspended media cannot be written to by
Netbackup until all the images on it expire.  Sort of a logical "tape
write protect" - until the expiration date.  Then it goes back to
unassigned / into the scratch pool.  Freezing a media means Netbackup
will never expire or write to that media again.  I'm not sure if the
actual images expire or not, but the media itself will stay assigned in
that pool until it's unfrozen.  The easiest way to suspend or freeze
media is with the bpmedia command.  I generally do this kind of thing
via batch command.

 

-Jonathan

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Weathers, Matt
Sent: Wednesday, November 21, 2007 2:52 PM
To: 'Veritas-bu@mailman.eng.auburn.edu'
Subject: [Veritas-bu] Suspend or Freeze media

 

We are trying to phase our our LTO 2 tapes as we go to LTO 3. My thought
is that I will freeze or suspend the tapes and when they expire we can
remove them from service. Does this seem logical? Also, is there a way
to freeze a range of tapes? I do not have a good understanding of
freezing/suspending media. From what I read it appears that once a
frozen tape expires it comes back into service and a suspended tape
never expires. I am interested in knowing thoughts on the best way to
remove the media from service.

 

Matt Weathers

Senior Systems Programmer

Farm Bureau Insurance of Michigan

 

[EMAIL PROTECTED]

Office: (517) 391-5021

Fax: (517) 323-6793

 

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

Re: [Veritas-bu] Open Q to the List: What is the "Best" Filesystem for a staging disk

[Jon Bousselot]

I've done only tests using disk staging with JBOD and SAN attached disks.

UFS performed pretty well.
VxFS was a bit slow on clearing image files, but that wasn't a huge
problem as the image cleanup didn't always happen when I was trying to
write new ones.  Since it was VxFS, I could manage it using our standard
tool set and I knew it would most likely survive a host crash and not
corrupt itself.
ZFS had a lot of overhead that my test system didn't appreciate, but did ok.

If I had a faster system, performance might be a non-issue, and the
reasons for picking one would be for the feature set. 

-Jon
> Good evening all,
>
> I'm in the process of setting up another media server which will have
> 7TB of staging disk.
>
> What have your experiences been with filesystem type X's performance
> over Filesystem type Y ?
>
> I'm running on a Solaris media server, so my interest directly lies with
> UFS, VXFS, ZFS, or QFS. But I am interested in hearing your thoughts /
> experiences.
>
> Thanks.
>
> Unfortunatly it is late, playing on a SAN when tired IS dangerous so I'm
> going to post this and see what get's stirred up.
>
> Regards
>
> Adam Mellor
> Senior Unix Support Analyst
> CF IT TECHNOLOGY SERVICES
> Woodside Energy Ltd.





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

[Veritas-bu] Suspend or Freeze media

[Weathers, Matt]

We are trying to phase our our LTO 2 tapes as we go to LTO 3. My thought is 
that I will freeze or suspend the tapes and when they expire we can remove them 
from service. Does this seem logical? Also, is there a way to freeze a range of 
tapes? I do not have a good understanding of freezing/suspending media. From 
what I read it appears that once a frozen tape expires it comes back into 
service and a suspended tape never expires. I am interested in knowing thoughts 
on the best way to remove the media from service.

Matt Weathers
Senior Systems Programmer
Farm Bureau Insurance of Michigan

[EMAIL PROTECTED]
Office: (517) 391-5021
Fax: (517) 323-6793

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

Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

[Marianu, Jonathan]

Something you wrote didn't sound quite right.
Bpbkar writes to the child bptm using TCP sockets which is a bottleneck.

The child bptm process or processes, depending on MPX, write to shared
memory, The parent bptm reads from shared memory and writes it to the
tape.

I still use 5.1 so this may be different in 6.0

__
Jonathan Marianu (mah ree ah' nu)
AT&T Storage Planning and Design Architect
(360) 597-6896
Work Hours 0800-1800 PST M-F

Manager: David Anderson
(314) 340-9296


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

Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

[Peters, Devon C]

Not sure if this question was directed at Mike or myself, but if it was
directed to me...

In our case, the memory buffers for the disk are the shared memory
buffers on the media server (T2000).  When a media server is backing up
itself, the bpbkar process reads from disk directly into the
shared-memory buffers - the same buffers that the bptm process is
writing to tape from.  So, for our filesystem backups, we see disk I/O's
of the same size as our tape buffers...  We're currently bottlenecked at
the front-end processors of our storage array, and doing fewer larger
I/O's provides a little more throughput from the array.

The cache on the storage array is something I don't have a whole lot of
understanding about.  I assume that for reads, it is mostly a buffer
space for readahead...

-devon

-Original Message-
From: Justin Piszcz [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 21, 2007 6:59 AM
To: Mike Andres
Cc: Peters, Devon C; VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

Buffers in memory to disk would be dependent on how much cache the raid 
controller has yeah?

Justin.

On Wed, 21 Nov 2007, Mike Andres wrote:

> I'm curious about NUMBER_DATA_BUFFERS_RESTORE and duplication
performance as well.  Anybody know this definitively?
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Peters,
Devon C
> Sent: Tue 11/20/2007 1:32 PM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>
>
>
> Chris,
>
> To me it looks like there's a 1Gb bottleneck somewhere (90MB/s is
about all we ever got out of 1Gb fibre back in the day).  Are there any
ISL's between your tape drive, your switch, and your server's HBA?
Also, have you verified that your tape drives have negotiated onto the
fabric as 2Gb and not 1Gb?
>
> When we had 2Gb LTO-3 drives on our T2000's, throughput to a single
drive toped out around 160MB/s.  When we upgraded the drives to 4Gb
LTO-3, throughput to a single drive went up to 260MB/s.  Our data is
very compressible, and these numbers are what I assume to be the
limitation of the IBM tape drives.
>
> Regarding buffer settings, my experience may not apply directly since
we're doing disk (filesystems on fast storge) to tape backups, rather
than VTL to tape.  With our setup we see the best performance with a
buffer size of 1048576 and 512 buffers.  For us these buffer sizes are
mostly related to the filesystem performance, since we get better disk
throughput with 1MB I/O's than with smaller ones...
>
> I'm also curious if anyone knows whether the
NUMBER_DATA_BUFFERS_RESTORE parameter is used when doing duplications?
I would assume it is, but I don't know for sure.  If it is, then the
bptm process reading from the VTL would be using the default 16 (?)
buffers, and you might see better performance by using a larger number.
>
>
> -devon
>
>
> -
> Date: Fri, 16 Nov 2007 10:00:18 -0800
> From: Chris_Millet <[EMAIL PROTECTED]>
> Subject: [Veritas-bu]  T2000 vaulting performance with VTL/LTO3
> To: VERITAS-BU@mailman.eng.auburn.edu
> Message-ID: <[EMAIL PROTECTED]>
>
>
> I'm starting to experiment with the use of T2000 for media servers.
The backup server is a T2000 8 core, 18GB system.  There is a Qlogic
QLE2462 PCI-E dual port 4Gb adapter in the system that plugs into a
Qlogic 5602 switch.  From there, one port is zoned to a EMC CDL 4400
(VTL) and a few HP LTO3 tape drives.  The connectivity is 4Gb from host
to switch, and from switch to the VTL.  The tape drive is 2Gb.
>
> So when using Netbackup Vault to copy a backup done to the VTL to a
real tape drive, the backup performance tops out at about 90MB/sec.  If
I spin up two jobs to two tape drives, they both go about 45MB/sec.   It
seems I've hit a 90MB/sec bottleneck somehow.  I have v240s performing
better!
>
> Write performance to the VTL from incoming client backups over the WAN
exceeds the vault performance.
>
> My next step is to zone the tape drives on one of the HBA ports, and
the VTL zoned on the other port.
>
> I'm using:
> SIZE_DATA_BUFFERS = 262144
> NUMBER_DATA_BUFFERS = 64
>
> Any other suggestions?
>
>

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

Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

[Mike Andres]

Thanks.  I guess my question could be more specifically stated as "does the 
duplication process utilize NUMBER_DATA_BUFFERS_RESTORE or 
NUMBER_DATA_BUFFERS."   I don't have a system in front of me to test.



From: Justin Piszcz [mailto:[EMAIL PROTECTED]
Sent: Wed 11/21/2007 8:58 AM
To: Mike Andres
Cc: Peters, Devon C; VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3



Buffers in memory to disk would be dependent on how much cache the raid
controller has yeah?

Justin.

On Wed, 21 Nov 2007, Mike Andres wrote:

> I'm curious about NUMBER_DATA_BUFFERS_RESTORE and duplication performance as 
> well.  Anybody know this definitively?
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Peters, Devon C
> Sent: Tue 11/20/2007 1:32 PM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>
>
>
> Chris,
>
> To me it looks like there's a 1Gb bottleneck somewhere (90MB/s is about all 
> we ever got out of 1Gb fibre back in the day).  Are there any ISL's between 
> your tape drive, your switch, and your server's HBA?  Also, have you verified 
> that your tape drives have negotiated onto the fabric as 2Gb and not 1Gb?
>
> When we had 2Gb LTO-3 drives on our T2000's, throughput to a single drive 
> toped out around 160MB/s.  When we upgraded the drives to 4Gb LTO-3, 
> throughput to a single drive went up to 260MB/s.  Our data is very 
> compressible, and these numbers are what I assume to be the limitation of the 
> IBM tape drives.
>
> Regarding buffer settings, my experience may not apply directly since we're 
> doing disk (filesystems on fast storge) to tape backups, rather than VTL to 
> tape.  With our setup we see the best performance with a buffer size of 
> 1048576 and 512 buffers.  For us these buffer sizes are mostly related to the 
> filesystem performance, since we get better disk throughput with 1MB I/O's 
> than with smaller ones...
>
> I'm also curious if anyone knows whether the NUMBER_DATA_BUFFERS_RESTORE 
> parameter is used when doing duplications?  I would assume it is, but I don't 
> know for sure.  If it is, then the bptm process reading from the VTL would be 
> using the default 16 (?) buffers, and you might see better performance by 
> using a larger number.
>
>
> -devon
>
>
> -
> Date: Fri, 16 Nov 2007 10:00:18 -0800
> From: Chris_Millet <[EMAIL PROTECTED]>
> Subject: [Veritas-bu]  T2000 vaulting performance with VTL/LTO3
> To: VERITAS-BU@mailman.eng.auburn.edu
> Message-ID: <[EMAIL PROTECTED]>
>
>
> I'm starting to experiment with the use of T2000 for media servers.  The 
> backup server is a T2000 8 core, 18GB system.  There is a Qlogic QLE2462 
> PCI-E dual port 4Gb adapter in the system that plugs into a Qlogic 5602 
> switch.  From there, one port is zoned to a EMC CDL 4400 (VTL) and a few HP 
> LTO3 tape drives.  The connectivity is 4Gb from host to switch, and from 
> switch to the VTL.  The tape drive is 2Gb.
>
> So when using Netbackup Vault to copy a backup done to the VTL to a real tape 
> drive, the backup performance tops out at about 90MB/sec.  If I spin up two 
> jobs to two tape drives, they both go about 45MB/sec.   It seems I've hit a 
> 90MB/sec bottleneck somehow.  I have v240s performing better!
>
> Write performance to the VTL from incoming client backups over the WAN 
> exceeds the vault performance.
>
> My next step is to zone the tape drives on one of the HBA ports, and the VTL 
> zoned on the other port.
>
> I'm using:
> SIZE_DATA_BUFFERS = 262144
> NUMBER_DATA_BUFFERS = 64
>
> Any other suggestions?
>
>



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

Re: [Veritas-bu] 6.5 restoring legacy 5.1 NDMP backup issue?

[RMajor]

Following up on my own finding, it appears that I can successfully restore
from other 5.1 backup types (Windows, Standard), but NDMP still has the
issue. I am not able to test if the 6.5 NDMP backups can successfully be
restored until after the holiday.
 
I'm still wondering if anyone else has run into this issue? Still waiting
on a call back from support.
 
-Rusty

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rusty R
Major
Sent: Tuesday, November 20, 2007 5:30 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] 6.5 restoring legacy 5.1 NDMP backup issue?


Has anyone that's upgraded to 6.5 from 5.1 (Specifically MP3AS2) run into
an issue restoring NDMP backups? I have discovered that the status of the
NDMP restore is successful, but it will not restore anything in a
sub-directory unless each file/directory in the sub-directory(ies) is/are
manually selected.
 
I have not yet tried to restore an NDMP backup made under 6.5. No case yet
with Veritas, but that will be opened tomorrow.
 
Thanks,
Rusty
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Upgrade 5.1 MP6 to 6.5

[RMajor]

I also was a little confused by this, but as long as the NetBackup install
itself is not clustered on any of the servers, then this does not apply to
you.
 
-Rusty

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Clooney,
David
Sent: Wednesday, November 21, 2007 10:47 AM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] Upgrade 5.1 MP6 to 6.5



Hi All

 

I am imminently upgrading a Solaris 8 master server from 5.1 MP6 to 6.5 in
preparation for the rest of our environments

 

I have been reading through all the documentation and there are a lot of
references to clustered environments, now I am taking that the
documentation id referring to the master server being clustered.

 

Environment

1 X Master - Solaris 8 - standalone

2 X Media -  windows 2003 - standalone

2 X Media -  windows 2003  - Microsoft clustered.

 

I have checked all vm.conf's across all and made sure there are no
REQUIRED_INTERFACE or MM_SERVER_NAME entries of which there are none.

 

Even though two of the media servers are clustered, can I proceed as
normal as I am just upgrading the master server.

 

If someone could clarify this for me it would be much appreciated

 

Regards

 

Dave

 

 

 

 



  _  

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

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

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

  _  

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

Re: [Veritas-bu] Which media were used for a backup?

[Jeff Lightner]

Funny - you seem to have ignored the command line I gave you that DOES
give you the tapes used for a specific backup.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Alexander Skwar
Sent: Wednesday, November 21, 2007 2:19 AM
To: Veritas Backup Mailinglist
Subject: Re: [Veritas-bu] Which media were used for a backup?

Hello.

On Nov 20, 2007 9:30 PM, Marianne Van Den Berg <[EMAIL PROTECTED]>
wrote:
> cmd line is so much easier and faster than the GUI!

Not always, no.

> I use this:
>
> bpimagelist -media -hoursago 12 -client  -U

That's what I currently use as well, but it doesn't provide the
information I asked for :)

I wanted to know, which tapes were used by a certain backup.
"bpimagelist -media -hoursago 12 -client  -U" answers
the question, which media were used in the last 12 hours to
backup a certain client.

But I think I'm quite happy with the Catalog search functionality.

Thanks a lot,

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

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

Re: [Veritas-bu] Tape Drive & Disk sharing HBAs - revisited

[Jeff Lightner]

To add to your "sparsely and vaguely documented" documentation:  We
frequently have to reset one of the fibre HBAs on our HP-UX master
server attached to our fibre bridges for SCSI tape drives on the L700
tape library to clear issues.   The idea of having those HBAs also be
the point of entry for the disk drives would be a major issue for us.

 

We've and HP have never been able to diagnose this as a problem with the
HBAs themselves.  It just appears that on occasion things get hung.

 

If you'd prefer to think it doesn't really happen feel free to put
yourself at risk.  Personally I think real world anecdotes trump
theoretical white papers every time.

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jim fred
Sent: Tuesday, November 20, 2007 5:28 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] Tape Drive & Disk sharing HBAs - revisited

 

Hi 

 

We all know that people have been telling us for years that you should
never share tape drives and disk on the HBAs. 

 

These days the idea that the HBA could become the bottle neck for data
transmission are becoming less.  

 

That leaves the other reason of  tape FC-SCSI commands have adverse
affects upon the SAN operations of disks.   The has been sparsely and
vaguely documented to the point where it  may be more mythology than
reality with modern SAN, disk and tape technology.  

 

Anybody attempted sharing emterprise grade disk [arrays] & LTO3 tape.
OS not important but Windows 2003 would be interesting. 

 

Anybody come across anything more definitive that these references ?
. 

 

1. IBM Redbook sg246268 Implementing IBM Tape in Linux Widows p201+.

I queried IBM to provide more infono reply form them. 

 

2. The following came from X-Info [Qlogic OEM]  Qlogic weren't
interested but flipped my questions to two of their OEMs to answer  (no
referecne cited) : 

 

Tape resets can affect other devices on the SAN because when a tape does
its reset, it will also reset its FC connection (logs out and logs back
into the fabric nameserver of the switch).  When a device logs out and
back into the switch, the switch will send out an RSCN (registered state
change notification) to the rest of the ports on the switch letting
other FC devices know that there was a change in the fabric.  When the
RSCN is received by the initiators (servers and workstations), they in
turn must log out and back in to see what has changed on the nameserver.
This process of logging out and in can cause issues with the host OS
(particularly with Windows) because of the delays incurred during this
logout/in.  During periods of high IO, the OS may just loose connection
to the drives, or it may kernel panic/blue screen the OS. 

Qlogic switches have a feature called IOStreamguard that prevents RSCN's
from going to initiators that don't need to see them (i.e., the server
does not have an active connection to the tape, or the tape is not in
its zone).  Other vendors switches can use zoning to restrict this as
much as possible, but RSCN's can still propagate outside the zones
affected. 

Also, tape resets are not as prevalent now as they used to be.  The
older SCSI tape drives that were connected to the SAN via SCSI to FC
Bridge were more of a problem that the newer native FC tape drives.  The
native FC drives are kinder to the fabric, and do not do resets unless
they are actually needed.  Despite the advances made with the native FC
tape drives, there still can be issues, and that is why there is the
recommendation of using a separate fabric for the tape subsystem. 

Regards Jim 

   

 

 

 

 

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

[Veritas-bu] Upgrade 5.1 MP6 to 6.5

[Clooney, David]

Hi All

 

I am imminently upgrading a Solaris 8 master server from 5.1 MP6 to 6.5
in preparation for the rest of our environments

 

I have been reading through all the documentation and there are a lot of
references to clustered environments, now I am taking that the
documentation id referring to the master server being clustered.

 

Environment

1 X Master - Solaris 8 - standalone

2 X Media -  windows 2003 - standalone

2 X Media -  windows 2003  - Microsoft clustered.

 

I have checked all vm.conf's across all and made sure there are no
REQUIRED_INTERFACE or MM_SERVER_NAME entries of which there are none.

 

Even though two of the media servers are clustered, can I proceed as
normal as I am just upgrading the master server.

 

If someone could clarify this for me it would be much appreciated

 

Regards

 

Dave

 

 

 

 




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

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

If this email originates from the U.K. please note that Bank of America, N.A., 
London Branch and Banc of America Securities Limited are authorised and 
regulated by the Financial Services Authority.
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

[Justin Piszcz]

Buffers in memory to disk would be dependent on how much cache the raid 
controller has yeah?

Justin.

On Wed, 21 Nov 2007, Mike Andres wrote:

> I'm curious about NUMBER_DATA_BUFFERS_RESTORE and duplication performance as 
> well.  Anybody know this definitively?
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Peters, Devon C
> Sent: Tue 11/20/2007 1:32 PM
> To: VERITAS-BU@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3
>
>
>
> Chris,
>
> To me it looks like there's a 1Gb bottleneck somewhere (90MB/s is about all 
> we ever got out of 1Gb fibre back in the day).  Are there any ISL's between 
> your tape drive, your switch, and your server's HBA?  Also, have you verified 
> that your tape drives have negotiated onto the fabric as 2Gb and not 1Gb?
>
> When we had 2Gb LTO-3 drives on our T2000's, throughput to a single drive 
> toped out around 160MB/s.  When we upgraded the drives to 4Gb LTO-3, 
> throughput to a single drive went up to 260MB/s.  Our data is very 
> compressible, and these numbers are what I assume to be the limitation of the 
> IBM tape drives.
>
> Regarding buffer settings, my experience may not apply directly since we're 
> doing disk (filesystems on fast storge) to tape backups, rather than VTL to 
> tape.  With our setup we see the best performance with a buffer size of 
> 1048576 and 512 buffers.  For us these buffer sizes are mostly related to the 
> filesystem performance, since we get better disk throughput with 1MB I/O's 
> than with smaller ones...
>
> I'm also curious if anyone knows whether the NUMBER_DATA_BUFFERS_RESTORE 
> parameter is used when doing duplications?  I would assume it is, but I don't 
> know for sure.  If it is, then the bptm process reading from the VTL would be 
> using the default 16 (?) buffers, and you might see better performance by 
> using a larger number.
>
>
> -devon
>
>
> -
> Date: Fri, 16 Nov 2007 10:00:18 -0800
> From: Chris_Millet <[EMAIL PROTECTED]>
> Subject: [Veritas-bu]  T2000 vaulting performance with VTL/LTO3
> To: VERITAS-BU@mailman.eng.auburn.edu
> Message-ID: <[EMAIL PROTECTED]>
>
>
> I'm starting to experiment with the use of T2000 for media servers.  The 
> backup server is a T2000 8 core, 18GB system.  There is a Qlogic QLE2462 
> PCI-E dual port 4Gb adapter in the system that plugs into a Qlogic 5602 
> switch.  From there, one port is zoned to a EMC CDL 4400 (VTL) and a few HP 
> LTO3 tape drives.  The connectivity is 4Gb from host to switch, and from 
> switch to the VTL.  The tape drive is 2Gb.
>
> So when using Netbackup Vault to copy a backup done to the VTL to a real tape 
> drive, the backup performance tops out at about 90MB/sec.  If I spin up two 
> jobs to two tape drives, they both go about 45MB/sec.   It seems I've hit a 
> 90MB/sec bottleneck somehow.  I have v240s performing better!
>
> Write performance to the VTL from incoming client backups over the WAN 
> exceeds the vault performance.
>
> My next step is to zone the tape drives on one of the HBA ports, and the VTL 
> zoned on the other port.
>
> I'm using:
> SIZE_DATA_BUFFERS = 262144
> NUMBER_DATA_BUFFERS = 64
>
> Any other suggestions?
>
>
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3

[Mike Andres]

I'm curious about NUMBER_DATA_BUFFERS_RESTORE and duplication performance as 
well.  Anybody know this definitively?



From: [EMAIL PROTECTED] on behalf of Peters, Devon C
Sent: Tue 11/20/2007 1:32 PM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] T2000 vaulting performance with VTL/LTO3



Chris, 

To me it looks like there's a 1Gb bottleneck somewhere (90MB/s is about all we 
ever got out of 1Gb fibre back in the day).  Are there any ISL's between your 
tape drive, your switch, and your server's HBA?  Also, have you verified that 
your tape drives have negotiated onto the fabric as 2Gb and not 1Gb?

When we had 2Gb LTO-3 drives on our T2000's, throughput to a single drive toped 
out around 160MB/s.  When we upgraded the drives to 4Gb LTO-3, throughput to a 
single drive went up to 260MB/s.  Our data is very compressible, and these 
numbers are what I assume to be the limitation of the IBM tape drives.

Regarding buffer settings, my experience may not apply directly since we're 
doing disk (filesystems on fast storge) to tape backups, rather than VTL to 
tape.  With our setup we see the best performance with a buffer size of 1048576 
and 512 buffers.  For us these buffer sizes are mostly related to the 
filesystem performance, since we get better disk throughput with 1MB I/O's than 
with smaller ones...

I'm also curious if anyone knows whether the NUMBER_DATA_BUFFERS_RESTORE 
parameter is used when doing duplications?  I would assume it is, but I don't 
know for sure.  If it is, then the bptm process reading from the VTL would be 
using the default 16 (?) buffers, and you might see better performance by using 
a larger number.


-devon 


- 
Date: Fri, 16 Nov 2007 10:00:18 -0800 
From: Chris_Millet <[EMAIL PROTECTED]> 
Subject: [Veritas-bu]  T2000 vaulting performance with VTL/LTO3 
To: VERITAS-BU@mailman.eng.auburn.edu 
Message-ID: <[EMAIL PROTECTED]> 


I'm starting to experiment with the use of T2000 for media servers.  The backup 
server is a T2000 8 core, 18GB system.  There is a Qlogic QLE2462 PCI-E dual 
port 4Gb adapter in the system that plugs into a Qlogic 5602 switch.  From 
there, one port is zoned to a EMC CDL 4400 (VTL) and a few HP LTO3 tape drives. 
 The connectivity is 4Gb from host to switch, and from switch to the VTL.  The 
tape drive is 2Gb.

So when using Netbackup Vault to copy a backup done to the VTL to a real tape 
drive, the backup performance tops out at about 90MB/sec.  If I spin up two 
jobs to two tape drives, they both go about 45MB/sec.   It seems I've hit a 
90MB/sec bottleneck somehow.  I have v240s performing better!

Write performance to the VTL from incoming client backups over the WAN exceeds 
the vault performance. 

My next step is to zone the tape drives on one of the HBA ports, and the VTL 
zoned on the other port. 

I'm using: 
SIZE_DATA_BUFFERS = 262144 
NUMBER_DATA_BUFFERS = 64 

Any other suggestions? 

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

[Veritas-bu] Open Q to the List: What is the "Best" Filesystem for a staging disk

[Mellor, Adam A.]

Good evening all,

I'm in the process of setting up another media server which will have
7TB of staging disk.

What have your experiences been with filesystem type X's performance
over Filesystem type Y ?

I'm running on a Solaris media server, so my interest directly lies with
UFS, VXFS, ZFS, or QFS. But I am interested in hearing your thoughts /
experiences.

Thanks.

Unfortunatly it is late, playing on a SAN when tired IS dangerous so I'm
going to post this and see what get's stirred up.

Regards

Adam Mellor
Senior Unix Support Analyst
CF IT TECHNOLOGY SERVICES
Woodside Energy Ltd.

NOTICE: This email and any attachments are confidential. 
They may contain legally privileged information or 
copyright material. You must not read, copy, use or 
disclose them without authorisation. If you are not an 
intended recipient, please contact us at once by return 
email and then delete both messages and all attachments.

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

[Veritas-bu] Yoseph Leleputra has invited you to join Friendster

[Yoseph Leleputra]

You're invited to join Yoseph Leleputra's network of friends. 

By joining Friendster, you can reconnect with old
friends, meet new friends, start a blog, build a custom
profile, keep track of birthdays, and so
much more!

You can even stay in touch if you move away, switch
email addresses, or lose your mobile phone.

Click below to join Yoseph's network.

http://www.friendster.com/join.php?inviteref=9098972&invite=V6fflDwAijjjHMf1PGQK_QZnhajVk93PUwckXdeM6fOFvqiKaH5sSrPX0ICU7VUu&lang=

*
If you do not wish to receive notification emails from Friendster, please click 
below:
http://www.friendster.com/blockemails.php?invite=dmVyaXRhcy1idUBtYWlsbWFuLmVuZy5hdWJ1cm4uZWR1
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu