Obviously, being in Chicago this week has frozen my brain (or maybe I'm downwind from UIC...). Yes, you're correct - it is Domain and Storagepool combined.
Nick Cassimatis ----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 01/22/2008 09:42 PM ----- "ADSM: Dist Stor Manager" <[email protected]> wrote on 01/22/2008 08:24:29 PM: > Nick > > I may well have a flawed understanding here but.... > > Set up an active-data pool > clone the domain containing the servers requiring recovery > set the ACTIVEDATAPOOL parameter on the cloned domain > move the servers requiring recovery to the new domain, > Run COPY ACTIVEDATA on the primary tape pool > > Since only the nodes we want are in the domain with the ACTIVEDATAPOOL > parameter specified, will not only data from those nodes be copied? > > Regards > > Steve > > Steven Harris > TSM Admin, SYdney Australia > > "ADSM: Dist Stor Manager" <[email protected]> wrote on 23/01/2008 > 11:38:17 AM: > > > For this scenario, the problem with Active Storagepools is it's a > > pool-to-pool relationship. So ALL active data in a storagepool would be > > copied to the Active Pool. Not knowing what percentage of the nodes on > the > > TSM Server will be restored, but assuming they're all in one storage > pool, > > you'd probably want to "move nodedata" them to another pool, then do the > > "copy activedata." Two steps, and needs more resources. Just doing > "move > > nodedata" within the same pool will semi-collocate the data (See Note > > below). Obviously, a DASD pool, for this circumstance, would be best, if > > it's available, but even cycling the data within the existing pool will > > have benefits. > > > > Note: Semi-collocated, as each process will make all of the named nodes > > data contiguous, even if it ends up on the same media with another nodes > > data. Turning on collocation before starting the jobs, and marking all > > filling volumes read-only, will give you separate volumes for each node, > > but requires a decent scratch pool to try. > > > > Nick Cassimatis > > > > ----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 01/22/2008 07:25 PM > > ----- > > > > "ADSM: Dist Stor Manager" <[email protected]> wrote on 01/22/2008 > > 01:58:11 PM: > > > > > Are files that are no longer active automatically expired from the > > > activedata pool when you perform the latest COPY ACTIVEDATA? This > would > > > mean that, at some point, you would need to do reclamation on this > pool, > > > right? > > > > > > It would seem to me that this would be a much better answer to TOP's > > > question. Instead of doing a MOVE NODE (which requires moving ALL of > > > the node's files), or doing an EXPORT NODE (which requires a separate > > > server), he can just create an ACTIVEDATA pool, then perform a COPY > > > ACTIVEDATA into it while he's preparing for the restore. Putting said > > > pool on disk would be even better, of course. > > > > > > I was just discussing this with another one of our TSM experts, and > he's > > > not as bullish on it as I am. (It was an off-list convo, so I'll let > > > him go nameless unless he wants to speak up.) He doesn't like that you > > > can't use a DISK type device class (disk has to be listed as FILE > type). > > > > > > He also has issues with the resources needed to create this "3rd copy" > > > of the data. He said, "Most customers have trouble getting backups > > > complete and creating their offsite copies in a 24 hour period and > would > > > not be able to complete a third copy of the data." Add to that the > > > possibility of doing reclamation on this pool and you've got even more > > > work to do. > > > > > > He's more of a fan of group collocation and the multisession restore > > > feature. I think this has more value if you're restoring fewer clients > > > than you have tape drives. Because if you collocate all your active > > > files, then you'll only be using one tape drive per client. If you've > > > got 40 clients to restore and 20 tape drives, I don't see this slowing > > > you down. But if you've got one client to restore, and 20 tape drives, > > > then the multisession restore would probably be faster than a > collocated > > > restore. > > > > > > I still think it's a strong feature whose value should be investigated > > > and discussed -- even if you only use it for the purpose we're > > > discussing here. If you know you're in a DR scenario and you're going > > > to be restoring multiple systems, why wouldn't you do create an > > > ACTIVEDATA pool and do a COPY ACTIVEDATA instead of a MOVE NODE? > > > > > > OK, here's another question. Is it assumed that the ACTIVEDATA pool > > > have node-level collocation on? Can you use group collocation instead? > > > Then maybe I and my friend could both get what we want? > > > > > > Just throwing thoughts out there. > > > > > > --- > > > W. Curtis Preston > > > Backup Blog @ www.backupcentral.com > > > VP Data Protection, GlassHouse Technologies > > > > > > -----Original Message----- > > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of > > > Maria Ilieva > > > Sent: Tuesday, January 22, 2008 10:22 AM > > > To: [email protected] > > > Subject: Re: [ADSM-L] Fw: DISASTER: How to do a LOT of restores? > > > > > > The procedure of creating active data pools (assuming you have TSM > > > version 5.4 or more) is the following: > > > 1. Create FILE type DISK pool or sequential TAPE pool specifying > > > pooltype=ACTIVEDATA > > > 2.Update node's domain(s) specifying ACTIVEDESTINATION=<created active > > > data pool> > > > 3. Issue COPY ACTIVEDATA <node_name> > > > This process incrementaly copies node's active data, so it can be > > > restarted if needed. HSM migrated and archived data is not copied in > > > the active data pool! > > > > > > Maria Ilieva > > > > > > > --- > > > > W. Curtis Preston > > > > Backup Blog @ www.backupcentral.com > > > > VP Data Protection, GlassHouse Technologies > > > > > > > > -----Original Message----- > > > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > > > Of > > > > James R Owen > > > > Sent: Tuesday, January 22, 2008 9:32 AM > > > > To: [email protected] > > > > Subject: Re: [ADSM-L] Fw: DISASTER: How to do a LOT of restores? > > > > > > > > > > > > Roger, > > > > You certainly want to get a "best guess" list of likely priority#1 > > > > restores. > > > > If your tapes really are mostly uncollocated, you will probably > > > > experience lots of > > > > tape volume contention when you attempt to use MAXPRocess > 1 or to > > > run > > > > multiple > > > > simultaneous restore, move nodedata, or export node operations. > > > > > > > > Use Query NODEData to see how many tapes might have to be read for > > > each > > > > node to be > > > > restored. > > > > > > > > To minimize tape mounts, if you can wait for this operation to > > > complete, > > > > I believe > > > > you should try to move or export all of the nodes' data in a single > > > > operation. > > > > > > > > Here are possible disadvantages with using MOVe NODEData: > > > > - does not enable you to select to move only the Active backups for > > > > these nodes > > > > [so you might have to move lots of extra inactive backups] > > > > - you probably can not effectively use MAXPROC=N (>1 nor run > > > multiple > > > > simultaneous > > > > MOVe NODEData commands because of contention for your > > > > uncollocated volumes. > > > > > > > > If you have or can set up another TSM server, you could do a > > > > Server-Server EXPort: > > > > EXPort Node node1,node2,... FILEData=BACKUPActive > TOServer=... > > > > [Preview=Yes] > > > > moving only the nodes' active backups to a diskpool on the other TSM > > > > server. Using > > > > this technique, you can move only the minimal necessary data. I > don't > > > > see any way > > > > to multithread or run multiple simultaneous commands to read more > than > > > > one tape at > > > > a time, but given your drive constraints and uncollocated volumes, > you > > > > will probably > > > > discover that you can not effectively restore, move, or export from > > > more > > > > than one tape > > > > at a time, no matter which technique you try. Your Query NODEData > > > > output should show > > > > you which nodes, if any, do *not* have backups on the same tapes. > > > > > > > > Try running a preview EXPort Node command for single or multiple > nodes > > > > to get some > > > > idea of what tapes will be mounted and how much data you will need to > > > > export. > > > > > > > > Call me if you want to talk about any of this. > > > > -- > > > > [EMAIL PROTECTED] (w#203.432.6693, Verizon c#203.494.9201) > > > > > > > > Roger Deschner wrote: > > > > > MOVE NODEDATA looks like it is going to be the key. I will simply > > > move > > > > > the affected nodes into a disk storage pool, or into our existing > > > > > collocated tape storage pool. I presume it should be possible to > > > > restart > > > > > MOVE NODEDATA, in case it has to be interrupted or if the server > > > > > crashes, because what it does is not very different from migration > > > or > > > > > relcamation. This should be a big advantage over GENERATE > BACKUPSET, > > > > > which is not even as restartable as a common client restore. A > > > > possible > > > > > strategy is to do the long, laborious, but restartable, MOVE > > > NODEDATA > > > > > first, and then do a very quick, painless, regular client restore > or > > > > > GENERATE BACKUPSET. > > > > > > > > > > Thanks to all! Until now, I was not fully aware of MOVE NODEDATA. > > > > > > > > > > B.T.W. It is an automatic tape library, Quantum P7000. We graduated > > > > from > > > > > manual tape mounting back in 1999. > > > > > > > > > > Roger Deschner University of Illinois at Chicago > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > On Tue, 22 Jan 2008, Nicholas Cassimatis wrote: > > > > > > > > > >> Roger, > > > > >> > > > > >> If you know which nodes are to be restored, or at least have some > > > > that are > > > > >> good suspects, you might want to run some "move nodedata" commands > > > to > > > > try > > > > >> to get their data more contiguous. If you can get some of that > > > DASD > > > > that's > > > > >> coming "real soon," even just to borrow it, that would help out > > > > >> tremendously. > > > > >> > > > > >> You say "tape" but never "library" - are you on manual drives? > > > > (Please say > > > > >> No, please say No...) Try setting the mount retention high on > > > them, > > > > and > > > > >> kick off a few restores at once. You may get lucky and already > > > have > > > > the > > > > >> needed tape mounted, saving you a few mounts. If that's not > > > working > > > > (it's > > > > >> impossible to predict which way it will go), drop the mount > > > retention > > > > to 0 > > > > >> so the tape ejects immediately, so the drive is ready for a new > > > tape > > > > >> sooner. And if you are, try to recruit the people who haven't > > > > approved > > > > >> spending for the upgrades to be the "picker arm" for you - I did > > > that > > > > to an > > > > >> account manager on a DR Test once, and we got the library approved > > > > the next > > > > >> day. > > > > >> > > > > >> The thoughts of your fellow TSMers are with you. > > > > >> > > > > >> Nick Cassimatis > > > > >> > > > > >> ----- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 01/22/2008 > > > > 08:08 AM > > > > >> ----- > > > > >> > > > > >> "ADSM: Dist Stor Manager" <[email protected]> wrote on > > > 01/22/2008 > > > > >> 03:40:07 AM: > > > > >> > > > > >>> We like to talk about disaster preparedness, and one just > happened > > > > here > > > > >>> at UIC. > > > > >>> > > > > >>> On Saturday morning, a fire damaged portions of the UIC College > of > > > > >>> Pharmacy Building. It affected several laboratories and offices. > > > The > > > > >>> Chicago Fire Department, wearing hazmat moon suits due to the > > > highly > > > > >>> dangerous contents of the laboratories, put it out efficiently in > > > > about > > > > >>> 15 minutes. The temperature was around 0F (-18C), which > compounded > > > > the > > > > >>> problems - anything that took on water became a block of ice. > > > > >>> Fortunately nobody was hurt; only a few people were in the > > > building > > > > on a > > > > >>> Saturday morning, and they all got out safely. > > > > >>> > > > > >>> Now, both the good news and the bad news is that many of the > > > damaged > > > > >>> computers were backed up to our large TSM system. The good news > is > > > > that > > > > >>> their data can be restored. > > > > >>> > > > > >>> The bad news is that their data can be restored. And so now it > > > must > > > > be. > > > > >>> > > > > >>> Our TSM system is currently an old-school tape-based setup from > > > the > > > > ADSM > > > > >>> days. (Upgrades involving a lot more disk coming real soon!) Most > > > of > > > > the > > > > >>> nodes affected are not collocated, so I have to plan to do a > > > number > > > > of > > > > >>> full restores of nodes whose data is scattered across numerous > > > tape > > > > >>> volumes each. There are only 8 tape drives, and they are kept > busy > > > > since > > > > >>> this system is in a heavily-loaded, about-to-be-upgraded state. > > > > (Timing > > > > >>> couldn't be worse; Murphy's Law.) > > > > >>> > > > > >>> TSM was recently upgraded to version 5.5.0.0. It runs on AIX 5.3 > > > > with a > > > > >>> SCSI library. Since it is a v5.5 server, there may be new > > > facilities > > > > >>> available that I'm not aware of yet. > > > > >>> > > > > >>> I have the luxury of a little bit of time in advance. The hazmat > > > > guys > > > > >>> aren't letting anyone in to asess damage yet, so we don't know > > > which > > > > >>> client node computers are damaged or not. We should know in a day > > > or > > > > >>> two, so in the meantime I'm running as much reclamation as > > > possible. > > > > >>> > > > > >>> Given that this is our situation, how can I best optimize these > > > > >>> restores? I'm looking for ideas to get the most restoration done > > > for > > > > >>> this disaster, while still continuing normal client-backup, > > > > migration, > > > > >>> expiration, reclamation cycles, because somebody else unrelated > to > > > > this > > > > >>> situation could also need to restore... > > > > >>> > > > > >>> Roger Deschner University of Illinois at Chicago > > > > [EMAIL PROTECTED] > > > >
