Greg Etling wrote:

> Interesting that it would appear then that EMC's own documentation and
> support reps have led me astray on this! The scanner -i suggestion
> (which the man page says "Rebuilds both the media and the online file
> indexes from the volumes read.") came from both the 7.4 DR Guide (pg.
> 46) and from an EMC support rep. 

They're correct. Scanner rebuilds the media database and optionally the
client file index from the data save sets on the tape, but not from a
backed up index on the tape.

> I can certainly see that concurrent saveset IDs could cause a problem -
> but what I fail to see is how they don't become a problem in all
> scenarios you describe. Either via scanning in all old savesets or
> scanning as necessary; if you hit a saveset with a duplicate ssid,
> wouldn't you cause the same problems? And does the conflict arise from
> standard ssids, long ssids, or both? I only appear to have one short
> ssid conflict and no long ssid conflicts.

That's a good question and I am not certain of the answer. I assume that
it will renumber save sets as it scans them.

> Lastly, in scenarios 1 and 2, recognizing the limitations you have
> described, how do you use scanner to scan in savesets from which you
> need to restore, if the media db entries do not exist? Given that our
> retention period for these save sets is only three months, I will likely
> use scenario 2 but before I go forward I need to be sure to know how to
> run saveset and file level restores in the intervening three months.

Part of what scanner does is to recreate the media database entries as
it goes.

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