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
|