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 <mezron AT HOTMAIL DOT COM>@VM.MARIST.EDU> on 02/27/2002 11:50:42
AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
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
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:mezron AT HOTMAIL DOT COM]
>Sent: Wednesday, February 27, 2002 11:44 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>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