ADSM-L

Re: TSM 4.2/AIX setup questions

2002-06-13 10:24:30
Subject: Re: TSM 4.2/AIX setup questions
From: Dan Foster <dsf AT GBLX DOT NET>
Date: Thu, 13 Jun 2002 14:19:46 +0000
Hot Diggety! Miles Purdy was rumored to have written:
>
> 1) Is there any particular reason to set a max file size for a disk stgpool?
>    (Assuming a setup where disk stgpool will migrate to tape stgpool)
> Generally yes, if you will be backing up a file larger than the stgpool. If 
> you will be backing up a file larger than the stgpool it may be more 
> efficient to send it right to tape, this is the general rule.

Ahhh, efficiency...makes sense. Also explains why there might be a situation
where client->disk [but too big or unavailable]->direct to tape instead,
so the copy stgpool might not have every single file in the disk stgpool,
hence this being the reason for backing up tape stgpool to the copy stgpool
in order to fill in any gaps (in addition to backing up disk stgpool, also).

> 2) Should the TSM server have its own stgpool for backing up itself?
> A. I don't think so. Do you mean the filesytems on the TSM/AIX server? No, it 
> doesn't _need_ its own.

Ok. Must've been an original design decision at this site for the existing
setup. Can't say I know the rationale (and can't ask since the folks in
question are long since gone now), but I'll keep that in mind. We set up
the existing scheme about 5-6 years ago, and in this high-turnover industry
(ISP), people moved on every few years when the grass was still green. ;)

> 3) I've heard mixed things about 358x firmware version 22UD... I think we
>    have 18N2 (but not near it right now to confirm), although what I've
>    heard about 22UD is generally (but not 100% in agreement) positive. Stable?
> A. I'm using 22U0, things seem good.

Hmmm. Duly noted, thanks.

> 4) Whom is supposed/allowed to upgrade firmware? IBM CE only?
> It depends how comfortable you are performing the work.

I'm good with any sort of firmware updates from SP nodes to disks to
disk arrays to tape drives, etc. But for this one time, I think I'll
let the CE do it the next time he's on-site for the 3584. :) No reason
to throw caution to the wind.

> 5) The only docs for firmware upgrade references a NT/2000 box and the
>    NTUtil application, whereas I'm in an all-UNIX (AIX and Solaris, although
>    I do have a laptop with Linux and Windows XP if need be) environment, so
>    wonder how to upgrade the firmware without Windows if it's even possible.
> A. You can upgrade the firmware from a drive (drive to drive) or from a tape 
> cartridge. Check the docs for the main panel.

Ahhh, yes. See it now, thanks.

> 6) To *SM, all backups are incrementals (except for the first backup of a
>    new client), is my general understanding. Is there a way to force a full
>    backup of a particular client as an one-time operation? I'm guessing maybe
>    not, but thought I might try asking, anyway. :)
> A. This is called an 'archive'. There is plenty of docs on this.

Ahhh, sure is! Archive, being TSM's term for that... okay, can deal with that.
Back to reading up more on the archive section.

> 7) The biggest single question... I don't have a real good understanding of
>    the purpose of copy stgpools. I've read a lot of documentation -- hundreds
>    of pages of multiple docs, re-read, read old adsm-l mail, Google searches,
>    etc... but still just don't quite 'get it'. I can set up HACMP clusters,
>    debug really obscure things, but this eludes me. ;)
> A. Copy pools are for offsite. Copy pools are what is in your vault. A copy 
> pool is a complete copy, usually offsite.

Ahhhhhh, that makes much more sense, thanks. (And rest assured, we *do*
have an off-site storage vendor and bring tapes off-site. :) )

> > Almost, you do send the (primary) data to another (copy) pool, but all the 
> > time. I would do something like this, everyday:
>
> 1. backup your clients to disk (disk storage pool)
> 2. make a copy to a copy storage pool (OFFSITE)
> 3. backup from the disk storage pool to your primary storage pool
> 4. backup your database, devconfig, volhist
> 5. send the OFFSITE tapes and the database backup offsite
> 6. during the day run reclamation on each storage pool

Makes sense.

Hmm, I saw a suggestion in the TSM 4.2 admin guide to disable reclamation
for the copy stgpool (specifically) to avoid a situation where tapes gets
sent off site and then it wants them for the reclamation.

But of course, for the other stgpools, reclamation does make sense.

Much appreciated the pointers...big help, thanks!

-Dan Foster
IP Systems Engineering (IPSE)
IP Systems Engineering (IPSE)
Global Crossing Telecommunications