ADSM-L

Re: Question on defeating TSM strengths: due to budget constraints << solved

2003-05-27 23:39:51
Subject: Re: Question on defeating TSM strengths: due to budget constraints << solved
From: Robert Clark <res03db2 AT GTE DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 27 May 2003 20:27:53 -0700
I've been wondering what the benefits/tradeoffs of VTL would be in
this scenario. (Aside from the cost margin of VTL over cheap IDE/SATA
disk.)

Any feedback / ideas?

[RC]
----- Original Message -----
From: "DFrance" <DFrance-TSM AT ATT DOT NET>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Tuesday, May 27, 2003 3:27 PM
Subject: Re: Question on defeating TSM strengths: due to budget constraints
<< solved


Yep... it worked in our case since the environment was (a) stable (all
policy decisions had been settled, so there was not a big risk of changing
one po-set and forgetting to change the other, in lock-step), (b) enabled
the most current full backups to stay in the single silo (the main exposure
was getting the full backups done over the course of a weekend, being
available for help if problem arose during that weekend, once a month).

TWO of the sites I referenced were going to stay with single-drive solution;
the net result was, to keep it "lights out", I convinced them to keep
primary pool data on disk, sending two copy-pools to tape -- one for onsite,
one for offsite storage.  In this instance, the customer was able to live
with the limits of the disk array we installed for primary storage pool
data... whew!

Now, with serial ATA drives on the scene, there's much discussion of various
ways to exploit larger pools of cheap disk, maybe as secondary in the
storage hierarchy (maybe as FILE volumes, with the SANergy enhancements in
v5.1), so as to enable much larger, online/nearline primary pool storage.

I agree, the "correct" answer lies with the specific customer situation; in
general, we gotta "sell" the customer on the need for HW investment (ie, at
least TWO, prefer odd number of drives for data center solutions).  When
that is not "in the cards" (for a short or long while), then ya gotta get
creative to keep the customer whole, and "keep the faith", eh!?!

Regards,
Don


Don France
Technical Architect -- Tivoli Certified Consultant
Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390
San Jose, Ca
(408) 257-3037
mailto:don_france AT ayett DOT net (change aye to a for replies)

Professional Association of Contract Employees
(P.A.C.E. -- www.pacepros.com)



-----Original Message-----
From: Steven Pemberton [mailto:stevep AT ibk.com DOT au]
Sent: Thursday, May 22, 2003 7:43 PM
To: ADSM: Dist Stor Manager; DFrance
Subject: Re: Question on defeating TSM strengths: due to budget
constraints << solved


On Friday 23 May 2003 11:08, DFrance wrote:
> With all due respect, I supported an international account exactly this
> way; as an interim solution (while they ordered up a second tape drive) at
> 3 of their 12 sites, using policyset swap to re-drive the full-backups
(ie,
> change copygroup to "absolute", from "modified") was just what we needed,
> so they could run (almost) lights-out for a month at a time, using
> incrementals after each monthly full.

As with most of TSM, there is no one "right way". Just lots of flexibility.
:)

Yes, swapping policy sets will work, but you run the risk of someone
updating
one of the "twin" policy sets and not the other. Then when the policy sets
are swapped, your data may be rebound (if a MC doesn't exist) or retained
(or
not) for an unexpected period.

If you were going to do this I'd prefer to copy the "active" set to a
temporary name, change the copygroup to/from absolute/modified, and then
copy
it back to the "active" set.

But I'm still hesitant about swapping policy sets because it's not
"obvious".

> If you've got the bandwidth to run the full-backup over a weekend, this
> fits the bill;  if not (due to multiple nodes), then you'll need to work
> harder and support multiple node-names per client machine... one for daily
> INCR, one for weekly INCR --- Hmmm, maybe that's a better scenario for
your
> situation, eh?  (My customer's scenario worked best because it allowed us
> to do en-mass swap of scratch tapes for old backup tapes... which
> facilitated remote restore from the help desk, transparently to the
> help-desk folks!)

Also, if you use two node names for the "daily incr" and "weekly full"
backups, they can use two separate management classes, with different
retention periods.

So, when your management decides they want to keep the full backups for a
month/year, and the incremental backups for only a week/month, you can.

Alternatively, have you considered keeping *all* the primary backups on disk
(mmmm, lots of disk :) and only sending the copy pool versions to tape for
offsite storage? Or maybe only sending backup set versions to tape (which
can
be retained and restored separately from the TSM server?

But, of course, the "correct" answer is to but another tape drive.

Regards,
Steven P.

--
Steven Pemberton                                      Mobile: +61 4 1833
5136
Innovative Business Knowledge                   Office: +61 3 9820 5811
Senior Enterprise Management Consultant    Fax: +61 3 9820 9907