Re: [Veritas-bu] Linux Restore Procedure

[Rusty . Major]

Most likely the directory structure under the "Browse Directory:" text box 
is not correct. It seems to want to load the logged in user's home 
directory by default. Change it to just "/" (without quotes...) and that 
will show you everything that was backed up.

If anyone knows how to force it to the default of / I would appreciate 
knowing.

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. 



"McDonald II, James F."  
Sent by: veritas-bu-boun...@mailman.eng.auburn.edu
04/03/2009 09:43 AM

To

cc

Subject
[Veritas-bu] Linux Restore Procedure






I have finally gotten NetBackup installed in a mixed environment and 
working properly.  I was testing the restore on the Windows side and it 
appears to be working fine, but I’m a little lost on how to do a restore 
on the Linux side.  I tried to do one from NBU master server, but the 
Linux servers won’t display any of their directories in the network tree. 
How do you perform a restore on a Linux server either from the 
command-line on the Linux machine?  Is there something I can do to get the 
directories of my Linux servers to show up in the network tree of the 
Backup, Archive, Restore option on the NBU master?
 
(NBU Master is Windows Server 2003; Linux machine has REHL 5.0; NetBackup 
version is NBU 6.5 for Windows)
___
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] Unable to write data for some clients

[Marianne Van Den Berg]

Check bpbkar log on client. 
What O/S?

-Original Message-
From: NBU 
Sent: 03 April 2009 08:49
To: VERITAS-BU@MAILMAN.ENG.AUBURN.EDU 
Subject: [Veritas-bu]  Unable to write data for some clients


Hi Forum,

Few clients thats gets fired during the backup cycle doesn't write anything and 
remains ACTIVE for hours. It shows begin writing but no data transfer is seen.

Netbackup version is 6.0 MP6

Pls. help.

+--
|This was sent by qureshiu...@rediffmail.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___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

[Veritas-bu] Linux Restore Procedure

[McDonald II, James F.]

I have finally gotten NetBackup installed in a mixed environment and
working properly.  I was testing the restore on the Windows side and it
appears to be working fine, but I'm a little lost on how to do a restore
on the Linux side.  I tried to do one from NBU master server, but the
Linux servers won't display any of their directories in the network
tree.  How do you perform a restore on a Linux server either from the
command-line on the Linux machine?  Is there something I can do to get
the directories of my Linux servers to show up in the network tree of
the Backup, Archive, Restore option on the NBU master?

 

(NBU Master is Windows Server 2003; Linux machine has REHL 5.0;
NetBackup version is NBU 6.5 for Windows)

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

Re: [Veritas-bu] Question on how to exclude Files in subdirectories on certain FS only

[Larry Mascarenhas]

Thanks. Food for thought.

