Re: [Veritas-bu] Netbackup verify at write time

[Meidal, Knut]

>
>
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:veritas-bu->[EMAIL PROTECTED] On Behalf Of 
>Curtis Preston
>Sent: Thursday, July 31, 2008 12:44 PM
>To: Jeff Lightner; VERITAS-BU@mailman.eng.auburn.edu
>Subject: Re: [Veritas-bu] Netbackup verify at write time
>
>Jeff Lightner said:
>
>>FDA Validation requirements make S-OX look
>>like a walk in the park.
>
>What HE said!
>

Agree wholeheartedly!
Stuart, thoughts?




Knut

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

Re: [Veritas-bu] Multiplexing on VTL's

[Meidal, Knut]

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bob944
Sent: Wednesday, April 30, 2008 4:36 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Multiplexing on VTL's

> Good reason #1:  in my VTL testing experience, making a boatload of
> drives from the VTL's available disk space leads (of course) to fewer or
> smaller tapes.  And a backup that requires a dozen tapes because they're
> only 10GB-sized incurs a significant time penalty from all those media
> change times.

===
Speaking only for my NetApp VTLs here, but the 'media change time' as in 
'rewind, unload drive, put tape in slot, grab a new tape from slot, put in 
drive, mount/position' takes next to no time at all. Fractions of a second.
===

> Good reason #2:  backing the number of drives down produced a need to
> multiplex in order to have N jobs in execution (the reason for all those
> virtual drives in the first place--throw a drive at every job required).
> Multiplexing worked fine.  In non-real-world mux testing (simultaneous
> backups of the same directories on a media server), aggregate throughput
> improved all the way up to mux 32.

===
Multiplexing WILL work. In my ever so humble opinion, MPX was a band-aid to 
address the 'how to pipe data fast enough to fast tape drives' question. The 
VTL doesn't care. 1 MB/s or 100MB/s or anything in-between is fine.
My main concern is that when doing restores off a multiplexed tape, the VTL 
READ speed off the disk(let's say it's 80MB/s) is the same whether there's MPX 
in the stream or not. The restore will throw away the bytes that doesn't belong 
to the client, so out of a 80 MB/s stream coming off the disk, you will throw 
away (let's say) 60MB and use only 20. It's this reduction in effective restore 
speed that's my main concern.
A VTL without MPX _may_ be more effective at doing restores.
===

> Good reason #3:  the administrative overhead of, say, 128 drives versus
> 16 quickly became annoying.  Pages and pages of tpconfig listings going
> off the screen, or GUI device monitor to look through... hard to see the
> drive situation at a glance... process-troubleshooting... it slows
> things up in real and (probably) imagined ways.

===
While true, my experience is that virtual drives are quite reliable. There's no 
write errors or read errors detected by the media servers, and they don't have 
reasons to DOWN their drives. (That's somewhat of a simplification... if there 
are SAN hiccups, media servers may down all their drives immediately...)
===

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

Re: [Veritas-bu] NDMP tape drives

[Meidal, Knut]

This is a situation where a VTL would be quite useful.
You could create some virtual drives that are assigned as NDMP drives and 
dedicated to a filer, and also have a suitable number of non-NDMP drives 
assigned to master or media servers.
The VTL would then clone tapes from both behind the scenes.

The need for SSO drives (with associated license cost and configuration 
complexity) would also disappear.

I can't remember off the top of my head what our NetApp/Symantec folks have 
told me about the SSO for NDMP, but I think it is a feature of 6.5, and some 
version of OnTap.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Rioux
Sent: Tuesday, April 29, 2008 7:35 AM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] NDMP tape drives

We are running NB 5.1 on a Windows master and have 2 drive in an autoloader. 
One drive is defined as an NDMP drive the other is a normal media drive. Can I 
make an NDMP storage unit and point to the non-NDMP drive to do backup to it?
Would the situation be any different if I upgraded to 6.5?

Thanks,
Jerry
___
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

[Meidal, Knut]

I'll let that one slide

IF you had mentioned ArcServe, however I'd be running after you


CommVault, anybody?



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony T.
Sent: Monday, March 31, 2008 3:03 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Top 20 (or so) misunderstood things about NBU

- Brick level backups of Exchange...not nearly as good as Backup Exec

*runs out of the room*


