rsync por VPN: un reintento que reutiliza a transferencia rota

A túa subida atasca nos catro gigaoctetos dun arquivo de doce gigaoctetos, e o hábito aprendido dos xestores de descargas di que premas retomar. rsync non retomará o fluxo TCP, porque ese fluxo foise coa última retransmisión do túnel. O que si pode facer é conservar os bytes que xa recibiu e usalos como base para o seguinte intento, que é outro mecanismo con outro conxunto de regras. Os indicadores que elixas deciden se esa reutilización chega a ocorrer.

O reintento reconstrúe o estado, non retoma o fluxo

Cando a sesión SSH cae, no extremo remoto queda só o que acadou a volcar en disco e nada máis. Non hai testemuño de sesión ao que volver engancharse nin número de secuencia que reproducir. A seguinte execución abre unha conexión nova, volve ler a orixe e pregunta ao receptor que ten xa.

Esa última pregunta explica por que paga a pena conservar un ficheiro parcial. A copia do receptor dálle a rsync algo co que comparar, e o algoritmo envía só as diferenzas que pode identificar. Segue a ser unha transferencia nova de metadatos e unha pasada nova pola orixe, así que o tempo aforrado é proporcional a canto do ficheiro coincide, non a ata onde chegara a conexión anterior. Se o receptor non conservou nada, o seguinte intento é unha copia completa, por moitos gigaoctetos que movera o primeiro.

Decide onde vive o fragmento reutilizable

O comportamento predeterminado escribe o ficheiro parcial na ruta de destino, o que fai visible un arquivo a medio escribir baixo o nome final. --partial-dir móveo a un directorio da túa elección, e o manual describe ese directorio como conservado para usalo como datos nunha transferencia posterior. Un nome relativo resólvese dentro do directorio de destino, que é o que queres cando os dous extremos poden ter disposicións distintas.

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

A orde tamén importa no destino: o directorio parcial necesita espazo suficiente para o fragmento, e o volume necesita espazo suficiente tamén para o ficheiro completo. Encher o volume de destino a metade da transferencia produce un fallo que parece un problema de rede pero non o é, e pode deixar o fragmento conservado truncado. Comproba o espazo libre no host receptor antes de que comece a execución, non despois de que falle. Uns segundos con df -h pola mesma ruta SSH é a proba máis barata posible do plan.

Os permisos son unha preocupación menor pero real. Un directorio parcial no que poden escribir contas alleas permite que outro substitúa contido que a túa seguinte execución tratará como xa recibido. Mantéño en propiedade da conta de transferencia e non o poñas onde publiquen outros servizos.

Executa a mesma copia, non unha máis astuta

A reutilización só se aplica cando a orixe e o destino seguen describindo o mesmo obxecto. Mesma ruta, mesmo nome, mesmo ficheiro. Renomear a orixe ou apuntar a outro directorio de destino comeza unha comparación nova contra nada útil.

Non engadas --whole-file esperando o comportamento delta. Esa opción dille a rsync que copie o ficheiro enteiro sen a comparación de suma de verificación deslizante, o que é unha escolla razoable nunha ligazón local rápida e exactamente a equivocada tras unha subida de longa distancia fallida. --inplace tamén cambia a historia: escribe directamente no ficheiro de destino, así que unha interrupción deixa un ficheiro que mestura contido vello e novo sen un fragmento separado ao que recorrer.

A liña de progreso informa do progreso agregado da transferencia. Non é un sinal de finalización. Un número que chega ao cen por cento mentres a conexión segue aberta significa que os datos se empuxaron, non que o receptor renomease, sincronizase ou aceptase algo.

Acepta o obxecto só cando coincida

Confirma primeiro o estado de saída e logo compara o resultado en lugar de fiarte da ausencia de erros. Unha comprobación de tamaño atrapa a maioría das transferencias truncadas; unha comparación de sumas de verificación atrapa o resto, e ambas son baratas comparadas con volver executar a subida.

Se o arquivo o publica un proceso posterior, fai que ese proceso espere o ficheiro aceptado. Un fragmento conservado que aterra nun directorio vixiado baixo o nome final cólloo o seguinte varrido, e o erro do consumidor será sobre entrada corrupta e non sobre unha transferencia que nunca rematou.

Non toques a orixe ata que o destinatario confirme. Rexenerar o arquivo entre intentos cambia a base de comparación, e a seguinte execución ou ben transfire case todo ou ben produce un ficheiro que non coincide nin coa orixe vella nin coa nova.

Cando o límite é a ligazón, non o indicador

A sobrecarga de cabeceira e protocolo é un custo da transferencia, e raramente é a que decide canto tarda un ficheiro grande. O comportamento de reinicio importa máis: un método que sobrevive a unha caída sen pasos manuais entrega un ficheiro utilizábel antes que un método máis rápido que ten que comezar de novo. O almacenamento nos dous extremos e a ruta de autenticación pertencen á mesma comparación.

Compara as rutas alternativas permitidas co mesmo ficheiro e o mesmo destino, e anota desde onde retoma cada unha tras unha interrupción. Esa única columna diche máis sobre unha subida de doce gigaoctetos por VPN que calquera velocidade punta medida nunha proba curta.