Back during the run up to Y2K, I was doing storage/backup admin.

The team doing Y2K testing didn't tell us anything about what they
were doing, and they started to get weird results with attempted
restores when they took systems forward and backwards in time.

My first reaction was that they were endangering the production TSM
servers by testing against them. My second reaction was that they
needed to seek out a Time Lord.

Part of the problem was the havok the time travel rasied with
retention, the other part was the difficulty in figuring out what to
restore.

Our work around was to script a call to from the time-traveling
system to a not-time-traveling system to get the real world time, and
then use that text in the description of an archive.

When folks wanted to do a retrieve, all they needed to do was look
over the description fields to see what dates were available.

I was happy to see testing completed, and the archived filespaces/
nodes deleted.

Thanks,
[RC]

On Feb 22, 2010, at 2:42 PM, Steve Harris wrote:

Hello Again,


I have a client with a requirement to perform testing at different
times
into the future.  They wish to set the clocks, backup, do some
testing,
backup,  set the clock again, and so on.

They wish to be able to roll forward and *backward* to any time
that they
have tested at.

Now I realize that the TSM scheduler will have conniptions if the
server
time is too far out.  Assuming that we kick off a backup by some other
means, will TSM handle being able to roll back and forth in this
manner?
Will the client be able to see a backup on march 1 that was taken at a
client time setting of October 1 2010?

Any pointers/gotchas  gladly received.

Regards

Steve

Steven Harris
TSM Admin
Paraparaumu, New Zealand.