>
> Hi,
>
> Here's a question that I think was explained to me one time in the past,
> but I find myself lacking an answer now and I'm confused.
>
> Let's suppose you run a full against something like /0/path and you have
> indexing turned on for the given pool.

What exactly do you mean by that?  Are you talking about having 'store
index entries' set to 'yes' in the pool?

> You then run say 10 incrementals
> over the next 10 days. Prior to the backups, folks are creating,
> modifying and deleting data under /0/path. Now, the incrementals should
> be capturing all the files that have either been added or modified since
> the previous incremental, but what happens to the deleted files? Is the
> index updated with this info? Here's where I'm going with this. If I use
> nwrecover to change the date to the last incremental then I should see
> an exact picture of the way /0/path looked as of the last incremental,
> so any previously deleted files from before that should NOT show up but
> any ones deleted after that should, correct? Isn't this the whole point
> of the index in that it allows you to change the browse time to reflect
> the way the path looked at that time never mind what happened after or
> before?

The indexes store which files are in which saveset.  If you had indexes
off, you would only know that it was a (for example) level 9 backup on
Tuesday at 4:34 am.  You would not know any of the contents.  As a
result, you could not browse the backup in nwrecover.

> If, in this example, you instead used saveset recover to recover the
> original full instance of /0/path, and then you recovered all 10
> incrementals (overwriting any identical file names), then the deleted
> files would be recovered and would not be removed as you progressed
> through the recovers, so you'd end up with the original, the latest
> versions of the modified files and all the files that were ever deleted
> since the full, right? This seems kind of bogus. I mean, you now have
> extra files, right? So what are you to do with those, and how would you
> identify them? It seems clear to me that within the browse policy,
> saveset recover and nwrecover do not really achieve exactly the same
> thing. The files recovered from nwrecover are a subset of what saveset
> recover would result in, right? Am I correct in saying that in the
> example above, saveset recover = newrecover + all the deleted files? Hmm

> Maybe someone can straighten me out here. Why use saveset recover if you
> end up with extra files?

1) It might not matter for you.
2) You might not have a choice (you're past the browse period)
3) It could be faster/easier than doing a 'nwrecover', especially for
   savesets with large numbers of files.

> What's the advantage of saveset recover *IF*
> you have an index and you're recovering data within the browse policy?

It might be much faster than messing with 'nwrecover'.  You might
understand that for your application, recovering previously deleted
files will not cause a problem.

> One reason I can think of is that a huge index can take a long time to
> load, but saveset recover is a no-brainer that requires no real mental
> anguish on the part of the client or the server. We had to run this
> recently because nwrecover just sat there all day and never loaded.

Exactly.



--
Darren Dunham                                           ddunham AT taos DOT com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=