On Wed, 28 Jul 2004, George Sinclair wrote:
>
>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? What's the advantage of saveset recover *IF*
>you have an index and you're recovering data within the browse policy?

The advantage is the saveset recover will recover much faster. This
advantage is only beneficial when you're in a hurry to do a recover and
you're recovering a large amount of data, such as would happen after a
disk failure. Of course, you'll get back more data than you expect if your
users did infact delete files.

>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.

We rarely use nwrecover here, mainly because its a lot easier to issue
recover utility commands by typing them than navigating through menus.

What I find really incredulous is that you actually have users who delete
files. The users here seem to have this misperception that disk space is
an infinite resource and my management seems to encourage that perception!

--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=