>We have retried the restore with the trailing slashes, and things have >not gotten any better.
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. Richard Sims, BU
