Merge TSM servers and upgrade

patbel

Newcomer
Joined
Aug 20, 2019
Messages
3
Reaction score
0
Points
0
Hi,
I saw plenty of topics regarding upgrade of tsm servers and even merging few with export server command, but none of it solves my problem fully.

Now I have 4 TSM servers each witn 7.1.7 release. My intention is to end with single and up-to-date server on new hardware
.
Here's what I intend to do:

1. merge 4 servers into single 7.1.7 machine (not new, merge them all to one of existing)
2. install tsm 7.1.7 on new hardware
3. migrate old server to new server
4. upgrade tsm@new server

Now, first step is what I cannot figure out by myself. If I understand export server command, it copies data between servers if I choose FILEData=None no data will be copied except for node, policy etc definitions. If I pick FILEData=All it will copy all existing data - that is not my intention - there are PB of data, it will take months to execute.
Is there a way to merge two servers in such manner that it will move all from database - tape definitions, information about files stored and owner, nodes, policies etc, without copying any data from tape to tape and (unlike with db2 export/import) overwriting server definitions?
 
I forgot, one of these existing servers share libraries to the others. So most comfortable would bo to merge the other servers to that one which already has libraries defined.
 
There's only 3 ways to merge servers:
1 - point nodes to new server and start new backup after X days, get rid of old server (not really a merge)
2 - use export/import to send data from old server to new server
3 - use node replication to send data from old server to new server

Option 1 doesn't get you any historical data

Options 2 and 3 will have the same end result. Both will need to copy the data from the old to the new server, there's no way around that. Option 3 is much easier than 2 because you can automate it and also it's incremental. You can run it multiple times, and each time, it works on replicating what has not been sent yet.

So it would make sense that the first server you migrate is the largest server, that way the other 3 will have less data to copy over.
 
Thank you for suggestions, actually maybe I'll have to only migrate small clients (<10TB) so I'll consider node replication.
Option 1 is also good hint as long as client is fine with old data left on old server.
 
Yes, you can do a mix. Option 1 also work well if the retention is short, like a month or less. That means that after a node has been backing up for a month to the new server, that data is no longer needed on the old server.

Where it gets more complicated is for nodes that have long retention. With those, you either have to replicate all the data for that node, or keep the old server until that data expires.
 
Back
Top