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