We hit the exact same issue in test - so we took a rather butcher-ish approach:
- When starting up the 'old' server following the extract, we defined a new, 
temporary stgpool and directed all new data to that pool.  All other volumes 
were marked 'read only'.
- normal night's backup ran, to the temp pools.
- The tapes were moved from the old server to the new one's library.  That's 
because there was a new library, but it's not essential, just that the old 
server doesn't need to know about the tapes, nor should it have access to think 
they're scratch and start making use of tapes that have useful data on them (!).
- started the 'new' server, and ensured that it had access to the tape data 
(quick test restore was enough for me)
- immediately before running the export node command we DELETED THE OLD VOLUMES 
on the old server - I hated doing that, really I did.  The old server only left 
had in it's database the data that was available to it, i.e. the stuff in the 
temporary disk stgpool.
- With the 'old' server now only containing a tiny amount of new data, the 
export node * ran just fine.

It's a lot of fiddling, especially with changing the destination of copygroups, 
but it meant it worked and the import is a 40+ hour job for that one.


----- "Wanda Prather" <wPrather AT ICFI DOT COM> wrote:

> From: "Wanda Prather" <wPrather AT ICFI DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Sent: Wednesday, 14 September, 2011 7:34:02 AM
> Subject: [ADSM-L] Follow-up:  Question about "Hybrid" method upgrade to TSM 
> V6.2.2 and server-to-server export
>
> 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