Hi, Hi,
First deteremine what is the slowest chain in your restore path. Following assumes tapes are the weak point. First check the actual impact of tape speed on your restore time: Try once a dsmc select backup for small portion of file server, maybe 1 GB consisting from your typicall small files. Be sure you have enough place in your disk storage pool to keep this backup and allow no reclamation. Test restore time from this backup. Compare this to restore times you get when restoring from incrementals => from tapes. Probably there will be significant penalty resulting from keeping small files on tape drives. If so, and only then, try to use even better tapes if you can afford, (1) try to use more tape drives in parallel even for single restore, (2) try to reduce tape usage at all, (3) try smarter, not harder (4) 1)For small files on tapes search, rewind, mount/unmount, start/stop times and not data transfer rate are important. Give a look to either 3590 or AIT, they might be better in this point. 3575 definitely is better here, but the capacity is not acceptable any more. 2) a)if your file server has more file systems, use collocation=filesystem (check for correct syntax, please) and be sure to use enough tapes to allow backups really be spread over more media. This will allow parallel restores from more tapes. Yes, you would have to start more restores manually, one session for each file system. b)With 10(!) tape drives you even can think about collocation=off. I know, it is heretic, but this would spread your files over many tapes, thus allowing more parallel restores to use more tape drives in parallel. You would have to start more restores at once to profit from this, each restore for different directory or file system. On the other side there would be penalty from even more tape mount and seek operations. The usability would strongly depend on your actual data and hardware, surely a thing to be thoroughly tested, not a generall recommendation. c) define a couple TSM nodes on your file server and let them backup alternative parts of it. Not nice from managament point of view, but this would easilly allow for controlled collocated environment thus parallel usage uf tapes during restore. 3)keep your disk storage pools (very) large and try to keep them as many data from your file server as possible. There are many ways to optimise this, you may want , for example, to create a management class for files beeing notoriosly small and a separate disk storage poll for them. This is common practise for smallest files possible: fordirectories, isn�t it? 4)as others mailed, try disk extender. Or consider file server cluster which might eliminate the need for disaster restore. 5) Other thoughts: test your file server how auickly they are able to create small files. How quickly runs a xcopy with small files? Do you use GUI TSM or command line? GUI is notoriously slower with small files comparing to command line. 6)share your experiences with us once you have worked it out for you. regards Juraj Salak A&H Familienholding -----Original Message----- From: Karel Bos [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 15, 2002 8:45 AM To: [EMAIL PROTECTED] Subject: Large server restore time? Today I received a request to back-up a win2000 fileserver. They will start with 200 gig. Based on servers we currently host I predict this server to store 8755028 files and 756095 mb on the TSM server. The TSM server is version 4.1.3 and runs on a 1gig 2 cpu AIX machine. The library is a 3584L32 from IBM with 10 scsi lto drives. The TSM client will be version 4.2.x. The network is 100mbps ethernet (which will not be THE problem). Smaller fileservers have a poor restore time (>26 hours), so this will become a disaster. Is there anyone out there who has something like this AND can keep the restore time less than 24 hours (tested!). If so, tell me how, please. Thanx, Karel Bos NUON ICT Holland
