The system works exactly as it does now. Data goes to disk, then migrates to tape. Both disk and tape pools are backed up to copy pools. The only difference is that when you migrate, Instead of migrating the largest file spaces, you migrate only the inactive files. We have migration delay where we can set how old a file must be before it migrates, this is just delaying migration until the file becomes inactive
-----Original Message----- From: George Lesho [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, March 27, 2002 10:23 AM To: [EMAIL PROTECTED] Subject: Re: Idea for a TSM feature Hope you folks don't have a disaster and lose your disks... How would DRM work with active files all held on disk? I guess you could copy the active files to your copy pool(s) to get the stuff offsite rather than migrate to a primary pool. I sure wouldn't want to tell the folks I work for that we only had copies of inactive files from which to perform a disaster recovery... George Lesho AFC Enterprises James Thompson <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 02/27/2002 11:50:42 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: (bcc: George Lesho/Partners/AFC) Fax to: Subject: Re: Idea for a TSM feature With current/future tape technology the most important thing for performance is to be able to stream data to and from the tape drive. Certain TSM operations stream data to tape really well (migration). Due to the granularity of TSM (file level) retreiving data from tape is normally not streamed. Any type you have to relocate with tape, your performance suffers. Generating backupsets can cause a lot of tape mounts with a lot of locates needed to get the active versions. Having this feature would eliminate tape performance issues with creating backupsets. Also file system restores would not have tape performance issues with the active versions. 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. The one issue I do see with this feature would be dealing with aggregates. A file aggregate could have both active and inactive. But theses types of development isses are not anything I would have to deal with..... :) James Thompson ------ I am sure others will reply, but why not use large cached primary disk pools? If you need to, define a separate pool for each "important" client, large enough to hold a "full" backup. That way, all the active files will usually be in the pool. (Exceptions will break this, eg a big file that changes every day may flush out an "old" active file....) True? (See TSM Guide for disadvantages of cached pools...) While I suspect that having active/inactive be in different storage pools would "break" something in TSM, maybe we could get a "move data node=xxx type=active" command... >-----Original Message----- >From: James Thompson [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, February 27, 2002 11:44 AM >To: [EMAIL PROTECTED] >Subject: Idea for a TSM feature > > >Thought I would throw an idea I had for a TSM feature out on >the listserv and get some thoughts no whether this would be useful or not. > >The feature that I would like to see is the ability to create >a special disk storage pool, that would only migrate inactive versions of >backup objects to the next storage pool. This would keep all the active >versions on disk storage. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