On Mon, Mar 31, 2008 at 4:48 PM, Curtis Preston <[EMAIL 
PROTECTED]> wrote:
Hey there, folks!  I'm working very hard on my next book, which will
have some product-specific information in it.  I'm covering multiple
products, so I won't go TOO deep on individual products, but I'd like to
do my best to cover misunderstood or frequently asked topics for each
major product.  I figured that no one would know better than this list
which topics people tend to get confused.

What topics do you think should go on that list?  (I've got my personal
preferences, but I don't want to prejudice your thoughts.)  What are the
top 5/20/30 things about NBU that you think people get wrong?

TIA

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



--
)
(
)
[_])
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] VTL & NetBackup Best Practice

[Meidal, Knut]

Our NetApp Nearstore VTL will do the following when you initiate import from a 
physical tape:

It will immediately mount  the tape and start importing(depending on available 
physical drives, it doesn't pre-empt the write queue to read anything). The 
tape is immediately seen by the media server as soon as importing starts. Data 
will be read from the physical tape and laid down to disk inside the VTL.

Then, one of two things will happen.
1: If the VTL has time to read the entire contents of the data, it will simply 
lay it down on disk from start to finish, and unmount the physical tape from 
the drive, and let the data sit on disk awaiting restore. When you go to 
restore, it is very quick. Positioning is instantaneous, and read speeds are 
blazing, 120-130MB/s
2: If you decide to start the restore before the piece of data you're 
interested in is read off the tape, the VTL will stop the import, skip ahead on 
the physical tape to the file marker requested, and data is passed directly to 
the media server without being staged on to the VTL disk. In this case, the 
positioning is slower, as it is in fact the physical tape being manipulated, as 
well as read speeds, will be whatever is coming off the physical tape at a 
given point. The rest of the data on tape will be read and imported when it is 
able to do so

All of this is transparent to NetBackup.
The import speed is pretty much whatever the physical drive is able to give 
you, it's data dependent and we're seeing approx 70-80 MB/s on LTO-2 tapes, 
80-95 MB/s on LTO-3 tapes.

This is how NetApp VTLs work, I cannot comment on other products.

So, in summary, the time taken to import is a factor, but somewhat mitigated by 
the "bypass" operations. Another complication is of course the need to do this 
preparation step in the VTL before NetBackup gets involved.




From: Shyam Hazari [mailto:[EMAIL PROTECTED]
Sent: Friday, March 07, 2008 12:34 PM
To: Meidal, Knut
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] VTL & NetBackup Best Practice

Knut,

I am just curious how significant is the time taken to import data to VTL.

-Shyam
On Fri, Mar 7, 2008 at 1:14 PM, Meidal, Knut <[EMAIL PROTECTED]<mailto:[EMAIL 
PROTECTED]>> wrote:

We converted our environment from Vault to using the "Direct Tape Copy" feature 
of our VTLs.

Bad:

 *   Requires additional steps to import data to VTL before restore can start

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

Re: [Veritas-bu] VTL & NetBackup Best Practice

[Meidal, Knut]

Since Stuart is soliciting feedback from his former co-workers...:

We do have VTLs in our environment, and a rather complex setup. I'm not sure if 
our environment would qualify as any "best practices", however.

We're on NetBackup 5.1, Solaris master, 4 Linux media servers, 4 Windows media 
servers. 13 NetApp filers are SAN connected and zoned to the same VTL.
We have 6 NetApp NearStore VTL700s with a total of 256TB of useable disk. That 
is before the data compression is factored in.
On the back-end we have a 7-node Decru DataFort cluster and a 20-drive ADIC 
Scalar i2000.

Each of the 8 media servers are controlling 3 virtual libraries. These 24 
virtual libraries are spread among the 6 VTL controllers for load balancing and 
redundancy.
In addition, we have one virtual library that is dedicated to NDMP usage. I'll 
get back to that in a moment.

Starting out with this new environment, the tape type on the VTLs were 40GB in 
size. The idea being precisely as others have pointed out; a higher number of 
small tapes will waste less space,and ease congestion, making it feasible 
forego multiplexing. Also, in the beginning, NetBackup Vault was in charge of 
duplicating images from VTL tapes to physical LTO tapes. A 16-drive SSO pool 
was configured.
Conceptually this had a few good points:

 *   NetBackup would have control and knowledge of all copies, virtual and 
physical
 *   Prioritizations could be made for the Vaulting and offsite copying
 *   Restores could be done directly from physical tape without first importing 
to a VTL
 *   The large number of virtual libraries (24) means that a given VTL outage 
will not take down the entire environment or cripple a media server

There were however issues with this, as Stuart points out. The BPDUPLICATE 
function in NetBackup 5.1 is very slow and inefficient. We had a lot of small 
images, and there was about 14 seconds of housekeeping time for each of the 
images, so for small or empty images, the thruput is very low. I cannot comment 
on the BPDUPLICATE function in later versions, or how it behaves with DSU image 
duplication.
We converted our environment from Vault to using the "Direct Tape Copy" feature 
of our VTLs.
Performance skyrocketed, we saw increase in total thruput at the time from 
about 1TB/day with Vault to about 24TB/day with DTC. How often do you get to 
experience a 24 TIMES performance increase? Essentially free, too! We are 
currently sending approx 44TB/day to tape, as an average for a month.

Good and bad things about using the DTC function:
Good:

 *   Performance is good
 *   No performance penalty on the media servers, they have to do less work
Bad:

 *   NetBackup loses track of what data is on disk or physical tape. To 
NetBackup, it's all on a tape...
 *   Little possibility to prioritize which tapes or policies are cloned first
 *   Requires additional steps to import data to VTL before restore can start
For us, at present time, the benefits of the performance outweighs the 
downsides. Your mileage may vary.

Continuing my musings on "best practices"; I'm undecided about "many small, 
self-contained virtual libraries" vs "fewer, larger, shared virtual libraries".
There are good and bad points to both approaches, we do value the redundancy of 
having many, smaller virtual libraries. There is additional operator 
involvement in this, like having to assign tapes to all of them, balance the 
assignment against expected usage etc.
We have written (well, Stuart actually) scripts that will assign scratch tapes 
in the libraries as needed, based on low/high watermarks. That way, managing 6 
or 24 virtual libraries doesn't make much of a difference.

Back to the case for NetApp filers and backups with NDMP for a minute:
VTLs are pretty much a perfect complement to filers. What we have, is 13 
SAN-attached NetApp filers, that have been zoned in (round-robin) to 4 
front-end ports on a VTL.
I have set up ONE large virtual library, with 52 virtual drives. My Solaris 
master server is the robot control host of this large library, but does NOT 
have access to any of the drives.
Each filer has exclusive control of 4 virtual drives.
There is NO drive sharing taking place in this scenario. Even if certain OnTap 
and NetBackup combinations can handle drive sharing, I believe that having 
dedicated virtual drives in a shared library makes more sense. All the 
benefits, none of the downsides.
I have one Storage unit configured per filer, utilizing the virtual drives each 
filer owns in the shared library.
This simplifies scratch tape management, and seems to work great.
A nice side-effect is that when doing re-directed restores from a filer to 
another, the destination filer mounts the virtual tape directly in its own 
assigned drive and reads the data directly over the SAN. No data is sent over 
the network.

Now; is this something that could be considered "best practice"?
It's working well for us, and I would recommend a setup like that for other

Re: [Veritas-bu] Windows & Unix Media Servers is a SSO environment.

[Meidal, Knut]

We're no longer doing SSO, but I don't think there were any fundamental issues 
in our environment sharing 16 LTO drives across 4 windows and 4 Linux media 
servers.

We were using 5.1MP4 at the time, on Windows Server 2003 and RedHat Linux 4
The drives were mapped through Decru DataForts, but I also don't think that has 
an impact on functionality.

Knut Meidal

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, January 25, 2008 11:18 AM
To: VERITAS-BU@mailman.eng.auburn.edu
Subject: [Veritas-bu] Windows & Unix Media Servers is a SSO environment.

In the early days of SSO, mixing Windows and Unix media servers sharing
the same drives via SSO was, to put it kindly, painful.

Any experience with the current software set?  Anybody mixing Windows &
Unix painlessly (sharing the same drives via SSO)?

-M

___
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] Clarification on NetBackup 5.1 & 6.5

