Re: [ADSM-L] NBU user considering switch to TSM

See below.

See Ya'
Howard


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Paul Zarnowski
> Sent: Wednesday, October 01, 2008 1:55 PM
> To: ADSM-L AT VM.MARIST DOT 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:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf
> > > Of steve sorenson
> > > Sent: Tuesday, September 30, 2008 11:44 PM
> > > To: ADSM-L AT VM.MARIST DOT 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.