Como Rastrear uma Transferência de Ficheiro Remota que Falha Sempre no Mesmo Tamanho de Ficheiro

Uma transferência que falha repetidamente no mesmo número de bytes geralmente atinge um limite determinístico ou uma etapa pós-transferência, em vez de perda aleatória de pacotes.

Para um NAS remoto ou serviço de ficheiros auto-hospedado, o ponto de falha visível pode vir do sistema de ficheiros de destino, espaço livre ou aplicação de quotas, um limite de upload da aplicação, um proxy reverso, um contador cliente de 32 bits, uma duração fixa da ligação ou processamento de soma de verificação após a chegada da carga útil. O diagnóstico mais rápido regista o deslocamento exato em bytes e o tempo decorrido, depois altera o tamanho do ficheiro, a velocidade de transferência, o protocolo e o destino uma variável de cada vez.

Registe o Deslocamento Exato em Bytes e a Fase da Falha

Execute a mesma transferência duas vezes e registe o tamanho da origem, bytes transferidos, percentagem, tempo decorrido, erro do cliente, erro do servidor e se permanece um ficheiro parcial. Distinga falha durante a transferência da carga útil de falha durante renomeação, soma de verificação, confirmação, indexação ou confirmação final da API.

Um caso de suporte WinSCP falhou repetidamente aos 4 GB até o utilizador identificar um limite de tamanho de ficheiro FAT32. O limite exato em bytes revelou uma restrição de armazenamento em vez de um problema de encaminhamento SFTP ou SCP.

Se a contagem de bytes for idêntica dentro de uma pequena margem, priorize limites fixos e limites inteiros. Se o tempo decorrido for idêntico mas a contagem de bytes variar com a velocidade de transferência, priorize tempos limite de ligação, proxy, inatividade ou autenticação.

Altere a Velocidade de Transferência para Separar Tamanho do Tempo

Transfira o mesmo ficheiro uma vez pelo caminho remoto normal e outra vez por um caminho deliberadamente mais lento ou mais rápido. Registe se a falha ocorre no mesmo número de bytes ou na mesma duração.

Uma discussão na API do Dropbox descobriu que ficheiros que pareciam falhar acima de 4 GB podiam refletir um tempo limite de pedido HTTP, e sugeriu downloads parciais baseados em intervalos para evitar um pedido longo.

Quando a contagem de bytes varia mas o tempo decorrido permanece estável, inspecione a duração da sessão do túnel, tempo limite de leitura do proxy, tokens expirados e deteção de inatividade. Quando a falha permanece num valor exato de bytes apesar de uma grande alteração de velocidade, continue com limites do sistema de ficheiros, quota, cliente e aplicação.

Teste Vários Ficheiros em Torno do Limite Suspeito

Crie ou selecione ficheiros logo abaixo, exatamente no e logo acima do tamanho que falha. Teste também um ficheiro diferente com o mesmo tamanho para que conteúdo, nome do ficheiro, compressão e metadados não se tornem variáveis ocultas.

Um relatório no fórum FlashFXP descreveu uma transferência FTP que parou exatamente em 4,00 GB. Limites em potências de dois como 2 GB, 4 GB ou 8 GB frequentemente indicam um limite de contador, sistema de ficheiros ou aplicação.

Se todos os ficheiros acima do limite falharem, inspecione limites rígidos. Se apenas um ficheiro falhar, compare comprimento do caminho, caracteres do nome do ficheiro, regiões esparsas, permissões, erros de leitura da origem e se o processamento do lado do servidor trata esse tipo de ficheiro de forma diferente.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique o Sistema de Ficheiros de Destino, Quota e Espaço Temporário

Identifique o sistema de ficheiros que contém o ficheiro final e o sistema de ficheiros que contém os uploads temporários. Verifique o tamanho máximo do ficheiro, bytes livres, inodes livres, quota do utilizador, quota do conjunto de dados, capacidade do volume do contentor e qualquer partição de preparação.

Um serviço remoto pode aceitar todo o fluxo numa localização temporária e falhar apenas quando move ou confirma o ficheiro. Isso produz um erro do cliente perto dos 100% mesmo que o caminho de rede tenha entregue quase todos os bytes.

Transfira o mesmo ficheiro para outro compartilhamento ou conjunto de dados no mesmo NAS. Se o limite seguir o destino, corrija o seu sistema de ficheiros, quota ou espaço de preparação; se seguir o cliente ou protocolo entre destinos, continue fora da camada de armazenamento.

Contorne a Aplicação, Proxy ou Túnel Uma Camada de Cada Vez

Compare o fluxo remoto normal com um teste direto do protocolo: SFTP em vez de upload web, acesso VPN direto em vez de proxy reverso público, ou uma transferência LAN local em vez do túnel remoto. Preserve o mesmo armazenamento de origem e destino.

Um utilizador do rclone descobriu que uploads grandes reiniciavam repetidamente após uma longa pausa até alterar o tempo limite, enquanto o servidor parecia realizar trabalho de soma de verificação pós-upload. Isto ilustra porque uma falha no final do mesmo ficheiro nem sempre é um limite de bytes.

Se o SFTP direto tiver sucesso enquanto o caminho web falhar, inspecione limites de upload da aplicação e proxy. Se a transferência local tiver sucesso mas todos os protocolos remotos falharem no mesmo tempo decorrido, inspecione o túnel, caminho ISP, duração da sessão e middleboxes.

Valide a Correção com Testes de Retoma e Soma de Verificação

Após corrigir o limite suspeito, repita ficheiros abaixo e acima do antigo limite. Teste se o protocolo retoma uma transferência interrompida deliberadamente e se o hash final do ficheiro corresponde à origem.

O fluxo de trabalho ZimaSpace para preparar grandes transferências NAS oferece uma forma mais segura de retestar sem reiniciar um trabalho de vários terabytes do zero.

O diagnóstico está completo apenas quando o antigo limite é ultrapassado repetidamente, o servidor confirma o ficheiro, a soma de verificação corresponde e os registos identificam a camada corrigida. Não aceite tentativas automáticas que ocultem uma falha determinística e desperdicem largura de banda silenciosamente.