What you say makes perfect sense now that I think about it. After all,
how can you recreate index metadata information if you can't determine
what that should be? And having the file(s) on tape doesn't give you
that. Yes, you have the file(s), but what about the user, group,
permissions, etc? All of that original metadata would have to be saved
to the tape, too, which it would not be with the 'Store index entries'
disabled for the pool.

>>> You are wrong. The 'file attributes' must always be there and will of 
>>> course be recovered. The CFI is solely for browsing. Think about a 
>>> recoverable or recyclable save set - you can still recover the data, but 
>>> you cannot browse the index any more.


BUT could NW determine at least the names from the data as it scans the
tape and then build/update the index that would at least have those file
names? Or is it the case that it can't determine the names from the data
on the tape and depends solely on that CFI information having been
written to the tape?

>>> If you use the command line, you would see all filenames and you could 
>>> redirect that. Using the GUI, there is the networker.log file that you 
>>> could use to verify the files. However, you can not use it for the index. 
>>> This can only be done by running a new backup.


If indexing is turned off for a pool, and some of the media database
entries are later removed, you can still scan the tapes and rebuild the
media database entries for those save set sets, but you can't re-create
the index entries. Correct?

>>> Sure.


I hit the send button too soon. What I meant to say was that assuming
that no CFI information was sent to tape (i.e. indexing was turned off
for the pool) then a subsequent scanner command could still recover the
data, but it's only going to pick up on a limited number of things like
the ssid and save set names as far as what it can rebuild in terms of
information about the data. That would be fine for recreating the media
database entries (assuming those had been removed), but that's not going
to cut it for the index. It would need the file names, minimally, for
that. I guess you'd have to somehow recover the actual data and then
rebuild the indexes from that, but there's no way to do that other than
backing it all up again, this time with the indexing turned on, right?

>>> correct. as i mentioned.


How much longer does it take to rebuild indexes from scanner (assuming
indexing *was* turned on for the pool when the data was written) versus
the time it would take to actaully recover the data? Scanner doesn't
have to read the data to rebuild the indexes, just the CFI information,
so could take quite a while but would still be much faster than actually
reading all the data, correct?

>>> I would assume twice the time for a save set via scanner because
  - you have to read all data during the scanner process.
  - then you have to re-read it during the recover pocess.

+----------------------------------------------------------------------
|This was sent by carsten_reinfeld AT avus-cr DOT de via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------

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