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
|