ADSM-L

Re: NT restore performance for small files

2015-10-04 17:47:36
Subject: Re: NT restore performance for small files
From: Diana Cline
To: ADSM-L AT VM.MARIST DOT EDU
Yea, but what if you are using co-location. All these different threads
can't
use one tape!  Right?






ADSM-L AT VM.MARIST DOT EDU on 02/02/99 03:10:40 PM
Please respond to ADSM-L AT VM.MARIST DOT EDU @ RPDINET
To: ADSM-L AT VM.MARIST DOT EDU @ RPDINET
cc:
Subject: 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>
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 fevr. 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
>