Ok, Dwight, you are "theorically" wright.
In practice, on NT, what if g: size is 2 GB and h: size is 100 GB ?
Restore of g: and h: will restore in parallel during 30 at 60 minutes and h:
will run alone for hours !
The problem is that the principle of VIRTUAL MOUNT POINT does'nt exist for
NT. You can't split easy the restore of an NT BIG filespace .

NT is not Unix ;-)

Francis.

-----Message d'origine-----
De : Dwight Cook <decook AT AMOCO DOT COM>
De : Dwight Cook <decook AT AMOCO DOT COM>
À : ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
Date : mardi 2 févr. 1999 20:54
Objet : Re: NT restore performance for small files


>     Sure it provides an easy way to split restores...!
>     Now backups will run faster as a single thread (multiple concurrent
>     incrementals lock contend with each other to much) BUT with restore
>     processing... you can launch multiple concurrent dsmc restore
>     processes and specify the level of a file system or logical volume
>     (what ever platform your client is on)  say with NT
>        dsmc restore g:\* -subdir=yes -replace=yes -pass=xxx
>        dsmc restore h:\* -subdir=yes -replace=yes -pass=xxx
>     with unix
>        dsmc restore /d001/* -subdir=yes -replace=yes -pass=xxx
>        dsmc restore /d002/* -subdir=yes -replace=yes -pass=xxx
>     if your  file systems are so big you might need multiple concurrent
>     tasks with a single file system break it up with the adsm option
>        "VIRTUALMOUNTPOINT"
>
>     Or just piss off the bean counters and make them buy more servers
>     prior to them getting to a bazillion GB in size ;-)
>
>     later,
>           Dwight
>
>
>______________________________ Reply Separator
_________________________________
>Subject: Re: NT restore performance for small files
>Author:  fr.maes (fr.maes AT CGER DOT BE) at unix,mime
>Date:    2/2/99 3:11 AM
>
>
>Hello Matthias,
>
>This is a very very good question !
>Sorry but I have just the same kind of problems and no solution.
>
>We are using an ADSM V3 MVS server and ADSM V3 NT, AIX and DEC-UX clients.
>Some NT servers are big lan servers with 80 to 100 GB of disk space.
>We have also a restore transfer rate at 1.5 to 2GB / hour / process.
>Our "big" lan servers are now connected via ATM. The restore transfer speed
>is increased at +/- 4GB / hour.
>Max # of backup versions = 8
>Max retention only version = 800 days
>DB size = 51 GB (83% full)
>I mean that the actual version of ADSM is not the perfect way to restore
big
>NT filespaces (more than 20GB).
>ADSM offers no easy way to split backup and restore of a "big" NT filespace
>thru multiple processes.
>
>Will be better in a future release, comme d'habitude!
>
>Courage.
>
>Francis.
>
>
>
>
>
>-----Message d'origine-----
>De : Hensel, Matthias <Matthias.Hensel AT SCHERING DOT DE>
>A : ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
>Date : lundi 1 févr. 1999 17:36
>Objet : NT restore performance for small files
>
>
>>     I would like to know how I can achieve acceptable restore times in
>>     case of disaster of an very big LAN server. We had great
>>expectations
>>     to get better preformance when moving to V3 server/client because
>>of
>>     better tape algorithms and FatPipes etc. Now when we had our first
>>     really big disaster we were kind of disillusioned when seeing the
>>poor
>>     restore "speed".
>>
>>     How can I handle it to get performance beyond 1.5 - 2 GB/h per
>>session
>>     for LAN Server data? Having LAN servers up to 100 GB data capacity,
>>
>>     you can imagine with 3 to 4 sessions that we easily reach restore
>>     times of about 15 hours.
>>
>>     Is this adequate to todays needs? Am I doing something wrong?
>>
>>     I know that it is no problem to restore very big database files
>>when
>>     tape drives are streaming, but what to do with the vast amounts of
>>     small files?
>>
>>     Does it make sense to decrease the number of backup versions to
>>keep,
>>     to get less space (due to inactive files) between two active files
>>to
>>     be restored?
>>
>>     Is it an idea to do an export node filedata=backupactive and
>>reimport
>>     as a new node and then start the restore from this new node?
>>
>>     What are you doing to keep performance up to date?
>>
>>     Matthias
>>
>