> 
> If you have something you need to recover, and it's beyond the browse 
> policy, is there any way to speed up the saveset recover process? 
> Obviously, with the saveset recover GUI window you have no options, but 
> thought I remember seeing something about being able to run recover -S 
> ssid with some other option or pipe to some other command to expedite? 
> Might be thinking of uasm with scanner? Thought it involved uasm but 
> might be thinking of something else.

That doesn't really speed anything up.  

With a full saveset recover, you don't know where anything is so you're
reading the whole saveset.  That's pretty much the whole time that's
spent.

If your network or target filesystem is the bottleneck instead of the
tape and you only need a small amount of the data, it might be faster to
restore locally to the networker server, then copy the data you need.
Piping through uasm might also let you specify only a few files.  It
wouldn't be faster from a tape point of view, but it could reduce other
bottlenecks that are slowing you.

Recover writes directly to the filesystem, so I can't think of any way
to usefully pipe the output into anything.  You could do scanner|uasm if
you wanted to file limitation.

> Just want to clarify my understanding here:
> If you're not using something like nsrck -L7 to merge in an older index, 
> and you're gonna instead use saveset recover to rebuild a directory then 
> you have to select the last full (depending), and all of the 
> incrementals from the full up to the most recent time you want since you 
> don't know which saveset instances would have the directory and which 
> would not. If the directory only changed a few times since the last full 
> then it might not be on all those savesets, but unless you knew, you'd 
> have to play it safe and select all of them, right? Seems a bummer since 
> some of those savesets might be very large and might not even have that 
> directory on them if no changes occurred that day, but guess there's no 
> other way. Gotta byte the bullet.

Or don't use 'incr'...  :-)  That's one of the advantages of doing
something like full,9,9,9,9,9,9.  A little more tape used, fewer tapes
needed on restore.

> If the saveset was 300 GB, and you only needed to recover a 2 MB 
> directory then I guess saveset recover must read through the entire 
> saveset, so even if what you want is right at the beginning, unless 
> you're absolutely certain you have all your data, you have to let it 
> continue to read every thing else, right?

Correct.  

Now, you can be reasonably certain that 'save' is running the FS tree in
some sort of file order.  It's not going to be doing (say) inode order.
I'd feel *pretty* safe if I only wanted one subdirectory if it started
doing it then moved on that it wasn't going to go back.


-- 
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 listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=