Solución 1:
Sneakernet ¿Alguien?
Suponiendo que se trata de una copia única, no creo que sea posible simplemente copiar el archivo en un CD (u otro medio) y enviarlo de la noche a la mañana al destino, ¿está ahí?
En realidad, esa podría ser su opción más rápida, ya que una transferencia de archivos de ese tamaño, a través de esa conexión, podría no copiarse correctamente... en cuyo caso puede comenzar de nuevo.
rsync
Mi segunda opción/intento sería rsync, ya que detecta transferencias fallidas, transferencias parciales, etc. y puede retomar desde donde lo dejó.
rsync --progress file1 file2 [email protected]:/destination/directory
El indicador --progress le dará algunos comentarios en lugar de simplemente sentarse allí y dejar que usted mismo adivine. :-)
Vuze (bittorrent)
La tercera opción probablemente sería probar y usar Vuze como un servidor de torrents y luego hacer que su ubicación remota use un cliente de bitorrent estándar para descargarlo. Conozco a otros que han hecho esto, pero ya sabes... en el momento en que tuvieron todo listo para funcionar, etc... Podría haber guardado los datos durante la noche...
Depende de tu situación, supongo.
¡Buena suerte!
ACTUALIZACIÓN:
Sabes, me puse a pensar un poco más en tu problema. ¿Por qué el archivo tiene que ser un solo tarball enorme? Tar es perfectamente capaz de dividir archivos grandes en otros más pequeños (para abarcar medios, por ejemplo), así que, ¿por qué no dividir ese enorme tarball en partes más manejables y luego transferir las partes en su lugar?
Solución 2:
Ya lo hice en el pasado, con un archivo tbz2 de 60 GB. Ya no tengo el guión, pero debería ser fácil reescribirlo.
Primero, divide tu archivo en partes de ~2GB:
split --bytes=2000000000 your_file.tgz
Para cada pieza, calcule un hash MD5 (esto es para verificar la integridad) y guárdelo en algún lugar, luego comience a copiar las piezas y su md5 al sitio remoto con la herramienta de su elección (yo:netcat-tar-pipe en una pantalla sesión).
Después de un tiempo, verifique con el md5 si sus piezas están bien, luego:
cat your_file* > your_remote_file.tgz
Si también ha hecho un MD5 del archivo original, compruébelo también. Si está bien, puede descomprimir su archivo, todo debería estar bien.
(Si encuentro el tiempo, reescribiré el guión)
Solución 3:
Normalmente soy un gran defensor de rsync, pero cuando transfiero un solo archivo por primera vez, no parece tener mucho sentido. Sin embargo, si volviera a transferir el archivo con solo ligeras diferencias, rsync sería el claro ganador. Si elige usar rsync de todos modos, le recomiendo ejecutar un extremo en --daemon mode para eliminar el túnel ssh que mata el rendimiento. La página de manual describe este modo bastante a fondo.
¿Mi recomendación? FTP o HTTP con servidores y clientes que admitan la reanudación de descargas interrumpidas. Ambos protocolos son rápidos y livianos, y evitan la penalización del túnel ssh. Apache + wget estaría gritando rápido.
El truco de la tubería netcat también funcionaría bien. Tar no es necesario cuando se transfiere un solo archivo grande. Y la razón por la que no te notifica cuando está hecho es porque no se lo dijiste. Agrega un -q0 marca al lado del servidor y se comportará exactamente como esperarías.
server$ nc -l -p 5000 > outfile.tgz client$ nc -q0 server.example.com 5000 < infile.tgz
La desventaja del enfoque de netcat es que no le permitirá reanudar si su transferencia muere 74GB en...
Solución 4:
Dale una oportunidad a netcat (a veces llamado nc). Lo siguiente funciona en un directorio, pero debería ser lo suficientemente fácil de modificar para copiar solo un archivo.
En el cuadro de destino:
netcat -l -p 2342 | tar -C /target/dir -xzf -
En el cuadro fuente:
tar czf * | netcat target_box 2342
Puede intentar eliminar la opción 'z' en ambos comandos tar para obtener un poco más de velocidad, ya que el archivo ya está comprimido.