Řešení 1:
Je někdo na sneakernetu?
Za předpokladu, že se jedná o jednorázovou kopii, nepředpokládám, že by bylo možné soubor pouze zkopírovat na CD (nebo jiné médium) a přes noc jej do cíle?
To může být ve skutečnosti vaše nejrychlejší možnost, protože přenos souborů této velikosti přes toto připojení se nemusí správně zkopírovat... v takovém případě můžete začít znovu.
rsync
Moje druhá volba/pokus by byl rsync, protože detekuje neúspěšné přenosy, částečné přenosy atd. a může pokračovat tam, kde skončil.
rsync --progress file1 file2 [email protected]:/destination/directory
Příznak --progress vám poskytne zpětnou vazbu, místo abyste jen seděli a nechali vás, abyste sami hádali. :-)
Vuze (bittorrent)
Třetí možností by pravděpodobně bylo zkusit použít Vuze jako torrent server a poté nechat své vzdálené umístění použít ke stažení standardního bitorrentového klienta. Vím o dalších, kteří to udělali, ale víte... než to všechno zprovoznili atd... mohl jsem data nechat přes noc...
Myslím, že záleží na vaší situaci.
Hodně štěstí!
AKTUALIZACE:
Víš, trochu víc jsem přemýšlel o tvém problému. Proč musí být soubor jeden velký tarball? Tar je dokonale schopen rozdělit velké soubory na menší (například na média), tak proč nerozdělit ten obrovský tarball na lépe ovladatelné části a pak je místo toho přenést?
Řešení 2:
Udělal jsem to v minulosti se souborem tbz2 o velikosti 60 GB. Skript už nemám, ale mělo by být snadné ho přepsat.
Nejprve rozdělte soubor na části o velikosti ~2 GB :
split --bytes=2000000000 your_file.tgz
Pro každý kus vypočítejte hash MD5 (toto pro kontrolu integrity) a někde ho uložte, poté začněte kopírovat kusy a jejich md5 na vzdálenou stránku pomocí nástroje podle vašeho výběru (já:netcat-tar-pipe na obrazovce relace).
Po chvíli zkontrolujte pomocí md5, zda jsou vaše kousky v pořádku, pak:
cat your_file* > your_remote_file.tgz
Pokud jste také vytvořili MD5 původního souboru, zkontrolujte jej také. Pokud je vše v pořádku, můžete soubor rozbalit, vše by mělo být v pořádku.
(Pokud si najdu čas, přepíšu scénář)
Řešení 3:
Normálně jsem velkým zastáncem rsync, ale při prvním přenosu jednoho souboru to zdánlivě nedává moc smysl. Pokud byste však znovu přenášeli soubor jen s nepatrnými rozdíly, rsync by byl jasným vítězem. Pokud se přesto rozhodnete použít rsync, velmi doporučuji spustit jeden konec v --daemon režim pro odstranění tunelu ssh, který zabíjí výkon. Manová stránka popisuje tento režim poměrně důkladně.
Moje doporučení? FTP nebo HTTP se servery a klienty, které podporují obnovení přerušeného stahování. Oba protokoly jsou rychlé a lehké a vyhýbají se penalizaci za ssh-tunel. Apache + wget by rychle křičeli.
Netcat pipe trik by také fungoval dobře. Tar není nutný při přenosu jednoho velkého souboru. A důvod, proč vás neoznámí, když je hotovo, je ten, že jste mu to neřekli. Přidejte -q0 příznak na straně serveru a bude se chovat přesně tak, jak byste očekávali.
server$ nc -l -p 5000 > outfile.tgz client$ nc -q0 server.example.com 5000 < infile.tgz
Nevýhodou přístupu netcat je to, že vám nedovolí pokračovat, pokud váš přenos skončí 74 GB v...
Řešení 4:
Dejte netcatovi (někdy nazývanému nc) šanci. Následující funguje na adresář, ale mělo by být dostatečně snadné vyladit, aby bylo možné zpracovávat pouze jeden soubor.
Na cílovém poli:
netcat -l -p 2342 | tar -C /target/dir -xzf -
Na zdrojovém boxu:
tar czf * | netcat target_box 2342
Můžete zkusit odstranit možnost 'z' v obou příkazech tar, abyste viděli trochu rychleji, protože soubor je již zkomprimován.