ADSM-L

Re: [ADSM-L] Backupset/Export pain

2010-04-07 10:03:59
Subject: Re: [ADSM-L] Backupset/Export pain
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 7 Apr 2010 10:03:09 -0400
>> On Wed, 7 Apr 2010 00:16:54 -0400, Steve Harris <steve AT STEVENHARRIS DOT 
>> INFO> said:


> I have a customer that thinks he wants a monthly backup kept
> forever: cites legislative requirements and will not be disuaded.
> Current implementation is to use a series of backupsets.


We have several units which have spent some time thinking they must do
something like this.  You might be able to improve this by setting up
a distinct policy domain (or heck, even server instance).  So far,
they've all eventually repented the decision, but what we did was:


For customer EXAMPLE, we define two policy domains:

EXAMPLE, with vere=7,verdel=5,retextra=60,retonly=90

EXAMPLE-LONGTERM, with 
vere=nolimit,verdel=nolimit,retextra=nolimit,retonly=nolimit

Are you shuddering?  Good.


then they define two TSM nodes:

VICTIM, in domain EXAMPLE.

VICTIM-LONGTERM in EXAMPLE-LONGTERM.


They schedule VICTIM to back up nightly, and VICTIM-LONGTERM monthly.

I give them dire warnings about the possibilities for stupid storage
growth with VICTIM-LONGTERM.  Pleasantly, we're set up for chargeback;
if they really go overboard the customer feels it before I do.


You can do the dual schedule in a variety of ways.  If you're a pedant
you could run two CADs.  You could also assign a CMD schedule in
domain EXAMPLE to run 'dsmc incr -optfile=/yadda/longterm.opt' and
schedule that monthly.  Flip a coin as to which of these is less
confusing.


If you go this way, you will:

+ Still be using incremental heuristics to calculate the monthly backup.

+ Take up less duplicate space than the backupsets (or archive,
  Richard) solution.

+ Still be able to query the node contents without odd backupset introspection

+ Be able to manipulate the long-term data with the same media
  independance as your short-term data.  Someone who thinks they need
  'indefinite' storage should really really care about that.  The
  backupsets are not, (to my knowledge) transferrable unless you're in
  virtual volume land.

  I can just see someone presenting today with a ZIP drive.  "This is
  my permanent record!".  You have a ZIP drive on your TSM server,
  don't you?


Pleasantly for your case, it's also plausible that you could set it up
in time for "next month", and by "the month after that", you'll
already be saving tapes.



- Allen S. Rout
- Pedant.

<Prev in Thread] Current Thread [Next in Thread>