Rsync vs SCP: qual comando de cópia usar no Linux

Use rsync para qualquer coisa maior que uma cópia rápida pontual, e scp quando você só quer um arquivo em outra máquina agora. A diferença central: o scp reenvia o arquivo inteiro toda vez e não guarda memória de conexão caída, enquanto o rsync compara origem e destino, transfere só os blocos que mudaram e retoma uma cópia interrompida de onde parou. Num backup grande por um link instável, é a diferença entre dois minutos e começar do zero. Os dois vêm com o OpenSSH em praticamente toda distribuição Linux, então é uma escolha de hábito, não de instalação — e o hábito deve ter o rsync como padrão. Abaixo: tabela de comparação direta, diferenças reais de velocidade, o truque de retomada que o scp não tem e os casos em que o scp ainda é a resposta certa.

Qual é a diferença entre rsync e scp?

O scp faz uma coisa: abre um canal SSH, faz streaming dos bytes, fecha. Ele não guarda estado entre execuções, então se a transferência morre a 90% você recomeça do zero.

O rsync é uma ferramenta de sincronização que por acaso usa SSH como transporte. Antes de enviar, ele constrói uma lista de checksums do arquivo de destino (o algoritmo de delta de rolling checksum) e transmite só os blocos diferentes. Rode o mesmo comando duas vezes e a segunda passada quase não move nada. Isso também faz do rsync a ferramenta natural para manter dois diretórios em sync — agende-o e cada execução copia só os deltas.

As consequências práticas:

• Interrupções: o rsync retoma; o scp recomeça o arquivo.
• Segunda cópia: o rsync envia só as mudanças; o scp reenvia tudo.
• Deleções: o rsync espelha deleções com --delete; o scp não consegue.
• Filtragem: o rsync tem padrões --exclude; o scp copia tudo que você apontar.
• Dry run: o rsync mostra o que faria com --dry-run; o scp não oferece nada.

O rsync é mais rápido que o scp?

Para a primeira cópia de um arquivo grande por um link rápido, os dois ficam próximos — ambos saturam o SSH, e a passada de checksums adiciona pouco overhead. A diferença abre em três lugares:

1. Muitos arquivos pequenos. O rsync encadeia a varredura de diretórios e reutiliza uma conexão; setups antigos de scp abriam trabalho por arquivo. Milhares de arquivinhos (um node_modules, um WordPress) terminam visivelmente mais rápido com rsync.
2. Re-execuções. Copie um arquivo de 4 GB em que 50 MB mudaram e o rsync move cerca de 50 MB; o scp move os 4 GB de novo.
3. Compressão. O -z comprime em trânsito, o que ajuda em links WAN lentos.

Você pode cronometrar os dois — o comando é idêntico na forma:

# mesmo arquivo, mesmo servidor, ambos por SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# rode de novo: o scp recopia, o rsync verifica e quase não envia nada
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

Se você vive em servidores, velocidade de transferência é daquelas coisas que valem uma medição única — do mesmo jeito que o ss ganha do netstat em hosts ocupados (veja ss vs netstat: qual comando de porta usar no Linux).

O scp retoma uma transferência interrompida?

Não. O scp não tem retomada; se a conexão cai com 900 MB de 1 GB transferidos, você começa de novo. Essa é a razão mais citada em todo debate rsync-vs-scp, e ela é real.

Todo o design do rsync assume que a transferência vai ser interrompida às vezes. A invocação canônica da retomada:

rsync -avh --partial --append-verify --progress bigfile.tar.gz user@server:/srv/backup/

• --partial mantém o arquivo escrito pela metade em vez de apagá-lo.
• --append-verify retoma anexando e depois verifica por checksum a região anexada — seguro contra um arquivo parcial corrompido, ao contrário do antigo --append puro.
• --progress mostra onde ele retomou.

Envolvido num loop de retry, isso é backup configure-e-esqueça até numa conexão hostil:

until rsync -avh --partial --append-verify --progress 
    ./bigfile.tar.gz user@server:/srv/backup/; do
  sleep 5
done

Quando usar scp em vez de rsync?

O scp segue sendo a ferramenta certa em meia dúzia de casos:

• Um arquivo pequeno, uma vez. Digitar scp app.conf user@host:/etc/myapp/ é mais curto que qualquer invocação de rsync, e não há nada a retomar.
• O rsync não existe no outro lado. O rsync precisa do binário dele nos dois lados. Muitos containers mínimos e appliances trazem o servidor SFTP do scp mas não o rsync.
• Você não quer um servidor rsync exposto. Raro, mas alguns ambientes travam especificamente o daemon rsync.

Uma sutileza que vale conhecer: o projeto OpenSSH descontinuou o protocolo original do scp há anos, e o scp moderno na verdade fala SFTP por baixo. Isso consertou uma peculiaridade de escape de caminho, mas não mudou nada nas duas limitações que importam aqui — sem retomada, sem transferência delta. A troca de protocolo não transforma o scp em rsync.

Relacionado: se a sua pergunta é na verdade “rsync vs cp”, a resposta espelha esta — o cp é o equivalente local-only do scp (sem retomada, sem delta, sem atributos a menos que você adicione flags), e o rsync serve tanto para local quanto para remoto. Para cópias locais pontuais, o cp resolve.

Quais flags do rsync importam mais?

A maioria das pessoas precisa de uma linha só:

rsync -avh --partial --progress src/ user@server:/srv/dest/

Flag	O que faz
-a (archive)	Recursivo + preserva permissões, datas, grupo, symlinks, devices
-v (verbose)	Lista o que transfere
-h (human)	Tamanhos legíveis para humanos
--partial	Mantém arquivos parcialmente transferidos, para uma nova execução retomar
--progress	Progresso por arquivo — a coisa que o scp nunca teve
-z	Comprime em trânsito (CPU lenta em LAN rápida: pule)
--delete	Espelha deleções também — perigoso, sempre acompanhe de um dry run
--dry-run (-n)	Mostra o que aconteceria, sem mudar nada

Dois hábitos que valem adotar. Primeiro, dry run em qualquer comando com --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # revise
rsync -avh --delete src/ user@server:/srv/dest/             # depois execute

Segundo, atenção à barra final — /srv/src copia o diretório em si para dentro do destino, enquanto /srv/src/ copia o conteúdo dele. Isso derruba todo mundo uma vez; o rsync chega a avisar “no bytes transferred” quando você quis a outra forma.

Para um sync diário ou semanal, coloque o rsync num timer systemd e deixe-o copiar só os deltas — o lado de agendamento pelo journalctl está coberto no cheat sheet de journalctl.

Rsync vs scp: o veredito

	scp	rsync
Vem com o OpenSSH	Sim	Sim (precisa nos dois lados)
Retomar transferência interrompida	Não	Sim (--partial)
Transferência delta em re-execuções	Não	Sim
Preservar permissões/symlinks	Parcialmente	Totalmente (-a)
Padrões de exclusão	Não	--exclude
Dry run	Não	--dry-run
Espelhar deleções	Não	--delete
Melhor para	Cópias rápidas pontuais	Backups, syncs, árvores grandes

Prefira rsync para backups, árvores grandes, qualquer coisa por um link que pode cair e qualquer comando que você vai rodar mais de uma vez. Use scp quando o comando é mais curto que o pensamento. Se você levar uma flag daqui, que seja --partial — ela transforma toda conexão futura que cair de reinício em pausa.