Ed Wilts wrote:
> On Thu, Apr 2, 2009 at 8:06 PM, Larry Mascarenhas  > wrote:
> 
> I have a scenario whereby I want to exclude a type of file in a FS. eg I
> have /u, /u1 etc. Each of these FS have subdirectories
> /u/subdir1,
> /u/subdir1/subdir2...
> /u/subdir2/subdir3
> 
> /u1/subdir1/subdir2...
> /u1/subdir2/subdir3...
> 
> ... etc)
> 
> The go down a few (maybe 5-6) levels.
> 
> I need to exclude files (eg *.o) in FS /u and its subdirectories, but
> not in /u1. So my exclude file looks like this
> 
> /u/subdir*/*.o
> /u/subdir*/*/*.o
> 
> Apart from slowing down my processing (the .o files is just an example),
> it will actually speed up the backup because I can exclude 500Gig off a
> 700Gig FS.
> 
> But of course, this doesn't work too well. Any pointers in the general
> direction regarding setting up a good regular expression match would
> help tremendously. Thanks.
> 
> 
> Includes take precedence over excludes so you can probably do an exclude 
> of *.o, then an include of the more specific directories that you really 
> do want backed up.  This is the approach we do for database files - an 
> exclude of ORADATA in the general policy and then an explicit include in 
> the database-specific policy.  I'd probably break that u1 backup into a 
> special policy - that makes the includes/excludes a bit easier to define 
> and understand.
> 
> Obviously careful testing is required.
> 
>.../Ed
> 
> -- 
> Ed Wilts, Mounds View, MN, USA
> ewi...@ewilts.org 
> 

-- 

Larry Mascarenhas
lmasc...@comcast.net
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Slow Informix Logs backups

[Larry Mascarenhas]

Hi Patrick,

Thanks for your reply.
1. I'm running NBU v6.5.1.

2. I believe I see a lot of subjobs for the logs and yes I have 
multistreaming enabled on the policy. In fact the 300G DB backs up in a 
<1hour, but 30Gig of logs takes 3 hours.

3. Onbar streams for DB backups. For logs, it opens 1 onbar process (the 
same one that backed up the DB) and ships the logs sequentially. That's 
non-configurable (I'm pretty sure).

Patrick wrote:
> I didn't notice which version of NBU so I'll assume the latest. In the
> activity monitor do you see a parent job with a lot of sub jobs for the log
> files? Does the policy allow multistreaming? On the ONBAR side can you
> specify single or multiple streams? Just some thoughts.
> 
> Regards,
>  
> Patrick Whelan
> VERITAS Certified NetBackup Support Engineer for UNIX.
> VERITAS Certified NetBackup Support Engineer for Windows.
> 
> netbac...@whelan-consulting.co.uk
> 
> 
> 
> -Original Message-
> From: veritas-bu-boun...@mailman.eng.auburn.edu
> [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Larry
> Mascarenhas
> Sent: 03 April 2009 01:55
> To: Justin Piszcz
> Cc: veritas-bu@mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] Slow Informix Logs backups
> 
> Thanks. Tried this and it eventually does catch up. But this is not the 
> correct solution to the problem. It masks the real issue ie the Informix 
> Module generates a job for each log. The processing of this job is the 
> real reason the log backups are slow (even for disk).
> 
> In reviewing how ONBAR works, it opens 1 connection to NBU and ships the 
>   logs sequentially to it. It is the same onbar process that delivers 
> every log, not separate ones. But NBU treats each log as a separate 
> request and generates a job for it.
> 
> Can you imagine a STREAM for a FS and each file is a separate request 
> and therefore a separate job? I have to escalate this.
> 
> But thanks for this. It is a workaround.
> 
> Justin Piszcz wrote:
>>
>> On Fri, 27 Mar 2009, Larry Mascarenhas wrote:
>>
>>> Hello,
>>>
>>> I'm running backups on Informix7 DBs. We're able to stream the DB
>>> backups using parallelism 4 and get good throughput (100MB/s, yes
>>> megabytes/sec, it is a SAN Media Server). A 300Gig DB takes less than 1
>>> hour.
>>>
>>> However (I know ;)), when it backs up the LOGS (all backups go to tape,
>>> I don't have Disk backups), each log comes in as a separate request.
>>> Each log is therefore a separate job. So the time taken to process this
>>> request is greater than the time to backup each log. ie each log is
>>> 100MB and the time taken is <2secs (when the resource is allocted and
>>> ready), but it takes 1+min to create the job/assign the resource/and
>>> begin writing. This is resulting in my never being able to catch up with
>>> the rate of logs generation although the amount to be backed up is
>>> minimal eg 30logs is just 3Gig, but takes approx 30mins and by that time
>>> 10 more logs are created. I am using media_unmount_delay so the tapes
>>> are not re-mounting for every request.
>>>
>>> I cannot increase the size of the LOGS as this would affect replication
>>> and recoverability (double whammy). This is Symantec's recommendation.
>>>
>>> I'm looking for experiences that people have had to speed up the
>>> Informix backups.
>>>
>>> Thanks.
>>>
>>> -- 
>>>
>>> Larry Mascarenhas
>>> lmasc...@comcast.net
>>> ___
>>> Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
>>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>>>
>> Why not use a Disk Staging Unit if the logs are small enough?
>>
>> Send to disk first -> then shoot to tape?
>>
>> Justin.
>>
> 

-- 

Larry Mascarenhas
lmasc...@comcast.net
___
Veritas-bu maillist  -  Veritas-bu@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

Re: [Veritas-bu] Slow Informix Logs backups

[Justin Piszcz]

On Thu, 2 Apr 2009, Larry Mascarenhas wrote:

> Thanks. Tried this and it eventually does catch up. But this is not the 
> correct solution to the problem. It masks the real issue ie the Informix 
> Module generates a job for each log. The processing of this job is the real 
> reason the log backups are slow (even for disk).
>
> In reviewing how ONBAR works, it opens 1 connection to NBU and ships the 
> logs sequentially to it. It is the same onbar process that delivers every 
> log, not separate ones. But NBU treats each log as a separate request and 
> generates a job for it.
>
> Can you imagine a STREAM for a FS and each file is a separate request and 
> therefore a separate job? I have to escalate this.
Yikes-- agree, this is broken, let us know if you have any updates, thanks.
>
> But thanks for this. It is a workaround.
>
No problem, better to have something working then no backups/problematic
backups.

Justin.

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