Re: [Veritas-bu] Sun Servers

[Valenze, Christopher]

My customer uses M series for Master servers and T series for Media
servers.  When I was at Symantec this issue came up quite often.  The
general advice was that if you could afford it, the M Series was better for
the master.  There was also discussions of future changes to NBU to make it
more performant on the T series.

Of course if your budget is limited, then it would be nice if you could
provide some information on your projected load (Tuning Guide stuff like #
of media servers, jobs, etc) as to whether it will really be necessary to
go to the M.

Also, if you're rolling out a new server you really need to look to the
future and ask your Symantec SE if any of the changes in 7.5 will cause
additional load on the Master.  It's in public beta so you can see the
changes.  NetBackup Search, which I believe is indexing of the catalog, is
one feature that concerns me in regards to load, but I haven't had time to
try the Beta in my lab yet.


On Mon, Dec 5, 2011 at 3:30 PM, Carl Mathews  wrote:

> Is a T-series Sun master server a good choice for Netbackup 7  compared to
> a M-series, or linux?  The M-series is more expensive for a machine with
> the same amount of RAM.  Are there shops running NB 7 on T-series machines?
>  Is it true that Sybase doesn't perform well on a T-series?We are
> running Netbackup 6.5.5 on a T2000 and it works fine,  but we need a new
> server for NB 7.  I would like to stay with Solaris.
>
> Thanks Carl Mathews
> University of Arkansas
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>



-- 
Chris Valenze
BlackArrow
ch...@batechp.com
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Netbackup to VTL fast with first tape then slow thereafter

[Valenze, Christopher]

I would try to isolate the problem.

Take two new tapes from the VTL.
Move them to a new pool
Create a test policy that backs up directly to the VTL and fills the two
tapes.
See if that repeats the behavior of the second tape being.  This will tell
you whether duplication is involved.
If the second tape is slow:
   expire all images on test tapes with bpexpdate.
Repeat the backup.
If the problem goes away then the VTL tape is only slow on the first write.
 If not, you have a different problem.

Chris V.

On Thu, Jun 9, 2011 at 12:35 PM, nmagsaysay wrote:

> I'm writing my jobs to VTL then using SLP to get them to LTO5.  I've
> noticed that when i start a job it jumps right up and the speed is 25MB -
> 40MB then after the "tape" fills and a second one is "loaded" the KB/Sec
> drops to 2MB - 4MB and the speed never raises for subsequent "tapes".
>
> However when I write directly to LTO5 the jobs average 40MB - 60MB.  Using
> an EMC Clarion VTL.  Any advice would be greatly appreciated.
>
> Is there a log in NBU that would indicate these write speed fluctuations?
>  Any thoughts would be greatly appreciated.
>
> +--
> |This was sent by nmagsay...@gmail.com via Backup Central.
> |Forward SPAM to ab...@backupcentral.com.
> +--
>
>
> ___
> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>



-- 
Chris Valenze
BlackArrow
ch...@batechp.com
410-935-1397
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] why oh why!!!! Did Symantec REALLY say this

[Valenze, Christopher]

The "problem" with NetBackup is that it supports a greater diversity of
master and media server platforms than almost any competitor.  That makes
the testing matrix very unwieldy.   From my experiences when I was at
Symantec/VERITAS, I doubt they will ever change this.  However, as you say,
it works for filesystem backups to go up or down in rev and it probably
always will.

Chris V.

On Thu, May 5, 2011 at 1:00 PM,  wrote:

> They told him that because it works. We've done this for years but only
> when necessary and only on file level backups. We do not support using this
> method to backup a database, exchange or even system state because we can't
> rely on a restore due to issues with possible feature enhancements in the
> client that aren't any where else. The file level restores have always
> worked fine, though you are on your own since it's not officially supported.
>
> If Symantec is listening, I would like for them to support higher client
> rev's on a down rev master. It really is a pain to upgrade many sites to
> support a new feature. Some of their competitors support this.
>
> *Rusty Major, MCSE, BCFP, VCS* ▪ Sr. Storage Engineer ▪ SunGard
> Availability Services ▪ 757 N. Eldridge Suite 200, Houston TX 77079 ▪
> 281-584-4693
> Keeping People and Information Connected® ▪ *
> http://availability.sungard.com/* 
> P *Think before you print*
> CONFIDENTIALITY:  This e-mail (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited.  If you received this e-mail in error,
> please notify the sender and delete this e-mail from your system.
>
>
>  *"WEAVER, Simon (external)" *
> Sent by: 
>
> 05/05/2011 11:20 AM
>   To
> smpt , , <
> veritas-bu@mailman.eng.auburn.edu>
> cc
>   Subject
> Re: [Veritas-bu] why oh why Did Symantec REALLY say this
>
>
>
>
> Concern I have is that can you really rely on it. There may be enhancements
> to the product that the Master knows little about.
> If you have support with Symantec, and best practice is to follow what I
> have been doing 10+ years, should that be the best course of action?
>
> Of course, That's not to say running 5.1 on 7.0.1 clients is supported,
> because its not and I appreciate that, and would not expect support.
>
>
> --
> *From:* smpt [mailto:sm...@peppas.gr ] *
> Sent:* 05 May 2011 16:24*
> To:* WEAVER, Simon (external); scott.geo...@parker.com;
> veritas-bu@mailman.eng.auburn.edu*
> Subject:* RE: [Veritas-bu] why oh why Did Symantec REALLY say this
>
> Well, it is not supported but is  working.
>
> *From:* veritas-bu-boun...@mailman.eng.auburn.edu [
> mailto:veritas-bu-boun...@mailman.eng.auburn.edu]
> *On Behalf Of *WEAVER, Simon (external)*
> Sent:* Thursday, May 05, 2011 6:04 PM*
> To:* scott.geo...@parker.com; veritas-bu@mailman.eng.auburn.edu*
> Subject:* Re: [Veritas-bu] why oh why Did Symantec REALLY say this
>
> Sure I read somewhere this was bad practice, but for life of me cant
> find it!
>
>
> --
>
> *From:* veritas-bu-boun...@mailman.eng.auburn.edu [
> mailto:veritas-bu-boun...@mailman.eng.auburn.edu]
> *On Behalf Of *scott.geo...@parker.com*
> Sent:* 05 May 2011 15:33*
> To:* veritas-bu@mailman.eng.auburn.edu*
> Subject:* Re: [Veritas-bu] why oh why Did Symantec REALLY say this
> We found this out all on our own, without Symantec's blessing.
>
> They came a little late with their 2008 R2 support, so they let this go on
> for CYA.  We were doing this before we went to 7.0.1.
>
> When you are caught in the dilemma of getting backups or being supported,
> well, I choose the former.
>
>
>
>  From: "WEAVER, Simon \(external\)"   To: <
> veritas-bu@mailman.eng.auburn.edu>  Date: 05/05/2011 10:27 AM  Subject: 
> [Veritas-bu]
> why oh why Did Symantec REALLY say this  Sent by:
> veritas-bu-boun...@mailman.eng.auburn.edu
>
>
> --
>
>
>
>
> All
> From my History of working with NBU, any upgrades I have done have been in
> this order:
> Master
> Media Servers
> SAN Media
> Clients
>
> So ... why would Symantec be telling a colleage that "its ok to oto 6.5.6
> on a client and leave Master at 6.5.4" ?
> Client OS is Wink28 R2 SP1 which cant be backed up correctly 6.5.4 but runs
> fine and supported under 6.5.6 and 7.0.1
> S.
>
>  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.
> -o-
> Astrium Limited, Registered in England and Wales No. 2449259
> Reg