ARGGHH I found it. Its there even in 5.5
If you run Update stg primarypool And use the following option: COPYSTGpools=copypool,copypool2,etc. You'll get the Simultaneous writes. Of course you'll want to set: COPYContinue=yes Or else your whole backup will stop on any error. See Ya' Howard > -----Original Message----- > From: Howard Coles > Sent: Wednesday, October 01, 2008 2:46 PM > To: ADSM-L@VM.MARIST.EDU > Subject: RE: [ADSM-L] NBU user considering switch to TSM > > See below. > > See Ya' > Howard > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > > Of Paul Zarnowski > > Sent: Wednesday, October 01, 2008 1:55 PM > > To: ADSM-L@VM.MARIST.EDU > > Subject: Re: [ADSM-L] NBU user considering switch to TSM > > > > See my responses below.. > > > > At 02:04 PM 10/1/2008, Howard Coles wrote: > > >See in line answers below > > > > > >See Ya' > > >Howard > > > > > > > > > > -----Original Message----- > > > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On > > Behalf > > > > Of steve sorenson > > > > Sent: Tuesday, September 30, 2008 11:44 PM > > > > To: ADSM-L@VM.MARIST.EDU > > > > Subject: Re: [ADSM-L] NBU user considering switch to TSM > > > > > > > > Thanks so much for all the responses. I'd like to reply to just > a > > few > > > > responses for clarification. > > > > > >You're welcome. > > > > > > > Regarding simultaneous copies, Howard Coles said: > > > > I'm not talking about migration and backups happening at the same > > time, > > > > or even multiple migrations happening at the same time. > > > > > > > > First, let me verify what I was told TSM _could_ do. I was told > > that > > > during > > > > the initial backup (if you went straight to tape, such as with a > > large > > > > dataset), TSM could write to two tape drives simultaneously, > making > > two > > > > copies in the time it takes to make one. Is that part true? > > > > > >Yes. > > > > No, I do not think this is possible. Howard, the Copy Group > > DESTination > > can only specify one storage pool. Thus, it is not possible to send > > incoming data simultaneously to two different tape drives. This is > by > > design, and is not an oversight. The normal way of doing things is > to > > receive the data on disk first, and then you can simultaneously > migrate > > the > > data from disk to tape, and copy it to a copy storage pool. Perhaps > > Howard > > missed your premise that you want to go straight to tape. > > Sorry, but if you check your primary tape pools' properties you'll find > you are incorrect (unless the option doesn't even show up in a straight > up 5.5 environment). This option is set at the Storage Pool level, not > the Policy Domain. > > In a primary tape pool's definition you find the "Simultaneous Write" > tab. The description in that tab says: > Simultaneous Write > During client node or import operations, data can be written to the > primary storage pool and any combination of copy storage pools and > active-data pools. To protect inactive data, specify at least one copy > storage pool. > > However, it does appear that this feature isn't present in 5.5, or I'm > overlooking it badly. It was up until 5.4, which is why I see the > option I suppose (I also have a 5.3.5 server). And it does work for > copying into active data pools even in 5.5, or so it appears. Hmmm. . > . gotta dig into this. I never used it before, except in one occasion > where the client's users were very paranoid. :-D > > Note: I'm using TSM 5.5.1 & 5.3.5 & 5.2.8 (older hp-ux box about to be > replaced) > > > > > Howard Coles said: > > > > >You use the TSM GUI and/or command line to > > > > >do all the restores whether it be a backup set, or a backup from > > the > > > > >TSM server. > > > > > > > > But the contents of the backup set aren't in the TSM database, > > right? > > > > Isn't that the point of the backup set, to make an archive of a > > bunch of > > > > files that aren't tracked in the database, and that can be read > > outside of > > > > TSM? So if the contents of the backup set aren't in the > database, > > how > > > could > > > > you do restores the same way as you do with regular backups? > > > > > >Well, partially. The purpose of a backup set is to make a client's > > >backups portable. You are correct in that the contents of the > Backup > > >Set are not in the database (because they were intended to be > removed > > >from TSM and handed off to a client). However, you will need the > TSM > > >client, preferably the version that did the backup or newer, to > import > > >the backup set at the client, and hardware to read the tape/media > used > > >to create the backup set. > > > > This is not the only reason to use backup sets. You do not need > > hardware > > on the client to read the media, unless the point of the backupset is > > to > > have portable media. You can reference the backupset directly from > the > > server. Some folks use backupsets to take snapshots of their current > > backups, without having to re-send the data from the client again. > > > > Sorry, I was thinking of the original purpose. Yes, you can leave the > backup set in the library and mount it up for the client at the server > side.
