On the wishlist item: I have heard talk about implementing an automatic multi-stream restore similar to what we have now with backup and resourceutilization. This will be slick but then only really slick if one uses collocate=filespace. I believe it will still provide better restore times since it will know what tape volumes client data is on and will mount multiple volumes. If one thinks about this for a few minutes, one realizes the whole thing is damn complicated. Also, it would appear that collocation would not be a good thing if you use this technique: you want data on multiple tapes.
TSM restore is fairly smart. Before data is sent, TSM has optimized data coming off each volume. It does not back hitch to get data: it processes serially through the tape. I don't know the algorithm for determining which tape it uses first. I would guess perhaps the tape that has the most data (based on number of files, not size) and do that one first but that's just a guess. As for the new functionality I would guess at an implementation that orders the restore by number of files on volumes and choose the n largest volumes, where n is resourceutilization or the number of filespaces, mount those tapes and start that number of restores. Then, since there might be data for a filespace on one of the other tapes that mounted, get the data for the other filespace off that tape too. So work the n tapes until all the data for all n filespaces are off the tapes and then mount another batch. If I were a programmer this would be a fun exercise. No, I'm not looking for a job. I learned it's a lot easier to talk about sexy code than it is to write it! Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs, CO 80949 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Robin Sharpe Sent: Wednesday, December 19, 2001 8:31 AM To: [EMAIL PROTECTED] Subject: Re: Incremental forever -- any problems? (Scary thoughts) Backupsets can be useful in some situations, but saving time is not one of their benefits. In the experiments I've done, generating a backupset took as long as or longer than restoring the client. The generate backupset process will mount the same tapes as the restore. If you generate backupsets regularly, and already have one on hand, then yes it would save time. But regularly generating backupsets would take a lot of time and duplicate the normal backups. Another issue with restores, is that you can only do one filespace per command. This may not be a big problem for NT clients, but unix clients typically have ten or more filesystems. And unless the client is collocated-by-filespace, chances are that many tapes will have multiple filespaces on them and therefore will have to be mounted several times. Also, if you run those restore sessions in parallel, some of them will probably compete for the same tapes at some time. I have observed this every time we do disaster recovery tests. This leads me on to something I have been thinking about over the last few weeks... in the spirit of the season, here is the top item on my TSM wishlist: Since TSM has in its database the complete information about what each client has backed up, it is conceivable that TSM could construct an "optimized restore plan" for an entire client node. There should be an option on the restore command to indicate that all filespaces of a node be restored (or maybe a "restore node" command), and TSM should be able to multithread that operation to insure that each tape is accessed only once and no two sessions require the same tape. The restore command should also have a "preview=yes" option so we can pre-fetch any needed tapes from the rack or the vault. And it should also be able to give an estimate of how long the restore should take, even it has to be qualified by "assuming 10 GB/hour throughput", or something like that. Now, some of you may be thinking this is a good opportunity for a third party product or a server script.... I thought so too.... but as far as I can tell, that valuable information, which TSM must have in its database, cannot be retrieved by any known query or select. What you need to know is "what tape contains the active version of file xxx?" TSM can certainly determine this... it must, to be able to restore anything, but I challenge anyone to find it without actually doing a restore! Robin Sharpe Berlex Labs Karel Bos <Karel.Bos@NU ON.COM> To: [EMAIL PROTECTED] cc: (bcc: Robin Sharpe/WA/USR/SHG) 12/19/01 Subject: 05:41 AM Re: Incremental forever -- any problems? (Scary thoughts) Please respond to "ADSM: Dist Stor Manager" Are back-up sets a option?
