Soluzione 1:
Sneakernet chiunque?
Supponendo che si tratti di una copia una tantum, non suppongo che sia possibile semplicemente copiare il file su un CD (o altro supporto) e da un giorno all'altro portarlo a destinazione, vero?
Questa potrebbe effettivamente essere la tua opzione più veloce in quanto un trasferimento di file di quelle dimensioni, su quella connessione, potrebbe non essere copiato correttamente... nel qual caso dovrai ricominciare tutto da capo.
rsync
La mia seconda scelta/tentativo sarebbe rsync in quanto rileva trasferimenti falliti, trasferimenti parziali, ecc. e può riprendere da dove era stato interrotto.
rsync --progress file1 file2 [email protected]:/destination/directory
Il flag --progress ti darà un feedback invece di stare seduto lì e lasciarti indovinare da solo. :-)
Vuze (bittorrent)
La terza scelta sarebbe probabilmente quella di provare a utilizzare Vuze come server torrent e quindi fare in modo che la tua posizione remota utilizzi un client bittorrent standard per scaricarlo. Conosco altri che l'hanno fatto, ma sai... quando hanno messo tutto in funzione, ecc... avrei potuto perdere i dati dall'oggi al domani...
Dipende dalla tua situazione immagino.
Buona fortuna!
AGGIORNAMENTO:
Sai, ho pensato ancora un po' al tuo problema. Perché il file deve essere un unico enorme tarball? Tar è perfettamente in grado di suddividere file di grandi dimensioni in file più piccoli (ad esempio per estendere i media), quindi perché non dividere quell'enorme tarball in parti più gestibili e poi trasferire i pezzi?
Soluzione 2:
L'ho fatto in passato, con un file tbz2 da 60 GB. Non ho più lo script ma dovrebbe essere facile riscriverlo.
Per prima cosa, dividi il tuo file in parti di ~2GB :
split --bytes=2000000000 your_file.tgz
Per ogni pezzo, calcola un hash MD5 (questo serve per verificare l'integrità) e memorizzalo da qualche parte, quindi inizia a copiare i pezzi e il loro md5 sul sito remoto con lo strumento di tua scelta (io:netcat-tar-pipe in una schermata sessione).
Dopo un po', controlla con md5 se i tuoi pezzi sono a posto, poi :
cat your_file* > your_remote_file.tgz
Se hai fatto anche un MD5 del file originale, controlla anche questo. Se va bene, puoi decomprimere il tuo file, dovrebbe essere tutto a posto.
(Se trovo il tempo, riscriverò la sceneggiatura)
Soluzione 3:
Normalmente sono un grande sostenitore di rsync, ma quando si trasferisce un singolo file per la prima volta, non sembra avere molto senso. Se, tuttavia, stavi ritrasferendo il file con solo lievi differenze, rsync sarebbe il chiaro vincitore. Se scegli comunque di utilizzare rsync, ti consiglio vivamente di eseguire un'estremità in --daemon mode per eliminare il tunnel ssh che uccide le prestazioni. La pagina man descrive questa modalità in modo abbastanza completo.
La mia raccomandazione? FTP o HTTP con server e client che supportano la ripresa dei download interrotti. Entrambi i protocolli sono veloci e leggeri, evitando la penalità del tunnel ssh. Apache + wget urlerebbe velocemente.
Anche il trucco della pipa netcat funzionerebbe bene. Tar non è necessario quando si trasferisce un singolo file di grandi dimensioni. E il motivo per cui non ti avvisa quando ha finito è perché non glielo hai detto. Aggiungi un -q0 flag sul lato server e si comporterà esattamente come ti aspetteresti.
server$ nc -l -p 5000 > outfile.tgz client$ nc -q0 server.example.com 5000 < infile.tgz
Lo svantaggio dell'approccio netcat è che non ti permetterà di riprendere se il tuo trasferimento muore 74GB in...
Soluzione 4:
Dai una possibilità a netcat (a volte chiamato nc). Quanto segue funziona su una directory, ma dovrebbe essere abbastanza facile da modificare copiando solo un file.
Sulla casella di destinazione:
netcat -l -p 2342 | tar -C /target/dir -xzf -
Sulla casella di origine:
tar czf * | netcat target_box 2342
Puoi provare a rimuovere l'opzione 'z' in entrambi i comandi tar per un po' più di velocità visto che il file è già compresso.