Thanks, Darren!
Yes, I was referring to having 'store index entries' set to 'yes'. You
confirmed what I thought about the indexes. If you have this feature set
to yes, then using nwrecover is obviously nice because it doesn't
recover previously deleted files, but it can be slow as a dog at times,
making saveset recover a faster option in many cases and preferred even
though you get the deleted files back that you don't want. I think for
the most part, getting back the deleted files is okay for us and is
certainly a small price to pay in exchage for geting the other data back
that was not meant to be deleted!
But there are a few cases wherein one would really not want to recover
previously deleted files. For example, consider data that's going to be
ingested into a database or some such thing and is sitting in a holding
area pending further action. Maybe somebody wipes out some or all of the
data so you have to recover it, and if you use saveset recover then you
end up with a bunch of previously deleted files, so someone will then
have to get rid of those before they can ingest it which means searching
through the whole directory to figure out what should no longer be
there. That could be a lot of work, but the question is: "Is that more
work than waiting for nwrecover to finally wake up?" LOL! I guess it's a
trade off. Of course, if it was just a small directory under the main
one then you could just specify that on the recover paths window of
nwrecover and this wouldn't be so bad, but having to recover the whole
enchilada might result in a lot of effort to locate and remove those
"previously deleted" files since you might be dealing with a lot of
them. I guess I can always tell people the advantages and disadvantages
of each method and let them decide. As long as they understand then it's
fine by me.
George
Darren Dunham wrote:
>
> >
> > 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.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
