> -----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.