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.
