Re: Antwort: Re: Windows HSM experiences?
>> On Wed, 18 Jan 2006 16:55:25 +0100, TSM <tsm AT PROFI-AG DOT DE> 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 migrates the file and the file is in the tsm storage, stub file is
> 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
]] 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
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
- Allen S. Rout