Kyle,

I like your idea and think if we refine it further it can become a fairly
good recipe (IMHO).
Step 1a. Have separate storage hierarchy for nodes requesting "PIT
backups" over same device classes. Let's call it DISK-PIT, FILE-PIT and
TAPE-PIT.
Steps 2&3 - unchanged.
Set Reusedelay=<longest retension period for PIT backups>. How much to
raise the reclamation threshold I be sure but think disabled (sorry I have
no long term experience as some other people on this list). If retension
periods are very disimilar we can have COPY1-PIT and COPY7-PIT for 1 and 7
years respectively.
Countinue as you described backing up *-PIT pools to COPY-PIT and making
DB snapshots.
On restores DBS can be restored to another server or second instance. You
do not need to restore *any* primary pool. Just mark all volumes
unavailable and restore would take place right from copy pool volumes.
The main disadvantage is huge waste of tapes but if the management demands
this to be accomplished the old traditional way ... The implementation
with any Full/Incremental product would produce same ammount of tape
usage/waste.

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: Point in Time Backups

This may be totally unsuitable for your environment, but actually, I had
been thinking about the properties of 'REUSEDELAY' and database backups
recently, and I think maybe it could be used to create something to this
effect for your customers at large;  I wouldn't know how to drill it down
to individual nodes, however.  Also, because of the way it works, it would
only really be useful for archival purposes, not for data you anticipate
needing to restore on a regular basis.  The actual restore would be a
severe pain :)

The idea goes something like this:
  1.  Assume you have the following pools -- DISKDATA, TAPEDATA, and
      COPYTAPE.
  2.  DISKDATA is obviously a disk pool, TAPEDATA is your primary tape
      media, and COPYTAPE is your backup storage pool for both DISKDATA
      and COPYTAPE.
  3.  Define a third storage pool, COPYPIT -- copy-point-in-time.

Do your normal client backup/migration/stgpool backup with DISKDATA,
TAPEDATA, COPYTAPE.  Whenever you want to do a point in time backup, do
_another_ backup of DISKDATA and TAPEDATA onto COPYPIT.  Take a database
snapshot.  Send COPYPIT and the DBSNAPSHOT offsite, and leave them offsite
forever (or out of library).  Take note of which volumes and database
snapshots correspond to which dates -- you might want to store these
offsite too.

In the future, if you need to restore from one of the point in time
backups, recall the tapes and the snapshot you took from the appropriate
day, and you should be able to restore to that point in time.

Drawbacks:
  1.  You have to be very, VERY careful about reclamation.  The TSM server
      is going to be expiring these files, and you'll likely have no real
      way of knowing which volumes to reclaim.  More than likely, your
      best, safest bet is to write off the tapes, and never reclaim them.
  2.  Restoration is a HUGE, MASSIVE pain.  You'll need to recall the
      tapes, restore the database, then restore the storage pool, etc,
      before you can even think about restoring the data.  This is
      certainly no help if you need to be able to restore from these PIT
      backups on a moments notice.  You'll also need lots of scratch tapes
      to do the restoration, and you'll have to take precautions to make
      sure that you don't accidentally restore over current data --
      probably by removing all 'current' tapes from the library, or using
      a totally different machine and compatible library.
  3.  I don't think you can easily do this only for a subset of nodes.

Advantages:
  1.  Easier to maintain than doing more than a certain amount of
      backupsets.

Comments?  I may need to do something like this in the future, and if
anyone has any reasons why this is not really workable, it'd save me a
headache having to find it out the hard way.  And yes, I know this is a
horrible kludge. :)

Thanks,

Kyle Sparger