> > -----Original Message-----
> > From: James Thompson [mailto:mezron AT HOTMAIL DOT COM]
> > Sent: Wednesday, February 27, 2002 12:51 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: Idea for a TSM feature
> ...
> > This would not break anything with TSM.  It is really simple
> > to get in a state where your disk pool has only active versions and your
> tape next
> > storage pool has only inactive versions.  Just migrate data
> > to tape and run a selective backup of the filesystem.  Voila, active
> versions
> > on disk, only inactive on tape.
>
> (This is fun...)
> (WARNING: thinking out loud.)
>
> But no rules were applied to achieve this state, so it would not be a
> "configurable" option.
>
>
>
> So let's say the development folks added a storage pool (random access)
> parameter:
>
> MigrateActive   Yes/No  (default=Yes)
>
> Then let us set that new parameter to No.
> Overnight, we back up a bunch of stuff.  As long as it "fits" in the pool,
> it remains on disk.
> Next morning, we backup that stgpool to tape (for DR.)
> The next night, a bunch of stuff changes on the client, and we do another
> incremental.
> Now, however, the pool is full, and TSM has to decide what to do (just
like
> in the cached stgpool case.)
>
> I suppose we would want an initial attempt to locate the incoming file
> already in the pool, and migrate that (now inactive) file to tape, thus
> freeing up space for the (now active) file.
>
> If that fails, either because this is a "new" file, or it has grown, we go
> to the next step.
>
> What might that be?  We could let the current logic apply, thus
temporarily
> disabling the MigrateActive=No.
> If so, how long does that last? Just for the backup session?  Just for
this
> client (assuming more than one client lives in the pool)?  Until there is
> room for the next incoming file?  Do we need high/low percentage
parameters
> for this special case (to avoid the start/stop tape operations you
mention)
> ?
> Or do we just start writing incoming data to primary storage tape?
> Do we need some way to repopulate just the active data to that disk pool,
> after we have increased its size?
>
> Since we can't easily guarantee the pool will not fill, (I suppose we
could
> dynamically add volumes ala db triggering...), do we still want whatever
> will fit as a performance hedge (some improvement is better than none)?
If
> so, why wouldn't the current cache feature suffice?  And don't forget how
> long it will take for us to debug Tivoli's code...
>
> Other issues.
>
> Since this applies only to disk pools, SAN-type sessions are not covered
> (except SANEnegy.), since they go direct to tape.
>
>
> As data replication becomes more prevalent, the fast restore of an entire
> client's active dataset becomes less (but not entirely) dependent on
Backup
> methodologies.
>
> I agree with the Generate Backupset and Export Node filedata=backupactive
> performance concerns.  But it seems to me that some of the most important
> features of TSM (forever incremental and version control), almost dictate
> that some server-based background data movement will be needed, the
question
> is how/when it occurs.  One reason for using Backupsets is to increase the
> performance of restores, at the expense of Server pre-recover processing.