ADSM-L

Re: Exporting ADSM/VM Data to an (ASCII-based) TSM Server

2006-02-13 09:32:17
Subject: Re: Exporting ADSM/VM Data to an (ASCII-based) TSM Server
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 13 Feb 2006 09:31:55 -0500
>> On Fri, 10 Feb 2006 14:37:02 -0600, Mark Wheeler <mlwheeler AT MMM DOT COM> 
>> said:

> I'm planning to replace my ADSM/VM 3.1 server with TSM 5.3 on
> zSeries Linux. I have about 14 terabytes of data to move. My tape
> vendor says I can't export/import using tape because of ASCII/EBCDIC
> issues. He says I have to go the server-to-server route. Some of my
> clients store over a terabyte of data each, which I'm expecting
> could take a while!

I think you expect right. :)


> Has anyone used server-to-server export/import who could provide a
> throughput rate estimate? In my case, I'll be able to exploit
> hipersockets as the "network".

I've done server-to-server import/export for terabyte scale stuff, and
have eventually gotten up to tape write speed being the bottleneck,
which is paradise as far as I'm concerned.  Now, these were 3590-B
tape drives, so I was pegging in the vicinity of 40MB/s. That's not
pokey by todays' standards, but it's not that quick, either.

Filesystems which will be likely to keep you from streaming will be
those with many small files;  in this case you will very likely peg
the database of the new server.

As has been alluded to here in the recent past, your minimum
granularity for this transition is the filespace. With significant
inconvenience you can have a given TSM client node backing up the
transferred filesystems to your new server, and the untransferred ones
to your old server.

If you find you have to cancel a filespaces' transition before it
completes, you may as well zap the filespace on the new server, you're
going to have to go through all the data again anyway.



Keep in mind, If the new server and the old server are not using the
same set of tape drives, you have additional flexibility.



- Allen S. Rout