But remember that selective causes you to use a version regardless of weather the file has changed or not. Also, the caching function uses an algothrithm that removes the oldest data first.
Steffan ----- Original Message ----- From: "Richard Cowen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 27, 2002 11:26 AM Subject: Re: Idea for a TSM feature > > -----Original Message----- > > From: James Thompson [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 27, 2002 12:51 PM > > To: [EMAIL PROTECTED] > > 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.
