Migrating from a 3494-L12 with 3590 E1A's to 3494-L22 with 3592 J1A's -- Suggestions Please

[joejurak]

Hello -- I have been tasked with migrating a TSM server to a new pSeries system. The new 3494 library will have 3592 J1A tape drives. The issue is that the old media (10000 + volumes) is not readable or writable with the new tape drives. The old drives were 3590 E1A's. Now -- it is not practical to consider migrating all of that data to the new media ... I am looking for sound suggestions on how build this new environment and make it so the New TSM server and Library can access the Old Data on the 3590 E1A Media BUT Write new backups to only New Drives/Media...



Not sure if I should start from scratch with the new TSM server and simply have a second instance of TSM running the OLD database just incase I need to restore Old Media Data.... I would obviously need at least one 3590 Drive to do this...



Or - Restore the Old Database to the new server and simply not checkin the old media -- but have a mixed drive environment



etc... Please- if you have gone through a similar task please give my your input! I would love some good suggestions!



Thanks!

 

[heada]

I am going to be facing this same problem next year (hopefully) and I'm kicking around a few ideas. I have several years of history on 3590 tapes (about 11,000 tapes) and I have to keep all that history around.



I don't want to buy and build a new 3494(I already have 3), so I would have to migrate my existing 3494. I have 16 3590-E1As. If I take out 4 3590-E1As and replace them with 3592-J1As and checkin about 500 new tapes, I can define a new library in TSM to use those drives and tapes (volser masking to a new catagory on the 3494 side to keep it from getting confused) I would then change the stgpools to use this new library and all new backups would write to it.



At this point, I would start a migration process for all the old 3590 media to 3592 media and as I checkout scratch 3590s I'd replace them with 3592 scratch tapes. As more and more tapes are converted, I would slowly swap out 3590 drives for 3592 drives until I had only 2 drives left (for copypool restores)



I would then start a migrate process for the copypool tapes until (after about a very slow year) I no longer have any 3590 tapes and I remove my final 2 3590 drives.



VERY slow (and kinda expensive) way to do it, but this way I don't have to change ANY clients (no new servers) and I keep all my history available at all times. (FDA controlled company... I HAVE to keep my history around)



-Aaron

 

[joejurak]

Ok -- Nice to see I am not alone!! Although my environment is large -- sounds small in comparrison to yours! I like a couple of your Ideas here -- Particularly regarding disk pools and simply pointing their migration destination to the NEW 3592 drives -- Presto -- no old tapes will be written to and all the while -- all old media is still accessable! This is a good point because it answers the question of control.

Ok -- here is the one issue I see with you complete strategy and I know this to be an engineering limitation at this time (May change in near future): 3592's and 3590's CANNOT reside in the same frame. The 3592's can only go into a L-22 or a D-22. You probably already know this though...



I have some additional thoughts to add to this that I would love to kick around but need to continue tomorrow -- It has been a very long Day!



Thanks heada!

 

[AndyRH]

Our plan is similar to Aaron's and oddly for the same three letter reason. Our fist 3592's go into a new frame in each library. For AS/400 reasons we will maintain at least one 3590 indefinitely in the L frame of each library since we can not mix in the same frame as already mentioned.

I have not found a better way, but I am always looking. I have looked at several tape drive change threads and this is the best way I have seen described.





Andy

 

[heada]

In my 3494s, I have 8 frames (1 L and 7 D) with 2 3590s in the L, 2 3590s in the first D and 4 3590s in the next 3 Ds.(the rest of the Ds are purely storage) This is why I was going to change out the drives 4 at a time, one D at a time. The L would be the very last to be changed.



Silly engineers...making it hard for us. :grin:



-Aaron

 

[joejurak]

Aron, Andy, Thanks!



So -- Here is what I am thinking, and please comment, shoot holes in it, etc...



I will preface this by saying that I will be replacing the TSM server with a p650 and fibre attached storage for diskpool.

The new TSM server and Library will be located in a NEW server room -- so whether I go with option 1 or option 2 - I will still have to be located in the new server room in the end..



Here are the two scenarios I have so far:





Scenario 1.

a. Purchase a New 3494-L22 base frame with 4 3592 fibre tape drives. Install the latest and greatest TSM server software on the new p650 and define the new Library, device class, drives, and drive paths. Define the disk storage pool on the new fibre disks. The next storage pool for the diskpool will be to the new TAPEPOOL associated with the new Library/Drives.



b. Establish the TSM server to server commnications (New TSM server / Old TSM server). Export all Admin, Policy, Schedule, and Client definitions from old TSM server and import on New TSM server. NOT DATA.... I will then change each client Option file to point to the new TSM server. This will initiate a FULL backup for each client when scheduled -- to the NEW media.



c. Once all clients are backing up to the new TSM Server, I will stop all processing on old TSM server , backup the old TSM server database, Create a second TSM instance on the NEW p650, restore the Old database to this second instance, and take it offline. I will then have IBM move the D12 and S10 from the old 3494 library to the new library. I will add the D12 and its drives to a New Library Partition, and the S10 to the existing partition. I will create the necessary definitions to the OLD TSM instance to the 2nd Library partition and then simply shut it down. The only time it would be utilized is to restore a client from a point in time Prior to the new TSM server.



I know this may seem a little complex but here is my logic.... There is no risk to the existing TSM environment at any time. The new TSM environment will be built and operational prior to any changes to the current environment. Thus, backups are never interupted. Second, Upgrading the existing Library will cause significant down time since the L-12 must first be converted to a L-22 prior to adding the 3592 drives and the Library manager must be upgraded as well. I think there are a lot of potential time-consuming issues that are possible here... Third, the old library will still need to be moved to the new server room, and lastly, The first backup to the new media will be FULL for each client.



