> You may be between a rock and a hard place with that restoral...  The client
> admin is performing a point-in-time restoral, which may or may not suppress
No
> Query Restore (see client manual) functionality; but either way you may be
> hosed.  If No Query Restore is in effect, your server is doing sorting duty
on
> those millions of files you reported are in that file system (times a
> multiplier; see below), and if your server/system is constrained,
particularly
> on memory, it's going to choke.  If No Query Restore is not in effect, then
the
> info about those millions of files gets shoveled to the client for it to
plow
> through and sort and finally request files, and rare is the client which has
> abundant power for that to occur expeditiously.  (Realize that the amount of
> file info for such a restoral is much worse than for a normal incremental
> backup, in that the latter only works on a list of Active files, whereas the
> restoral is working both Active and Inactive files, which is some multiple.)
>
> All in all, this is one of those "plan ahead" issues where client and server
> must be sized to be able to do what we intend to do with them throughout
> their integrated lives.  I don't think there's a simple solution to your
> problem, except to devote as much resources as can be to getting through
> this restoral, and regroup afterward to consider infrastructure
improvements.
> If the restoral can in any way be "divided and conquered" by specifying
> individual files, that could help.

We have discovered that 'query backup' commands with same file selection
criteria complete within tens of seconds, and report less than 800 files.
Sorting that number of files by location should not be a major problem
either.