ADSM-L

Re: Please help me NOT migrate

2004-04-20 13:45:48
Subject: Re: Please help me NOT migrate
From: Eliza Lau <lau AT VTCAT.CC.VT DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 20 Apr 2004 13:45:03 -0400
> All right.
>
> 1. The only way to move TSM data from one operating system platform to 
> another is by using the export/import functions.
>
> 2. Exporting 24TB of data, even running a direct export from the old TSM 
> server to an import on the new server will take days.
>
> 3. How to prove this? Perform a fairly simple test. Create a test TSM server 
> on, say a Linux server. Attach enough disk to the Linux server to hold all 
> data for one decent-sized (say, 20GB) TSM client. Run an export from the old 
> server to the new server. Calculate the amount of data moved and the time it 
> takes to perform the export. You're moving data from tape to disk; now figure 
> (roughly) half again as much time will needed to move data from tape to tape.

Yes, this will be a good test on the test solaris server.  I will have some
good numbers to show the boss.

>
> There. You have a base line that you can show to the pointy-haired bosses and 
> say, "It's going to take us a *long* time to move all of this data."
>
> With a 3494, a viable alternative is to add a second TSM server and share the 
> library. Start doing your new backups through the new server, and allow the 
> data on the old server to slowly expire away. You will eventually *have* to 
> do an export to move data (particularly archives), but if you allow six to 
> nine months' worth of expiration on the old server, the export will be a lot 
> less painful.


This is something I can look into.  I can paritiion the 3494 so each server
has its own frame, tape drives, and tapes.  But will the 3494 control manager
get confused when 2 TSM servers try to talk to it at the same time?  Doesn't one
has to be the Library Manager while the other the 'slave'?

Eliza

>
> (This scenario's gonna go in the FAQ.)
>
> --
> Mark Stapleton
>
>