Scenario 2.



a. Upgrade Existing 3494 -L12 to 3494-L22

Move 2 3590 Drives from L frame to D frame thus giving the existing D-12 4 3590 drives.

Add 4 New 3592 Drives to the converted L frame.

Upgrade the Library Manager (Required as a part of the conversion)



b. Create the necessary definitions for the new drive class, drives, etc... to TSM

(Do I need to partition the Library or will the difference in the volsers be enough for the Library manager to keep media separate for each drive type???)



c. Create a new tapepool and associate with new drives and then change existing DiskPool to point to the new Tapepool. This way (as you mentioned) all new backups will go to new tape only.



d. Build new TSM server on the new p650, restore the database from the old TSM server. Take old TSM server off-line. Move the Library to new Location and attach to new TSM server and make all necessary changes so that new server is operational with tape library and all backups continue...



Anyway -- you get the main ideas here I think. I do have one important question for you Aaron, You mentioned Migration of date from old media to new media. Specifically



"I would then start a migrate process for the copypool tapes until (after about a very slow year) I no longer have any 3590 tapes and I remove my final 2 3590 drives.



VERY slow (and kinda expensive) way to do it, but this way I don't have to change ANY clients (no new servers) and I keep all my history available at all times. (FDA controlled company... I HAVE to keep my history around)"



Please elaborate a bit... I have not gone through a migration process yet from one media type to another.... My two scenarios above simply have to wait out the retention policy.



Sorry for the very long-winded reply here but this is a big project and will be complicated.



Thanks!!!



Joe.

 

[heada]

Joe,



I think that option 1 is more then likely the way to go since you are moving locations and hardware.



The migrate process I was talking about is the move media command. If you type in "move media {old_vol} stgpool={new_stgpool} remove=yes checklabel=no" it will read the data from the old volume and write it to the new stgpool and then remove the old volume from the library. Very handy if you need to change what is on what tape. You can do this by setting the reclamation stgpool on your old stgpool to the new stgpool and then gradually stepping down the reclamation threshold, but I like to do it one tape at a time in a controlled fashion(I'm in control vs TSM in control)



-Aaron

 

[joejurak]

Yeah, I like option One as well.... It takes a lot of risk out ot the project. I am still in a dilemma, however, on restoring the TSM database to the new server vs. just building from scratch and importing needed policies, client definitions, etc... If I restore the full database to the new server/new library combo, I won't have to maintain two instances of TSM. Problem is, any restore process would require both types of media since all backups are incremental after the first initial full backups. BUT migrating the data as you, have described below, over time, will alleviate this... I am curious; what methods are available for FORCING a full backup of each client to the new TSM server if I restore the old TSM database in full?? If I could make this happen from the central scheduler instead of Manually performing a FULL backup of each client, that would make life much easier (More than 300 client nodes) See, the reason I want a full backup to the new media -- is that if a restore were necessary (and most restores do require the very latest point in time) then more than likely, the data would reside only on new media... If I don't force a full backup of each client then the incrementals would simple continue on the new media. Also -- over time I can do the migration you mentioned.



Two benefits of keeping two separate TSM instances are

1. There is a very clear point in time cutover.... Any restores required prior to that point in time will come only from the old media.... In a very specific number of days (365) I can fully discard my old media since my retention is exactly 1 year.



2. I really never have to go through any type of migration process to the new media...





Thanks again Aaron!

:grin:

 

[rmeyer]

I am jumping in here following your great discussion just to say that I too will be looking at this in the near future and I plan to handle it a lot like Aaron was saying - I plan to migrate my data from the old 3590-K tapes to the new jaguar tapes. Over time this will free up a lot of slots and possibly let me shrink my library by a frame or two, or at least not have to keep adding 1 frame every year and a half. I will keep a couple of 3590 drives in the library for quite a while even after I finish moving all live data as I have a legal hold on some of the tapes (some lawyers just do not believe that moving data from 1 tape to another tape doesn't change that data).



Joe - one thing to keep in mind if you shut down your old TSM and only fire it up for periodic restores - your old tape inventory will never decrease. If you at least fire up the system on occasion and run expire inventory from time to time you might be able to decrease storage costs for all of the old tapes.



Roger

 

[joejurak]

Thanks for your feedback Roger -- It is most welcome...

I hope to get more resources involved in this discussion as I believe some good strategies can be developed here to help us all... I believe many will be faced with something similar in the coming months...



Your point is a good one!



Joe

 

[heada]

To ensure that all clients perform a full backup on the new media, just changes the copymode on the copygroup that the clients run to from modified to absolute. This will force a full backup for all clients that write to that copygroup (basicly management class) Look at the commands "query copygroup" and "update copygroup"



I am stuck where the government(FDA) tells me that certian types of data must be kept for so long. No if ands or buts about it. I have data that must be restorable for 7 years beyond the life of the product we sell. I'm not happy about it but thats my job. Since it sounds like you don't have that requirement, I would say just build a new server and export over those parts you need. Keep the old server up and running for awhile (maybe a few months) for those restores that will happen requiring old data. After a period of time(when the restore requests for that server drop off), just shut it down. It'd be easier then trying to move all your history over to the new tapes.



Something to keep in mind for those lawyer types. Magnetic media is only good for so long (I've seen about 4 to 7 years for 3590s). After that, the mylar tends to lose the ability to hold on to the bits (magnetics and all that jazz) If they want long term storage on a media that will not degrade (or not nearly as fast) look at optical (DVD or WORM or the like) That media is rated for 20+ years (assuming you get the good media)

With regards to the governemt(atleast the FDA), they don't care where I keep my data as long as I can put it back just like it was when I read it from the client. Don't tell them what you're doing and they can't ask questions. :grin:



-Aaron