ADSM-L

[ADSM-L] Follow-up: Question about "Hybrid" method upgrade to TSM V6.2.2 and server-to-server export

2011-09-13 15:42:56
Subject: [ADSM-L] Follow-up: Question about "Hybrid" method upgrade to TSM V6.2.2 and server-to-server export
From: "Prather, Wanda" <wPrather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 13 Sep 2011 19:34:02 +0000
Posting a follow-up to this thread.
Been there, done that, didn't like it when I tried it.

Customer had a TSM 5.5 server with ~100G data base.  Moving to 6.2.2 on new 
hardware.

Testing showed that the EXTRACT for the upgrade took only 2 hours, but the 
INSERTDB would take at least 10 hours.  Business-critical backups run from 
AS400 systems during the day, with normal Win and Linux filesystem backups at 
night, plus some Oracle TDP's, Exchange, etc.  So as to not miss the AS400, 
Oracle, and Exchange backups, we decided to do a "hybrid" upgrade.

The short version of the steps:

*        Do as much ahead of time as possible (like upgrading the TIP, for 
example, and running fibre to the new server)

*        Shut down V5.5

*        Run the extract

*        Bring V5.5 back up in production

*        Let normal backups run overnight to V5.5

*        On 6.2.2 run the INSERTDB overnight, taking as long as needed

*        Return in the morning, bring up the 6.2.2 server

*        Define disk storage pools, attach some tape drives (some are still 
attached to V5.5)

*        Verify 6.2.2 is ready for prime time by testing some backups & restores

*        Disable sessions on both servers

*        Swap IP addresses, clean up DNS alias to point to 6.2.2

*        Bring both servers back up

*        6.2.2 is now production, but the data is 24 hours behind

*        Do a SET SERVERNAME on 5.5 server to OLD

*        Define server-to-server connections

*        Run EXPORT node * from V5.5 to V6.2.2 with fromdate/fromtime set to 
merge the data from the past 24 hours into V6.2.2

Well, that all worked well (we had done two test runs beforehand, don't expect 
to get this right the first try!) up until the EXPORT NODE, where I ran smack 
into IC74464.

I didn't know that, of course, until trying it.  What I expected to see was 
V5.5 mounting the tapes that were written during the previous 24 hours.  What I 
saw instead was old tapes being mounted and just sitting for minutes at a time. 
 I finally cancelled the Export and tried again with just the AS400 data, that 
ran tickety-boo.  Tried the Oracle TDP data, and that ran tickety-boo.  Tried 
again with an ordinary filesystem client, and again the process just wilted and 
I eventually cancelled it.

So research brought me to IC74464, which says:
Directory processing: The FROMDATE / TODATE parameter does not
apply to directories. All directories in a file space are
processed even if the directories were not backed up in the
specified date range.

So, given that all our clients backed up overnight, the V5.5 server would 
eventually have mounted every tape required to export every directory from 
every client, in order to pick up the last 24 hours of filesystem backups.

I don't see any way it is possible or practical to complete this.  Most of the 
changed files would have been backed up anyway during the overnight production 
backups the first night after implementing V6.2.2, long before we picked them 
up with the export.  The only thing we are missing are versions of files that 
changed twice, once during the INSERTDB run and again before the first night of 
V6.2.2 production.  This process might (and it's just a "might") work in a site 
that has a DIRMCpool on disk or a VTL for the primary storage pool, but even 
then I think it will take an unreasonably long time.


We got all our TDP backups across, but we're giving up on those missing files, 
I don't see any way to get them.  We will just leave the V5.5 server around for 
a month, with 1 tape drive.  We can still restore those files from it, if 
somebody needs one.  After a month or so, we'll just declare a 98% victory to 
be sufficient and shut it down.

W

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