----- "Remco Post" <r.p...@plcs.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.
