Your methodology is correct. It's preferable to maintain the old solution
and phase it out over time, but if you have to migrate you have to migrate.
Potential Problems:
Depending on how TSM has been managed/groomed you may discover that
recovering $clientname_$savetime may take a very long time to complete.
You'll want to get some estimates of time to complete so you can evaluate
whether the project is feasible. If it is a 20 year project your management
may decide that's not something they want you doing for the next 20 years
:-).
You may also discover that some things can't be recovered. Nothing you can
really do about that. You have what you have.
You do need to resolve the application restore problem. You may be able get
temp licenses from your application vendors for a data protection migration
project, since you are not using the databases - just recovering them and
backing them up.
There are companies out there that can do this migration for you but I
couldn't find one that does it for TSM. You might try giving your EMC rep a
call. See if they have a way to do this automatically. I know they've been
working on this kind of stuff.
What is your disaster recovery plan for these applications? You may want to
simply exercise your disaster recovery plan and then do a backup of the
restored environment with NetWorker as your last step.
-----Original Message-----
From: Gaddy [mailto:xy.0815 AT GMX DOT NET]
Sent: Friday, October 06, 2006 5:15 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Migrating backup data from tool "A" to tool "B"
Ok, this is a bit off topic,
but I have been asked recently how to migrate data on tapes from
TSM to NetWorker (or NetBackup to TSM or the like).
And I haven't found an easy answer yet.
My theoretical migration scheme would be like this <very first guess>:
1.) have a very big disk (SATA array) at hand
2.) develop a new systematic order for the migrated data sets
e.g. $clientname_$savetime
3.) create directories/volumes named according to this order
4.) restore datasets into this directory with $OldTool
5.) backup directories/volumes with $NewTool
While this could(?) be a solution for filesystems,
I expect a lot trouble for all those application data
(i.e. R/3, Oracle, Exchange, etc.), which will not
fit easily into a directory scheme like this.
And most of the restores would require the application on
the "migration client".
Sure I know I could keep the old servers/tapes/drives/licenses etc.
But any ideas of solving the problems if I REALY HAVE TO MIGRATE are
pretty much appreciated.
Any body has gone through this nightmare yet?
Are there professional tools available?
Thanks a lot -sg-
--
Steffen Gattert; COMPAREX Hannover, Germany
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type
"signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if
you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
