You've got to do the local storage yourself, and have that ready to
receive the filedata. The only things that can be brought over by the
exports are things that are platform-independent. Having the system
guess what libraries, volumes, paths, drives, filesystems, disks,
whatever it's supposed to use is just too much to guess. Perhaps if
you were to define device classes and it would transfer stgpools that
use matching devclass names, but even that's just a guess, so they
haven't written it. That's another good reason for my own plan of doing
a pure metadata server export, following it with node exports. Once the
nodes and policies are defined on the destination, I set dest for each
domain as desired. Then, I make copies of the domains with dest set to
go direct to a sequential pool (no point importing them into DISK and
then migrating right away), and set each node to those temporary domains
for the duration of the node import, then move the node to the correct
domain at the same time I change the node's dsm.sys and dsm.opt.
If the destination has all the same device names and such, you COULD
create your devclasses. Pull your PLAN and make the macro. But really,
it's just not very hard to do it by hand.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard
Sent: Wednesday, September 10, 2008 4:46 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM 5.2.9: Migration from AIX to SuSE Linux
I ran the following commands:
export server toserver=NASCTSM filedata=all export server
toserver=NASCTSM fromdate=10/02/2002 filedata=all mergefilespaces=yes
I get everything except the storage pools and volhistory. Is there
another way to get this information over to my new server?
Thanks,
Richard
+----------------------------------------------------------------------
|This was sent by richard.dressell AT yahoo DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
|