[Meidal, Knut]

Also, I have a feeling that this (IF it works) would be like teaching a dog to 
walk on his hind legs... Possible, but not the most efficient way.

A media server lives to move data, and the more direct and unobstructed access 
to the hardware, the better


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jim fred
Sent: Monday, December 10, 2007 1:06 PM
To: WEAVER, Simon (external)
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Clarification on NetBackup 5.1 & 6.5

Hi

More ammo 

VMware itself will NOT support fibre channel tape drives and tape libraries.

I've actually tested this. We got a FC tape drives to work at the windows 2003 
OS level, could see a media changer (tape lib).  Netbackup would back to the 
tape drives as standalones, but couldn't restore. HP TTL  software didn't like 
FC devices on vmware.

Like others have said ...check the the 6.5 Release Notes.  They probably have 
been updated last week with the release of 6.5.1 MP.  i.e you can argue the 
reference is  the latest you will get.   If it ain't supported and you 
implement you have voided any support that you will receive from Symantec i.e 
they will not be interested helping you.

Jim


On 12/11/07, WEAVER, Simon (external) <[EMAIL PROTECTED]> wrote:

Guys
Quick 2 questions:

1) Does Symantec support NetBackup 5.1 or 6.5 in a virtualised environment?
(ie: Master or Media Server on a Vmware host)?
2) Can anyone clarify if NT4.0 is supported with 6.5 ?

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] mailto:[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
___
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] Maximum number of policies

