On Thu, Nov 12, 2009 at 02:48:40PM -0500, Francis Swasey wrote:
> I have a windows system that we have been backing up and it may have 
> index corruption or it may have such a convoluted series of mounted 
> directories that the data is just not being backed up.
> 
> I am able to use nsrinfo to see that the directory (empty) was backed up 
> on the last full save -- and that another directory that the system 
> admin originally said was not available is completely there.  I am able 
> to use "recover -t <nsavetime of last full> -c <client>" and browse into 
> the D:\users directory -- as nsrinfo says I should, and not into 
> D:\BHCommon as nsrinfo also says I should not.

Not sure I understand.  You're saying something appears in the index,
but when you try to recover it, it fails?  Or that something is in the
index, but it shouldn't have been backed up in the first place?

> Question:  Is there a way to see what was really backed up (short of 
> doing a full recover of the ssid)?  If the answer is scanner -- help my 
> feeble brain figure out what options to pass to it.

Why do you suspect the indexes are incorrect?  A full ssid recover is
the *best* way to know what's recoverable, but takes a lot of space.

See the 'scanner' page for a command line of how to do it.  Add -n to
uasm to not actually recover the files.  Something like:

scanner -S <SSID> <tapedev> -x uasm -rnv

I think the -v argument to uasm will cause it to display all files.
Because it's reading the entire filesystem, this may not be
significantly faster than actually doing a ssid recovery.  But it
doesn't consume disk space.

-- 
Darren

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER