[Veritas-bu] NBU 5.1 MP5 Flashbackup using nbu

Thanks Phil,  I'd given up on hearing a response on this one.  From the
list of gotchas you provided, I should be aok.
 
I've asked the same question to Symantec, and they replied with a "I'll
get back to you" about a week ago.  Ie: not the kind of response you
want to show management when you're trying to convince them we should be
changing the way we do something...
 
Cheers,
Jon

________________________________

From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Weber,
Philip
Sent: Tuesday, September 05, 2006 11:04 AM
To: veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] NBU 5.1 MP5 Flashbackup using nbu_snap


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

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

________________________________



Egg is a trading name of the Egg group of companies which includes:
Egg plc (reg no
2448340), Egg Financial Intermediation Ltd 
(reg no 3828289), and Egg Banking plc (reg 
no 2999842). Egg Banking plc and Egg 
Financial Intermediation Ltd are authorised 
and regulated by the Financial Services 
Authority (FSA) and are entered in the FSA 
register under numbers 205621 and 309551 
respectively. These members of the Egg group 
are registered in England and Wales. 
Registered office: 1 Waterhouse Square, 138-
142 Holborn, London EC1N 2NA.


This e-mail is confidential and for use by 
the addressee only. If you are not the 
intended recipient of this e-mail and have 
received it in error, please return the 
message to the sender by replying to it and 
then delete it from your mailbox. Internet e-
mails are not necessarily secure. The Egg 
group of companies do not accept 
responsibility for changes made to this 
message after it was sent.


Whilst all reasonable care has been taken to 
avoid the transmission of viruses, it is the 
responsibility of the recipient to ensure 
that the onward transmission, opening or use 
of this message and any attachments will not 
adversely affect its systems or data. No 
responsibility is accepted by the Egg group 
of companies in this regard and the 
recipient should carry out such virus and 
other checks as it considers appropriate.

This communication does not create or modify 
any contract.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060905/82bcdfaa/attachment-0001.html