Como mover arquivos grandes pela rede sem sofrer

Publicado em 2026-09-12 por frfrand

Por qué copiar 200 GB con el método equivocado tarda el triple, qué hace rsync que scp no puede, y cómo diagnosticar si el cuello está en el disco, la red o la CPU.

Copiar um arquivo de 200 MB não tem ciência. Copiar 200 GB, ou cem mil arquivos pequenos, é outro problema: aparecem interrupções, limites de disco e decisões que mudam o tempo total por um fator de três.

A diferença entre scp e rsync

scp copia. Ponto. Se a conexão for cortada a 90%, você começa do zero. Se o arquivo já estiver do outro lado, ele copia igual.

rsync compara antes de copiar. Vê o que há no destino e transfere apenas o que falta ou mudou. Se for interrompido, retoma de onde parou.

rsync -avzP --partial origem/ servidor:/destino/

As bandeiras, uma por uma:

• a (archive): preserva permissões, datas e links, e baixa recursivamente.
• v (verbose): mostra o que está fazendo.
• z: comprime durante o envio.
• P: mostra progresso e habilita retomar arquivos parciais.

Um detalhe que morde: a barra final da origem importa. Com "origem/" você copia o conteúdo da pasta; sem a barra, copia a pasta inteira dentro do destino. É a causa mais frequente de "ficou uma pasta dentro de outra".

Quando comprimir e quando não

A bandeira de compressão parece grátis e não é: consome CPU nos dois extremos.

• Vale a pena com texto, código, logs, dumps de banco de dados: comprimem muito.
• Não vale a pena com arquivos já comprimidos (vídeo, imagens, zips): a CPU trabalha para não reduzir nada, e se a rede for rápida, a compressão passa a ser o gargalo.

Regra prática: rede lenta e dados comprimíveis, comprima. Rede rápida ou dados já comprimidos, não.

Muitos arquivos pequenos é outro problema

Transferir cem mil arquivos de 10 KB é muito mais lento do que um arquivo de 1 GB, mesmo que o total seja parecido. Cada arquivo envolve metadados, permissões e uma ida e volta.

A solução é empacotar na origem e desempacotar no destino, em um único pipeline:

tar czf - pasta/ | ssh servidor "tar xzf - -C /destino"

Isso cria o pacote na hora, envia via SSH e desempacota do outro lado, sem gravar um arquivo intermediário. Para árvores de muitos arquivos pequenos, a diferença é enorme.

Onde está realmente o gargalo

Antes de culpar a rede, vale olhar, porque na metade dos casos não é a rede:

• O disco. Um disco mecânico gira em torno de 100 a 150 MB/s em leitura sequencial e muito menos com arquivos pequenos. Se sua rede entrega mais que isso, o disco é o limite.
• A CPU. Com compressão ativada e rede rápida, o processador pode ser o gargalo. Isso se nota olhando o uso de CPU durante a transferência.
• A rede. Só aí.

Um experimento que organiza a discussão: rodar a transferência sem compressão e comparar. Se for igual ou mais rápido, a compressão estava atrapalhando.

Dois hábitos que evitam sofrimento

Use tmux. Qualquer transferência de mais de alguns minutos deve rodar dentro de uma sessão do tmux. Se sua conexão cair, o processo continua no servidor e você volta a vê-lo.

Verifique no final. Comparar o tamanho não basta: uma transferência truncada pode coincidir. Comparar o hash sim.

sha256sum arquivo.tar.gz # em ambos os lados

Para dumps de banco de dados e qualquer coisa que você vá precisar a sério, esse passo vale os trinta segundos que custa.