Greetings,
    My question is, is it necessary to use a production client for this
sort of testing?  Couldn't they use a test client, take backups, play
with the time however they want, and then when they are all done, just
delete that TSM client and all it's backups?
    Even during Y2K testing we used test systems whereever possible. 
Those test systems were built out of the production systems so the
applications were just the same.  But in the event of problems there
wouldn't be any residual gotchas to contend with after testing was done.
    If it is absolutely necessary to use a production server, maybe you
could still use a test TSM client.  If the production TSM client is
called MYCLIENT, you could register a TSM client called MYCLIENT_TEST,
then on the day you want to time-travel, name the client MYCLIENT_TEST
in the TSM options files, and authenticate, and take a first backup.
    Then they can do any testing they want during the day, and any
backups.  Then sometime before the nightly backup comes along, switch
the TSM client back to MYCLIENT, and restart the services.  You could
switch back and forth every day they wanted to test if you needed to. 
Eventually when all the testing is done, you just delete MYCLIENT_TEST
from TSM.
    The only problem with this plan is it still doesn't address the fact
that, while time travelling, MYCLIENT may get a bunch of files with
future dates.  This could still contaminate MYCLIENT's backup data if
steps aren't taken to touch each of those files to get the datestamps
right again, or restore them from MYCLIENT's last good backup to be
sure. 
    Which brings me back to, why use a production server for this sort
of testing?  Wouldn't a test server be safer? 

Best Regards,

John D. Schneider
The Computer Coaching Community, LLC
Office: (314) 635-5424 / Toll Free: (866) 796-9226
Cell: (314) 750-8721

 
 
-------- Original Message --------
Subject: Re: [ADSM-L] TSM time Travel
From: Robert Clark <robert_clark AT MAC DOT COM>
Date: Mon, March 01, 2010 9:20 am
To: ADSM-L AT VM.MARIST DOT EDU

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.