Conference decwet::networker

I should mention that I am running Digital UNIX 4.0B on the server and client,
and Networker 4.2B with 3 patches for the client and server. I am trying to
recover using nwrecover since the indexes are still online.

Thanks,
Chris

	This sound like a serious problem but a quick workaround
	may be to use save set recover.  This will just dump
	all the data to disk without building the big file list and
	might get around your problem.

	Look up the SSID of the file system that you are trying to get 
	and use the -S switch on the command line recover program.

	man recover and man mminfo should help.

Why am I getting this error, do I have a bad tape, is 32Gb to big to restore?

I am not running save set recover, out of Networker. But, that seems like
it could take forever. The sessions window says that its reading 2MB of 36Gb.
Based on that I could be here all day.

Is save set recover the right way to go, you mention SSID and mminfo and
recover. I'm not doing that with the save set recover.

Is it possible for you to give me a call, this is very very important data
for an Eng. project and I have to get it restored as quick as possible.

My dtn is 223-5193.

Thanks,
Chris

In testing for NetWorker V4.3 on Digital UNIX V4.0B, we had problems
recovering a very large number of files in a single recover, and it 
turned out to be a system resource problem, where the recover process 
would run out of space while building a representation in memory of 
the tree to be recovered. You could test to see if this is the problem 
by doing the following:

 Before starting the recover process, run the limit command and set the
 datasize to be unlimited.

Then do your recover, and hopefully it will work.

Steven Yee will be posting more information about a permanent solution
to this resource problem sometime soon.

In your case, I think Legato would recommend that you use save set recover.
See the help text for save set recover in the nwadmin GUI.

Debbie

	Also save set recover is MUCH faster.  You don't loose anything
	if you are restoring a full backup anyway.

How does Saveset differ from the recover process, in terms of the way  
memory is allocated. Is the memory issue and the limit command on the Networker
server side or the client side.

I'm still in the process of doing the rebuild right now, but
it doesn't seem any faster. In fact it took a good 45 min. to an hour
to load the indexes, if that's what it was doing, before the recover started
writing files.

Thanks,
Chris

doing a saveset restore, just streams the data to the disk, when doing
a recover, the indicies are browsed and sorted (building lots of internal
structures) to try and accommodate finding the "latest" rev, and account for
deletions amoung the last full and all subsequent incrementals.

If all you have is a full, then saveset recover is just a fine route -- if,
though you have subsequent incrementals, you'll have to do saveset restore for
each of the incrementals too, and I think you'll end up with the previously
deleted files on your disk also.

The other document regarding system resources should be posted by the end of the
week.

steve.

When I started up the save restore, I highlighted the full, from May2, and
all the subsequent backups up until yesterday. I thought that this would
insure I got the last full and all updates until yesterday. I just told
Save Restore to overwrite the current file if one exists, this would get me
the most current file.

Is the right way to do a complete disk rebuild.

Ok, I think we might be confusing you with our terminology..

When we refer to doing a saveset restore, we're referring to the "-S" option
of recover, that is the case where the whole save set is streamed to disk, and
you must also restore all subsequent incrementals.

I believe, that when you use the GUI, you're doing the equivilent of a normal
(selective/browsing) recover. This scenerio (browsing indexes) is what causes
(potential) memory limitations.

Try the limit datasize unlimited option before starting up the GUI.

You can also look at Note 51.3 for a better description of some of the 
memory issues.

steve.