Sugiérame la forma MÁS RÁPIDA de transferir datos comprimidos de 35 GB (usando 7zip) desde mi computadora portátil a un servidor remoto. Por favor publique el comando también. He usado SCP pero es terriblemente lento, rsync es mejor pero con su velocidad de aproximadamente 1 MB/min, puede llevar mucho tiempo. ¿Hay alguna forma mejor?
Respuesta1
ftp y http son los más rápidos, ftp es más rápido para una cantidad menor de archivos grandes y http más rápido para una cantidad mayor de archivos pequeños (no sorprende considerando la naturaleza del tráfico http).
Puntos de referencia adicionales -https://www.disk91.com/2014/technology/networks/compare-rendimiento-of-diferente-archivo-transferencia-protocol-over-latency/
Nota: Su proveedor de Internet puede limitar la velocidad de carga según su proveedor. Si su proveedor impone un límite de velocidad o datos, puede que no importe.
Es posible que también puedas utilizar otros métodos, consultahttp://moo.nac.uci.edu/~hjm/HOWTO_move_data.html
Respuesta2
35 GiB tardarán unos 25 días a 1 MB/minuto (17 kB/s). Como llevará mucho tiempo, me centraría en una forma que le permita reanudar fácilmente. Hasta donde yo sé, esto descarta scp y buscaría los siguientes candidatos:
- http(s)
- sincronización
- red de zapatillas
Configurar un servidor web para entregar un solo archivo es bastante fácil; una instalación estándar de Ubuntu puede hacerlo sin ninguna configuración, siempre que se pueda acceder a la máquina desde Internet. Simplemente coloque el archivo /var/www/html/(o vincúlelo allí).
Úselo wget -c http://example.com/file.tarpara reanudar la descarga si se interrumpe. Esto funciona de manera bastante confiable. Dado que es algo único, no se moleste con los certificados SSL: cifre y firme los datos si le preocupa la seguridad y la integridad.
Rsync se transfiere a través de SSH, por lo que es seguro. Admite una continuación perfecta. debería admitir la reanudación y transferir el archivo sin preocupaciones.rsync -P localfile [email protected]:remotefile
Pero 25 días es mucho tiempo. Probablemente pueda copiar la unidad a una unidad USB y enviarla por correo más rápido. Se pueden conseguir unidades USB de 64 GiB por unos 20 USD. Si lo envía por DHL, llegará a casi cualquier lugar en un plazo de 3 a 4 días.
En resumen: la opción más rápida con esta cantidad de datos y la velocidad de conexión que estás viendo, la mejor opción probablemente sea simplemente guardarlos en un disco externo y enviarlos por correo.
O vaya a algún lugar con una conexión decente: 35 GiB con una conexión de 100 Mb/s le llevará menos de una hora.
Para cifrar y firmar el archivo, puede utilizar gpg. Configure un par de claves, cifre el archivo y fírmelo. En el extremo remoto, verifica la firma y la descifra. Esto garantiza la seguridad y la integridad al realizar el transporte a través de un canal que no es de confianza, como el correo o http. Si usa rsync, ssh se encargará de esto por usted.
Respuesta3
Como ha dicho Panther, las opciones no cifradas como FTPo HTTPserían las más rápidas. Sin embargo, si hay algo que prefieres que no sea público en Internet, te recomiendo que utilices un método cifrado. Puede intentar algo como crear una página de inicio de sesión PHP simple (usando una declaración if), instalarla y configurarla nginxpara apacheHTTPS y tener un enlace de descarga al que solo usted pueda acceder. HTTPS debe ser rápido ya que usa compresión y puede usar un programa para axelinstalar ese archivo usando múltiples conexiones.
La respuesta más simple, asumiendo que su conexión a Internet es el cuello de botella, y no la CPU, sería usar SFTPla -Cbandera para habilitar la compresión, aunque como ya la comprimió, la cantidad que se puede comprimir aún más es bastante pequeña. Lo más sencillo es comprimir los archivos nuevamente con un método más eficiente.