----- "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.
|