ADSM-L

Re: [ADSM-L] 5.5 -> 6.2

2010-03-17 12:43:13
Subject: Re: [ADSM-L] 5.5 -> 6.2
From: Remco Post <r.post AT PLCS DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 17 Mar 2010 17:44:04 +0100
On 7 mrt 2010, at 23:37, Xav Paice wrote:
> 
> 
> Most people with larger databases cannot cope with the downtime, measured in 
> days, that it takes to import the database.  

I fully agree with you on this one. Having a larger than recommended database 
is now a challenge to these customers. 

---8<---
> 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 partly agree. Splitting the database makes a lot of sense in the TSM 5 era, 
with TSM 6, there is less reason to do so, provided that IBM will never ever 
make us go through such an upgrade again.

> 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?
> 

A full backup and a full restore of a node should ideally take about the same 
amount of time. With a restore, there is of course a bit more tape-handling 
going on. An export, OTOH, needs to crawl through all active and inactive 
objects, rather than only the active objects. This may take quite some extra 
time. You are right, one could run a partial export and incrementally export a 
node if an export takes to long.

> 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?

Backup data retention of more than a few months is a problem. I know a lot of 
people have a hard time convincing customers that this data should most likely 
be archived, and I know that such retentions exists. And yes, in such cases, 
one would need either to export/import or keep the data around in the old 
server for such a long period.

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

so, export the archive data (usually, if you're smart that's just a small bit), 
and restart your backups.




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

I prefer to do a 5.4 to 5.5 upgrade over anything to do with 6.1...


-- 
Met vriendelijke groeten/Kind regards,

Remco Post
r.post AT plcs DOT nl

<Prev in Thread] Current Thread [Next in Thread>