SCO

If you find that the reason you can't tar a big file is that the file system sets a limit, it would seem reasonable to conclude that you ought to be able to tar it in smaller pieces. tar | split will allow you to break up the tar file in fragments which you can cat together at the other end.

Well, then I wonder why you do bother with creating that tarball locally. Stream it using ssh and you're done.

The server has OpenServer 5.0.5 which does not have ssh natively and it was never installed. It is on its way out from my server "park."

Can you provide an example?

I have GNU tar and GNU split and GNU tail. I don't know if those are available for SCO (lawsuit time? <ducks>) but you might be less lucky with the built-in variants, for example in whether split accepts human-readable big numbers (I calculated 1024*1024*512 and put that in here, but GNU split would allow simply "512m") and, more crucially, whether it can read standard input when you say "-"

Split demonstrated:

Code:

vnix$ echo fnord | split -d -b 3 - fnord.
vnix$ ls fnord.*
fnord.00  fnord.01
vnix$ tail fnord.*
==> fnord.00 <==
fno
==> fnord.01 <==
rd

Archiving:

Code:

tar whatever | split -a 4 -d -b 536870912 - whatever.tar.

-d means use numeric suffixes, -a 4 means create suffixes of length 4, -b bignum is how big each file can be.

Dearchiving:

Code:

cat whatever.tar.* | tar xvf -

Make sure you have enough digits in the suffix so that cat will not put them in the wrong order! I believe the wildcard should expand to an alphabetic list on all platforms.

I've done this when I had to make backups to an USB drive which was FAT formatted so it only accepted (IIRC) max 2 gigs in one file, but this is untested, from memory.

I suggest you try to create a big file with dd like fabtagon proposed, just to check that your coordinates are not completely off.