[Meidal, Knut]

Bright future in consulting, looks like.
Maybe Curtis is hiring...
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Liddle,
Stuart
Sent: Monday, July 23, 2007 3:57 PM
To: Justin Piszcz; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
Veritas-bu@mailman.eng.auburn.edu; Liddle, Stuart
Subject: Re: [Veritas-bu] Maximum number of policies

AhI see.  

So, Justin, you have some "special" insight about everyone's backup
environment and business requirements that allows you to come up with a
blanket statement like that?  



-Original Message-
From: Justin Piszcz [mailto:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 1:52 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
Veritas-bu@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Maximum number of policies

Whoever has that many polices has some mental issues.

On Mon, 23 Jul 2007, [EMAIL PROTECTED] wrote:

> I thought this pic would be appropriate for us ...
>
>
>
> 
>
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Liddle,
Stuart
> Sent: Monday, July 23, 2007 2:48 PM
> To: WEAVER, Simon (external); Liddle, Stuart; 'Edson Noboru Yamada';
Veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Maximum number of policies
>
>
>
> yes just over 1100 policiesit's not quite 1 client per policy as
Curtis Preston suggests.  What we have done is to have a policy for a given
dataset.  For example, we have two exchange policies one has 13 exchange
servers in it and the other has 10.  The reason we have two is because they
are in different datacenters and we have a media server in each datacenter.
>
>
>
> Most of our policies actually do have only one client per policy, but
because we are creating policies by dataset, we will have some that have
more than one client.
>
>
>
> --stuart
>
>
>
> 
>
> From: WEAVER, Simon (external) [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 22, 2007 11:20 PM
> To: 'Liddle, Stuart'; 'Edson Noboru Yamada';
Veritas-bu@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] Maximum number of policies
>
>
>
> 1,100 policies!!
>
>
>
>
>
> 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: Liddle, Stuart [mailto:[EMAIL PROTECTED]
>   Sent: Friday, July 20, 2007 2:59 PM
>   To: WEAVER, Simon (external); 'Edson Noboru Yamada';
Veritas-bu@mailman.eng.auburn.edu
>   Subject: RE: [Veritas-bu] Maximum number of policies
>
>   Hi,
>
>
>
>   we are running NB 5.1 MP6 with around 1100 policies and over 1600
clients.  We have been having problems with the scheduler not starting
things when they are supposed to start.  The one thing that is very
important is to have the proper settings in the /etc/system file for shared
memory.  If you don't have this set correctly, you WILL have problems with
the scheduler.
>
>
>
>   We had a case open with Symantec/Veritas about this and basically we
were told that it would be best to upgrade to 6.x because the scheduler has
been completely re-written and is much more efficient.  We hope to upgrade
to 6.5 later this year.  In the mean time we have to figure out creative
ways to deal with the problems of the scheduler getting bogged down.
>
>
>
>   I believe that you should not have problems with only 100 policies
if you have your memory settings correct in /etc/system.
>
>
>
>   good luck.
>
>
>
>   --stuart
>
>
>
>
> 
>
>
>   From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WEAVER,
Simon (external)
>   Sent: Friday, July 20, 2007 6:42 AM
>   To: 'Edson Noboru Yamada'; Veritas-bu@mailman.eng.auburn.edu
>   Subject: Re: [Veritas-bu] Maximum number of policies
>
>
>
>   Hi
>
>   Well I know of a site that had 120 policies, but never reported an
issue. Although its alot, I am not personally aware of any recommendation
that states what the limit should be.
>
>
>
>   Are you sure the frequency is right and the policy is enabled
correctly ?
>
>
>
>   If at all possible, can you consolidate any of your existing
policies and merge them ?
>
>
>
>
>
>   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 Edson Noboru
Yamada
>   Sent: Friday, July 20, 2007 11:43 AM
>   To: Veritas-bu@mailman.eng.auburn.edu
>   Subject: [Veritas-bu] Maximum number of polici

Re: [Veritas-bu] Maximum number of policies

[Meidal, Knut]

Well, it comes down to how you want to keep control of your environment, I
think.
It may be the right thing for certain environments.

Reporting success/failures is very efficient to do per policy, or 'data set'
as Stuart uses.


 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin
Piszcz
Sent: Monday, July 23, 2007 1:52 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
Veritas-bu@mailman.eng.auburn.edu; [EMAIL PROTECTED]
Subject: Re: [Veritas-bu] Maximum number of policies

Whoever has that many polices has some mental issues.

On Mon, 23 Jul 2007, [EMAIL PROTECTED] wrote:

> I thought this pic would be appropriate for us ...
>
>
>
> 
>
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Liddle, Stuart
> Sent: Monday, July 23, 2007 2:48 PM
> To: WEAVER, Simon (external); Liddle, Stuart; 'Edson Noboru Yamada'; 
> Veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Maximum number of policies
>
>
>
> yes just over 1100 policiesit's not quite 1 client per policy as
Curtis Preston suggests.  What we have done is to have a policy for a given
dataset.  For example, we have two exchange policies one has 13 exchange
servers in it and the other has 10.  The reason we have two is because they
are in different datacenters and we have a media server in each datacenter.
>
>
>
> Most of our policies actually do have only one client per policy, but
because we are creating policies by dataset, we will have some that have
more than one client.
>
>
>
> --stuart
>
>
>
> 
>
> From: WEAVER, Simon (external) [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 22, 2007 11:20 PM
> To: 'Liddle, Stuart'; 'Edson Noboru Yamada'; 
> Veritas-bu@mailman.eng.auburn.edu
> Subject: RE: [Veritas-bu] Maximum number of policies
>
>
>
> 1,100 policies!!
>
>
>
>
>
> 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: Liddle, Stuart [mailto:[EMAIL PROTECTED]
>   Sent: Friday, July 20, 2007 2:59 PM
>   To: WEAVER, Simon (external); 'Edson Noboru Yamada';
Veritas-bu@mailman.eng.auburn.edu
>   Subject: RE: [Veritas-bu] Maximum number of policies
>
>   Hi,
>
>
>
>   we are running NB 5.1 MP6 with around 1100 policies and over 1600
clients.  We have been having problems with the scheduler not starting
things when they are supposed to start.  The one thing that is very
important is to have the proper settings in the /etc/system file for shared
memory.  If you don't have this set correctly, you WILL have problems with
the scheduler.
>
>
>
>   We had a case open with Symantec/Veritas about this and basically we
were told that it would be best to upgrade to 6.x because the scheduler has
been completely re-written and is much more efficient.  We hope to upgrade
to 6.5 later this year.  In the mean time we have to figure out creative
ways to deal with the problems of the scheduler getting bogged down.
>
>
>
>   I believe that you should not have problems with only 100 policies
if you have your memory settings correct in /etc/system.
>
>
>
>   good luck.
>
>
>
>   --stuart
>
>
>
>
> 
>
>
>   From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of WEAVER,
Simon (external)
>   Sent: Friday, July 20, 2007 6:42 AM
>   To: 'Edson Noboru Yamada'; Veritas-bu@mailman.eng.auburn.edu
>   Subject: Re: [Veritas-bu] Maximum number of policies
>
>
>
>   Hi
>
>   Well I know of a site that had 120 policies, but never reported an
issue. Although its alot, I am not personally aware of any recommendation
that states what the limit should be.
>
>
>
>   Are you sure the frequency is right and the policy is enabled
correctly ?
>
>
>
>   If at all possible, can you consolidate any of your existing
policies and merge them ?
>
>
>
>
>
>   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 Edson Noboru
Yamada
>   Sent: Friday, July 20, 2007 11:43 AM
>   To: Veritas-bu@mailman.eng.auburn.edu
>   Subject: [Veritas-bu] Maximum number of policies
>
>
>   Hi
>
>   I have an NBU 5.1 installation with one master server
(Solaris 9) and 6 media servers (RHEL4, Windows 2003).
>
>   I´ve just created the 101st policy. The problem I´m running
into is that apparently the scheduler is simply ignoring
>  

Re: [Veritas-bu] Newbie to Netbackup using VTL

[Meidal, Knut]

Warning, long ramble follows... I'll take the middle ground.

The existence of a VTL appliance is IMO due to the fact that backup
utilities (from now on limited to NBU) are not really stellar at using
"disk-as-disk" or DAD. They are reasonably good at using tape, as that has
been designed in from the very beginning.
Disk has unquestionable advantages (random access, near-zero mount/position
times), some more "it depends" traits, like transfer speed flexibility and
so on. 

Some of the downsides of using disk as disk are 

1) Concurrency to disk: if you have multiple media servers, how to ensure
they're cooperating peacefully when reading/writing to the same disk area.
You can do that in several ways:

* Divide up in separate LUNs. Each media server owns it and creates
a file system on it. Very difficult to change the amount allocated to each.
Maybe a volume manager and advanced file system can address some of that.

* Cluster file system. Good solution. Introduces complexity and
potentially cost. 

* "Gentleman's agreement" sharing of LUN. Access to files are
centrally brokered by the master server. I believe this is how CommVault
Galaxy/GridStor operates. The servers asks broker politely before writing to
a certain disk area. Not a true cluster file system.

* Use the disk as a network file system. Use CIFS/NFS to access your
disk pool and backup images. 

2) Provisioning/expansion of capacity. How to grow the LUNs, grow the
cluster file system, etc.

3) The backup application (especially NBU 5.1) IMO isn't very clever about
disk storage.


To get the best of both worlds, the advantages of disk, combined with NBU's
ability to administer tapes, the VTL was created, to use "disk-as-Tape".
NBU does the same ole thing it's always done, and reaps the benefits of
quick mounts and positioning, and the "hidden" capacity growth that happened
when adding more disk to the unit. (Just create more virtual tapes).
De-duplication can happen behind the scenes, NBU will never know.

The downside to VTLs are (or might be) that NBU does the backup to a tape
with a barcode. Job done! There is no insight into what goes on behind the
scenes, when the physical tape is removed etc. 

This is where Vault shines. It knows all about the primary copy, all the
secondary copies all the way thru the lifecycle. 
There is a layer of abstraction as to managing the VTL copy to the Physical
Tape, as well as potentially importing it again when restoring, we have
found that to be manageable.

I understand upcoming versions of NBU will have some integration with NetApp
VTL to handle some of these 'hidden' tasks. 

Additionally, the job of copying the disk data on to a physical tape takes
some amount of resources, from a CPU somewhere. If an intelligent VTL
doesn't do it, a media server will have to. If you have plenty of resources
on your media server, great, if not -you might affect the backup performance
while duplicating.

Bpduplicate in 5.1 appears to be inefficient. Upcoming versions couldn't
possibly be worse. (knock on wood)

As far as I know, there is no way of having a "duplication only" media
server role in NetBackup. The idea being that a client-facing media server
dumps data to a disk, then letting a NBU media server (not client facing)
read the disk data and write out to tape. This would offload the job from
the client-facing media server, and have NBU know all about the goings-on.
(A kind of roll-your-own duplication workload offload engine, or RYODWOE if
you will. (tm) )

So, bottom line:
VTLs are an intermediate way of using disk with your dumb backup
application. 
NBU isn't (yet) smart about using disk-as-disk. 
The VTL controller does a great job of offloading the media server to create
the phys tapes.
Redesign of application necessary to use disk optimally. Let's hope that
happens in 6.5 and onwards.

That was a long rant... I apologize, as I didn't have time to write a short
rant.

Knut Meidal


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Curtis
Preston
Sent: Sunday, May 13, 2007 10:58 PM
To: Liddle, Stuart; [EMAIL PROTECTED];
VERITAS-BU@mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Newbie to Netbackup using VTL

Stuart Liddle said:
>NODon't use Vault to duplicate from VTL to physical tape!!!

Looks like it's my week to disagree with you, Stuart. 
(Sorry.  I love ya' man!)

>We tried this, and in NB 5.1 MP6, Vault is a HOG!!  We were not able to
>Keep the drives spinning fast enough using Vault.  The best speeds we
saw >going to physical tape using vault was maybe 30MB/sec.  Usually we
got 
>around 10MB/sec or lesswhich is definitely not a good thing.

I've been able to get Vault to go MUCH faster than that. I would say
there are keys to doing it right.  The biggest one I see is that you
should either use multiplexing or not.  Don't mpx to tape (or virtual
tape) and then de-mpx when you copy.  VTL will suck just as bad as
regular tape w