Another huge contributor to this phenomenon is failure to use DIRMC on disk (and FILE on disk for sequential migration/reclamation) storage pools.
A lot of servers and a lot of objects (more common with Windows these days) need all the help they can get; keeping directories on disk (using DIRMC trick) makes a huge difference in the number of tape seeks required... see other posts about restore times. I had a customer with non-collocated DLT backups for 30 servers, spread over 45 tapes; it only took about 30 hours to restore 316 GB, 1.6 million objects -- that's over 10 GB/Hr, faster than most benchmarks! Don France Technical Architect - Tivoli Certified Consultant Professional Association of Contract Employees (P.A.C.E.) San Jose, CA (408) 257-3037 [EMAIL PROTECTED] ----- Original Message ----- From: "Richard Cox" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 23, 2002 6:40 AM Subject: Re: Slow restores > Wieslaw, > > A typical reason for long search times is a high reclaimation value and > no colocation. If you have a lot of servers, this can really fragment > the data across the volumes > > Regards, > > Richard > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of > Wieslaw Markowiak/Kra/ComputerLand/PL > Sent: 23 April 2002 13:44 > To: [EMAIL PROTECTED] > Subject: Slow restores > > Hi, > After issuing node restore command my library spends a lot of time > seeking > for something on tape. The actual restore takes comparatively little > time. > Can anybody explain me what is happening? And is it possible to shorten > the > "seeking" period? > Thank you for your help in advance - Wieslaw
