Hmmm, well that seems fairly stupid.  Make a directive that says don't
back anything up?  I could understand making a directive that said don't
make it "all user friendly like" by eliminating the overhead of
browseable files but not to make it so you can't restore it at all
without the native restore commands?  And what if you were using the NBU
format instead of gnu tar?  You'd be totally screwed no?

~JK

Steve Kappel wrote:
> 
> Jeff Kennedy wrote:
> >I was under the impression that all this did was not allow browsing in
> >NBU but that the data was still there, if you knew what you were after.
> >So for disaster recovery it was fine, or if you knew the path to the
> >data you could enter it and still restore.  Is this incorrect?
> 
> I am not aware of any mechanism in NetBackup that allows a restore
> to specify an object that is not in the catalog.
> 
> You could do a manual restore on the filer using the native restore
> command.  Of course this would require figuring out which tape
> and file # it is in.
> 
> >Steve Kappel wrote:
> >>
> >> Jeff Kennedy wrote:
> >> >Would the directive 'set HIST=N' help this situation?
> >>
> >> Sure, if you don't need to be able to restore parts of the backup.
> >> HIST=N means no file history so all that will be in the catalog
> >> is the backup directory; that is all that you could restore using
> >> NetBackup.
> >>
> >> >Steve Kappel wrote:
> >> >>
> >> >> Jeff Kennedy wrote:
> >> >> >But the data has stoped being transferred 10 hours earlier.  I have 3
> >> >> >ndmp backups that are running 24+ hours but no data has moved for over 
> >> >> >6
> >> >> >hours.  The filer is doing nothing and the ndmp session is halted
> >> >> >because the backup is complete, all it's waiting for is a close message
> >> >> >from NBU.
> >> >> >
> >> >> >I checked some stats on my NBU server and the root disk is fairly
> >> >> >hammered, it's reading at 3MB/sec with nothing else going on; no other
> >> >> >backups, no restores.  And this server is dedicated to backups, no 
> >> >> >other
> >> >> >services.
> >> >> >
> >> >> >The images are all on an A5000 so it's not writing the images (btw, the
> >> >> >A5000 is idle too).  The only thing I can figure is the BPFSMAP_TMP
> >> >> >directory that holds an inode map for each ndmp session.  These files
> >> >> >are fairly huge, 300MB's to 800MB's each.  What I'm wondering is what's
> >> >> >happening at this point in the backup?  The inode maps are run at the
> >> >> >beginning of the backup on the filer so what is happening after the
> >> >> >backup is complete?  Is this verification of some type?
> >> >>
> >> >> Node-based NDMP file history (that is messages containing "DIR" and
> >> >> "NODE" info) must be collected until the end of the backup and
> >> >> then processed to convert into the full path catalogs used by
> >> >> NetBackup.  We call this the "bpfsmap phase".  It is responsible
> >> >> for the temporary files in BPFSMAP_TMPDIR as well as the memory
> >> >> utilization.  Both resources vary by the number of objects in
> >> >> the backup.  See the NetBackup NDMP Admin Guide for information.
> >> >>
> >> >> The NDMP session cannot be finished nor the tape released as
> >> >> the converted catalog needs to be written to tape.
> >> >>
> >> >> The upcoming 4.5 release will radically improve this.
> >> >>
> >> >> __________________________________________________________________________
> >> >> Steve Kappel                       steve.kappel AT veritas DOT com
> >> >> VERITAS Software (Engineering)     steve AT stevekappel DOT com 
> >> >> (Personal)
> >> >
> >> >--
> >> >=====================
> >> >Jeff Kennedy
> >> >Unix Administrator
> >> >AMCC
> >> >jlkennedy AT amcc DOT com
> >>
> >> __________________________________________________________________________
> >> Steve Kappel                       steve.kappel AT veritas DOT com
> >> VERITAS Software (Engineering)     steve AT stevekappel DOT com (Personal)
> >
> >--
> >=====================
> >Jeff Kennedy
> >Unix Administrator
> >AMCC
> >jlkennedy AT amcc DOT com
> 
> __________________________________________________________________________
> Steve Kappel                       steve.kappel AT veritas DOT com
> VERITAS Software (Engineering)     steve AT stevekappel DOT com (Personal)

-- 
=====================
Jeff Kennedy
Unix Administrator
AMCC
jlkennedy AT amcc DOT com