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