rsync por VPN: un reintento que reutiliza la transferencia rota

Tu subida se atasca en cuatro gigabytes de un archivo de doce gigabytes, y la costumbre aprendida de los gestores de descargas dice que pulses reanudar. rsync no reanudará el flujo TCP, porque ese flujo se fue con la última retransmisión del túnel. Lo que sí puede hacer es conservar los bytes que ya recibió y usarlos como base para el siguiente intento, que es otro mecanismo con otro conjunto de reglas. Los indicadores que elijas deciden si esa reutilización ocurre siquiera.

El reintento reconstruye el estado, no reanuda el flujo

Cuando la sesión SSH se cae, en el extremo remoto queda solo lo que alcanzó a volcar en disco y nada más. No hay testigo de sesión al que volver a engancharse ni número de secuencia que reproducir. La siguiente ejecución abre una conexión nueva, vuelve a leer el origen y pregunta al receptor qué tiene ya.

Esa última pregunta explica por qué merece la pena conservar un archivo parcial. La copia del receptor da a rsync algo con lo que comparar, y el algoritmo envía solo las diferencias que puede identificar. Sigue siendo una transferencia nueva de metadatos y una pasada nueva por el origen, así que el tiempo ahorrado es proporcional a cuánto del archivo coincide, no a lo lejos que había llegado la conexión anterior. Si el receptor no conservó nada, el siguiente intento es una copia completa, por muchos gigabytes que haya movido el primero.

Decide dónde vive el fragmento reutilizable

El comportamiento predeterminado escribe el archivo parcial en la ruta de destino, lo que hace visible un archivo a medio escribir bajo el nombre final. --partial-dir lo mueve a un directorio que elijas, y el manual describe ese directorio como conservado para usarlo como datos en una transferencia posterior. Un nombre relativo se resuelve dentro del directorio de destino, que es lo que quieres cuando los dos extremos pueden tener disposiciones distintas.

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

El orden también importa en el destino: el directorio parcial necesita espacio suficiente para el fragmento, y el volumen necesita espacio suficiente también para el archivo completo. Llenar el volumen de destino a mitad de la transferencia produce un fallo que parece un problema de red pero no lo es, y puede dejar el fragmento conservado truncado. Comprueba el espacio libre en el host receptor antes de que empiece la ejecución, no después de que falle. Unos segundos con df -h por la misma ruta SSH es la prueba más barata posible del plan.

Los permisos son una preocupación menor pero real. Un directorio parcial en el que pueden escribir cuentas ajenas permite que otro sustituya contenido que tu siguiente ejecución tratará como ya recibido. Mantenlo en propiedad de la cuenta de transferencia y no lo pongas donde publiquen otros servicios.

Ejecuta la misma copia, no una más astuta

La reutilización solo se aplica cuando el origen y el destino siguen describiendo el mismo objeto. Misma ruta, mismo nombre, mismo archivo. Renombrar el origen o apuntar a otro directorio de destino inicia una comparación nueva contra nada útil.

No añadas --whole-file esperando el comportamiento delta. Esa opción le dice a rsync que copie el archivo entero sin la comparación de suma de comprobación deslizante, lo que es una elección razonable en un enlace local rápido y exactamente la equivocada tras una subida de larga distancia fallida. --inplace también cambia la historia: escribe directamente en el archivo de destino, así que una interrupción deja un archivo que mezcla contenido viejo y nuevo sin un fragmento separado al que recurrir.

La línea de progreso informa del progreso agregado de la transferencia. No es una señal de finalización. Un número que llega al cien por cien mientras la conexión sigue abierta significa que los datos se han empujado, no que el receptor haya renombrado, sincronizado o aceptado algo.

Acepta el objeto solo cuando coincida

Confirma primero el estado de salida y luego compara el resultado en lugar de fiarte de la ausencia de errores. Una comprobación de tamaño atrapa la mayoría de las transferencias truncadas; una comparación de sumas de comprobación atrapa el resto, y ambas son baratas comparadas con volver a ejecutar la subida.

Si el archivo lo publica un proceso posterior, haz que ese proceso espere al archivo aceptado. Un fragmento conservado que aterriza en un directorio vigilado bajo el nombre final lo recoge el siguiente escaneo, y el error del consumidor será sobre entrada corrupta y no sobre una transferencia que nunca terminó.

No toques el origen hasta que el destinatario confirme. Regenerar el archivo entre intentos cambia la base de comparación, y la siguiente ejecución o bien transfiere casi todo o bien produce un archivo que no coincide ni con el origen viejo ni con el nuevo.

Cuando el límite es el enlace, no el indicador

La sobrecarga de cabecera y protocolo es un coste de la transferencia, y rara vez es la que decide cuánto tarda un archivo grande. El comportamiento de reinicio importa más: un método que sobrevive a una caída sin pasos manuales entrega un archivo utilizable antes que un método más rápido que tiene que empezar de nuevo. El almacenamiento en ambos extremos y la ruta de autenticación pertenecen a la misma comparación.

Compara las rutas alternativas permitidas con el mismo archivo y el mismo destino, y anota desde dónde reanuda cada una tras una interrupción. Esa única columna te dice más sobre una subida de doce gigabytes por VPN que cualquier velocidad punta medida en una prueba corta.