rsync por VPN: uma nova tentativa que reutiliza a transferência interrompida

O seu envio bloqueia aos quatro gigabytes de um arquivo de doze gigabytes, e o hábito aprendido com gestores de download diz para premir retomar. O rsync não vai retomar o fluxo TCP, porque esse fluxo desapareceu com a última retransmissão do túnel. O que pode fazer é conservar os bytes que já recebeu e usá-los como base para a tentativa seguinte, o que é outro mecanismo com outro conjunto de regras. As opções que escolher decidem se essa reutilização acontece de todo.

A nova tentativa reconstrói estado, não retoma o fluxo

Quando a sessão SSH cai, no extremo remoto fica apenas o que chegou a ser escrito no disco, e mais nada. Não há token de sessão a que se reconectar nem número de sequência para reproduzir. A execução seguinte abre uma nova ligação, relê a origem e pergunta ao destinatário o que já tem.

É essa última pergunta que explica porque vale a pena guardar um ficheiro parcial. A cópia do destinatário dá ao rsync algo com que comparar, e o algoritmo envia apenas as diferenças que consegue identificar. Continua a ser uma nova transferência de metadados e uma nova passagem pela origem, por isso o tempo poupado é proporcional à parte do ficheiro que coincide, não à distância a que chegou a ligação anterior. Se o destinatário não guardou nada, a tentativa seguinte é uma cópia completa, por muitos gigabytes que a primeira tenha movido.

Decida onde vive o fragmento reutilizável

O comportamento predefinido escreve o ficheiro parcial no caminho de destino, o que torna visível um arquivo escrito a meio sob o nome final. --partial-dir move-o para um diretório à sua escolha, e o manual descreve esse diretório como conservado para ser usado como dados por uma transferência posterior. Um nome relativo é resolvido dentro do diretório de destino, que é exactamente o que quer quando os dois extremos podem ter disposições diferentes.

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

A ordem também importa no destino: o diretório parcial precisa de espaço suficiente para o fragmento, e o volume precisa de espaço suficiente também para o ficheiro concluído. Encher o volume de destino a meio da transferência produz uma falha que parece um problema de rede mas não é, e pode deixar o fragmento conservado truncado. Verifique o espaço livre no anfitrião recetor antes de a execução começar, não depois de falhar. Alguns segundos com df -h pelo mesmo caminho SSH é o teste mais barato possível do plano.

As permissões são uma preocupação menor mas real. Um diretório parcial onde contas alheias podem escrever permite que outra pessoa substitua conteúdo que a sua execução seguinte tratará como já recebido. Mantenha-o na posse da conta de transferência e não o coloque onde outros serviços publicam.

Execute a mesma cópia, não uma mais astuta

A reutilização só se aplica quando a origem e o destino ainda descrevem o mesmo objeto. Mesmo caminho, mesmo nome, mesmo ficheiro. Renomear a origem ou apontar para outro diretório de destino começa uma comparação nova contra nada de útil.

Não acrescente --whole-file à espera do comportamento delta. Essa opção diz ao rsync para copiar o ficheiro inteiro sem a comparação de soma de verificação deslizante, o que é uma escolha razoável numa ligação local rápida e exactamente a errada depois de um envio de longa distância falhado. --inplace também muda a história: escreve diretamente no ficheiro de destino, pelo que uma interrupção deixa um ficheiro que mistura conteúdo antigo e novo sem um fragmento separado onde recuar.

A linha de progresso reporta o progresso agregado da transferência. Não é um sinal de conclusão. Um número que chega aos cem por cento com a ligação ainda aberta significa que os dados foram empurrados, não que o destinatário tenha renomeado, sincronizado ou aceitado algo.

Aceite o objeto apenas quando coincidir

Confirme primeiro o estado de saída e só depois compare o resultado, em vez de confiar na ausência de erros. Uma verificação de tamanho apanha a maioria das transferências truncadas; uma comparação de somas de verificação apanha o resto, e ambas são baratas comparadas com repetir o envio.

Se o arquivo é publicado por um processo a jusante, faça esse processo esperar pelo ficheiro aceite. Um fragmento conservado que aterra num diretório vigiado sob o nome final é apanhado pela análise seguinte, e o erro do consumidor será sobre entrada corrompida e não sobre uma transferência que nunca terminou.

Deixe a origem em paz até o destinatário confirmar. Regenerar o arquivo entre tentativas altera a base de comparação, e a execução seguinte ou transfere quase tudo ou produz um ficheiro que não coincide nem com a origem antiga nem com a nova.

Quando o limite é a ligação, não a opção

A sobrecarga de cabeçalho e protocolo é um custo da transferência, e raramente é a que decide quanto tempo demora um ficheiro grande. O comportamento de reinício conta mais: um método que sobrevive a uma queda sem passos manuais entrega um ficheiro utilizável mais cedo do que um método mais rápido que tem de recomeçar. O armazenamento nos dois extremos e o caminho de autenticação pertencem à mesma comparação.

Compare os caminhos alternativos permitidos com o mesmo ficheiro e o mesmo destino, e anote de onde cada um retoma após uma interrupção. Essa única coluna diz-lhe mais sobre um envio de doze gigabytes por VPN do que qualquer velocidade de ponta medida num teste curto.