ADSM-L

Re: Restore performance

2003-03-13 11:03:41
Subject: Re: Restore performance
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 13 Mar 2003 11:03:07 -0500
>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

<Prev in Thread] Current Thread [Next in Thread>