----- "Remco Post" <r.post AT PLCS DOT NL> wrote:
>
> huuh????, I know some of us have huge TSM database, but export/import
> for all node data for such a server is highly unlikely to complete in
> our lifetime.
>
> I'd say, either go for the downtime, or just build a new server (maybe
> export server) and then just point your clients to the new server. You
> need bigger faster hardware anyway for TSM 6.....
>


Most people with larger databases cannot cope with the downtime, measured in 
days, that it takes to import the database.  There are ways to import on a new 
server whilst leaving the old server running (restore db, new storage pool to 
leave the old one untouched, export the new data when everything is done) which 
might be more palatable, but I've not tried them.

Mostly I'm finding now that people don't just want to migrate to a new server 
if they have a massive database - they want to combine that action with 
splitting into more instances to reduce the db size.  Export/import is a good 
way to achieve that.

I'd be keen to try to do a full backup of nodes to the new server, so long as 
the client can complete that within a reasonable time.  If it takes 3 days to 
make a full backup then the node has no valid backup for 3 days.  Typically the 
client is the slow point rather than the server.  I'd be concerned if the 
amount of time taken to migrate the node data to a new server using 'export 
node' is too long - that's a background process which can be done in advance of 
moving the node, but note that it should take only a bit longer than the 
restore of that node.  If it takes a week to restore a node that would be well 
outside of SLA would it not?

The other issue with just doing full backups to the new server is the 
historical data that still lives on the old server. If it takes a year (or 
more) for that old data to expire, then surely that means keeping old instances 
of TSM hanging around for history?  Many clients also don't want that as they 
must return hardware for lease expiry, trade-in, etc. let alone having to 
maintain yet another box.  Not a problem if your RETONLY is 10 days and 
archives are only kept for a month, but if your archives are there for 7 years 
you have no choice but to move stuff around somehow.

The result is that you must pick the migration method on a per node basis - 
there are many factors to decide which method is chosen, none of which are 
ideal.