AFAIK, NQR isn't something you can "pick and choose" - if it was, I would.

>From the book:

When you enter an unrestricted wildcard source file specification on the
restore command and do not specify any of the options: inactive, latest,
pick, fromdate, todate, or |volinformation, the client uses a no query
restore method for restoring files and directories from the server. This
method is called no query restore because instead of querying the server
for each object to be restored, a single restore request is sent to the
server. In this case, the server returns the files and directories to the
client without further action by the client. The client merely accepts the
data coming from the server and restores it to the destination named on
the restore command.

What is killing me is having to restore inactive file (the server
corruption completely killed a big directory that the OS says is now
"empty" so the TSM backup marked everything "inactive").

In my opinion, these restrictions for NQR plus the issue of not having an
equivalent of MEMORYEFFICIENT for restores, is a major problem/weakness in
TSM.

I have spent the past 3+ days (and will be working throughout the weekend)
to restore these files.  I keep having to drill further and further into
each directory structure to guess which directory I can attempt to
restore.  Every time I click on a directory and attempt a restore, the
process runs for 30-minutes transferring 2G or more of meta-data before it
eventually fails on "insufficient memory" or I am lucky enough to pick one
that restores.  Then I have to start all over again, keep track of where I
am and what I was able to restore, drill further down,
rinse-lather-repeat!  Besides the 22M objects, there is 700GB of data to
process/wander through.

What good is having 50M objects of backups if I can't restore them in a
reasonable fashion?



From:
"Laughlin, Lisa" <Lisa.Laughlin AT OA.MO DOT GOV>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
12/09/2009 11:15 AM
Subject:
Re: [ADSM-L] Restoring LARGE server
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



How about using just the CLI and the no-query restore option?

thanks!
lisa


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Ochs, Duane
> Sent: Wednesday, December 09, 2009 9:57 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Restoring LARGE server
>
> Zoltan,
> Have you attempted a Point in Time restore from command line?
> That might help with the number of inactive files you are
experiencing.
> If that is not an option, you may have to go a couple directories at a
> time.
>
> I have only had experience restoring up to 9M files and the one time I
> did it used PIT and worked fine, turned maxmp up to 4. It certainly
> took a while. But it did complete.
>
> What OS are you using on the client ?
>
>
> Duane
>
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Zoltan Forray/AC/VCU
> Sent: Wednesday, December 09, 2009 7:51 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Restoring LARGE server
>
> Trying to restore a LARGE Windows server.  Over 40M objects.  Client
is
> 6.1
>
> As you can imagine, we have had to use the journal as well as
> MEMORYEFFICIENT to perform backups.
>
> If I read correctly, MEMORYEFFICIENT is ONLY for backups.  Obviously
> the
> journal is of no value since the restore is to a new machine/location.
>
> The other issue gumming up the works is that the backups have been
> failing
> (drive array problems/corruption) and thus TSM has marked almost
> everything
> as "inactive".  A first, NQR restore (just selected the drive) attempt
> only
> restored 90GB (of 600G+) before "finishing successfully".  But when I
> choose to pick inactive as well as active, the NQR is disabled.
>
> The server transfers down 1GB of metadata before the client chokes on
> "insufficient memory".
>
> So, how am I supposed to restore this many objects, besides picking
one
> directory at a time, which is not to say that some directories are
> large
> enough to also cause a "not enough memory" situation?
>
> Suggestions on how to handle this?