Hi Richard,
started again the whole thing and
-enabled the NQR again
-get again the v5.3.0.0 client
-added tcpwindowsize 64
tcpbuffsize 32
largecommbuffers no
txnbytelimit 25600
to dsm.sys ...
The client and Server have both gigabit.
Finally I raised the BufPoolSize on the server.
The restore-command without any options
'dsmc restore -quiet /mail/ /data2/mail/'
now works quite ok - it is still running at about 7 GB/h
( slightly getting faster ).
Not very much --- but the data really transfered right from the beginning.
There are 140 GB / 3.5 mio Files to be restored. ( it is just a test )
Another general restore-question here is: the server knows what files are to be
restored and the server also knows what tapes are needed ...
... so why is only one tape mounted at one time ?
The backup data of this client is on a node-collocated Tapepool
and I have free unmounted tapes. The whole data of the client
resides on about 10 magstar-cartridges. I think here in this
example I would now have about 14 GB / hour using two tape-drives
with one restore session.
I think there is a need for using more than one drive at a
single restore-session, for filesystems are growing and growing .
Greetings ,
Rainer
Richard Sims wrote:
>
> Hi, Rainer -
>
> Unfortunately, implicit restorals (where you do not explicitly name
> objects to be restored) has become a difficult challenge in the
> product, and remains a muddled area which sorely needs to finally be
> straightened out by Development, as the product should figure out the
> best approach: the mess should not be left to the befuddled,
> exasperated customer.
>
> In some cases, suppression of the more modern No Query Restore, by
> explicit suppression or involvement of qualifying restoral options, can
> improve restoral time, as Classic/Standard protocols are in play and a
> files list is promptly sent to the client and it can make its choice.
> This is what prompted you to add DISABLENQR to your option file. More
> often, you want No Query Restore to be in effect, though, such that the
> server generates the list of files to send to the client. However, the
> client's memory and processing power may be overwhelmed by the volume
> of files information (not to mention the time to send it over the
> network). With NQR in effect, customers get concerned as they see
> nothing coming back from the server for some time and wonder what's
> going on.
>
> Whereas you suppressed NQR, you are seeing the client examining the
> inventory list, and the client is probably slowing as its virtual
> storage is taxed and paging increases. In your wholesale restoral, NQR
> may be the better choice, as the server may have better resources to
> generate the list. Then again, it may take as long.
>
> I wish there were a better answer: none of us wants to have to deal
> with such quandries.
>
> Richard Sims
--
--------------------------------------------------------------------------
Rainer Wolf Mail: [EMAIL PROTECTED]
Kommunikations und Informationszentrum Tel/Fax: ++49 731 50-22482/22471
Abt. Infrastruktur, Uni Ulm Web: http://kiz.uni-ulm.de/
