One reason to backup the stub is for recovery. If have a server that has a lot 
of HSM there is a good chance the server won't have room for all the active 
data.  Not backing up the stub might be like backing up a Novell server but 
choosing not to backup the file after it is compressed.  Then when you restore 
you won't have room to recover all the data. In addition the data has been 
archived and even in the case of a restore there is in many cases no need to 
bring that data back.
   
  I'm not saying I don't understand your point. I'm just saying I'm not sure 
not backing up the stub file is really such a great thing.
   
  I had evauled the old DiskXtender product but I have not used the new HSM 
product yet.

"Allen S. Rout" <asr AT UFL DOT EDU> wrote:
  >> On Wed, 18 Jan 2006 16:55:25 +0100, TSM said:

> let us view tsm:
> you will only have two sorts of files on the filesystem: the original file
> or (after hsm migration) the stub
> (or not, it depends on the hsm configuration)

> so tsm will have the stub and the original file in its storage, how many of
> them depends on the copygroup parameters.
> often the active version will be the stub file

> hsm:
> hsm migrates the file and the file is in the tsm storage, stub file is
> left.

> so you have to mention both hsm and tsm parameters very carefuly, that no
> data is lost.

We agree. Contrast this with the UNIX HSM implementation, in a
similar scenario to that which I discussed. Here's the windows HSM
scenario:


]] Day 1: You run an incr, and back up the file.
]] Day 1.1: HSM decides to migrate your file. A stub is left.
]] Day 2: You run an incr, and back up the stub. (!)

On AIX, it would go:

Day 1: you run an incr, back up the file.
Day 1.1: HSM decides to migrate your file, a stub is left.
Day 2: You run an incr, and to a filesystem client the file is
completely unchanged. No new copy needed, no new copy sent.

The active version is the correct version, and there's never a stub
backed up. I think that the AIX behavior is much more clear, much
more TSM-ish.


One response to this would be using your HSM workflow to serve the
needs usually addressed by backups. But the windows-HSM storage is
managed on the TSM server as archives, not as space-managed storage.
This means that (unless you want your HSM filesystem to just lose
files after N days) you have to set retention to NOLIMIT.

This, in turn, means that you want to be -extremely- careful about how
dynamic the space is, because you'll be keeping every version of every
file, forever. Like I said in my initial reply: very very static
spaces.


- Allen S. Rout
  


                
---------------------------------
Yahoo! Photos ? Showcase holiday pictures in hardcover
 Photo Books. You design it and we?ll bind it!