Whilst I have not tried this across a version gap as big as this (and
you will therefore need to experiment)
if you use

gzip --rsyncable to compress the archives

and use rsync to transfer the 11.5 archive over the top of an already
transferred 10.0 archive - you MAY be surprised at the transfer time.

Others closer to the internals of an ontape archive may be able to blow
this out the water...

If indeed it doesn't help enough can you do an upgrade in UK on a test
machine just to get a valid archive and get that transferred to rsync
over the top of?

It might even be faster, once you have transferred such a reference
archive to rsync the final archive uncompressed, whilst using rsyncs own
on the fly compression.

--
Clive

--
This message has been scanned for viruses and
dangerous content by OpenProtect(http://www.openprotect.com), and is
believed to be clean.

On 05/08/2010 10:43, Clive Eisen wrote:
Well, you could try something like the following :

ontape -s -L 0 -F -t STDIO | gzip -c | remsh host1s "set_cl1_sec >
/dev/null; gunzip | ontape -p -t STDIO 2>/dev/null”

This will still have to pump say 50 Gig across the line (assuming that
gzip can compress 300 Gig to 50 Gig), but it means that you do not have
the intermediate archive file to write / read as it will go straight
from source to target.

ideally the restore completes before wrapping the logs on the primary.

I know of 300 Gig plus instances being set up like this, and they were
happy )

Proof is obviously in the testing