Rsync vs SCP: quale comando di copia usare su Linux

Usa rsync per tutto ciò che va oltre la copia veloce una-tantum, e scp quando vuoi solo un file sull’altra macchina adesso. La differenza di fondo: scp ristreama il file intero ogni volta e non ricorda una connessione caduta, mentre rsync confronta sorgente e destinazione, trasferisce solo i blocchi cambiati e riprende una copia interrotta da dove si era fermata. Su un backup grande via una linea instabile è la differenza tra due minuti e ripartire da capo. Entrambi arrivano con OpenSSH su praticamente ogni distribuzione Linux, quindi è una scelta di abitudine, non di installazione — e l’abitudine dovrebbe avere rsync come predefinita. Qui sotto: tabella di confronto secca, differenze di velocità reali, il trucco del resume che scp non può fare e i casi in cui scp resta comunque la risposta giusta.

Qual è la differenza tra rsync e scp?

scp fa una cosa: apre un canale SSH, streamma i byte, chiude. Non ha stato tra un’esecuzione e l’altra, quindi se il trasferimento muore al 90% ricominci da zero.

rsync è uno strumento di sincronizzazione che usa SSH come trasporto. Prima di inviare, costruisce una lista di checksum del file di destinazione (l’algoritmo a delta con rolling checksum) e trasmette solo i blocchi che differiscono. Lancialo due volte e la seconda passata non sposta quasi nulla. Questo rende anche rsync lo strumento naturale per tenere due directory sincronizzate — mettilo in schedulazione e ogni esecuzione copia solo i delta.

Le conseguenze pratiche:

• Interruzioni: rsync riprende; scp riparte da zero col file.
• Copie successive: rsync invia solo le modifiche; scp ritrasmette tutto.
• Cancellazioni: rsync può replicare le cancellazioni con --delete; scp no.
• Filtraggio: rsync ha i pattern --exclude; scp copia tutto ciò che gli punti.
• Dry run: rsync mostra cosa farebbe con --dry-run; scp non offre nulla.

rsync è più veloce di scp?

Per la prima copia di un file grande su un collegamento veloce sono vicini — entrambi saturano SSH, e la passata di checksum aggiunge solo un overhead contenuto. Il divario si apre in tre punti:

1. Molti file piccoli. rsync mette in pipeline l’attraversamento delle directory e può riusare una connessione; le configurazioni scp più vecchie generavano un lavoro per file. Migliaia di file piccoli (una node_modules, un’installazione WordPress) finiscono sensibilmente prima con rsync.
2. Esecuzioni ripetute. Copia un file da 4 GB in cui sono cambiati 50 MB e rsync sposta all’incirca 50 MB; scp ritrasmette 4 GB.
3. Compressione. -z comprime in transito, cosa che aiuta sulle lente linee WAN.

Puoi cronometrare entrambi da te — il comando ha la stessa forma:

# stesso file, stesso server, entrambi via SSH
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

# rilanciali: scp ricopia, rsync verifica e invia ~nulla
time scp bigfile.tar.gz user@server:/tmp/
time rsync -avh --progress bigfile.tar.gz user@server:/tmp/

Se passi la giornata sui server, la velocità di trasferimento è una di quelle cose che vale misurare una volta — allo stesso modo in cui ss batte netstat sugli host trafficati (vedi ss vs netstat: quale comando per le porte Linux).

scp può riprendere un trasferimento interrotto?

No. scp non ha resume; se la connessione cade a 900 MB di 1 GB, ricomincia. È il motivo più citato in ogni dibattito rsync-vs-scp, ed è reale.

Tutto il design di rsync presuppone che il trasferimento a volte si interrompa. L’incantesimo canonico di ripresa:

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

• --partial conserva il file scritto a metà invece di cancellarlo.
• --append-verify riprende accodando, poi verifica via checksum la regione accodata — al sicuro contro un file parziale corrotto, a differenza della vecchia --append pura.
• --progress ti mostra da dove ha ripreso.

Avvolto in un ciclo di retry, è un backup set-and-forget anche su una connessione ostile:

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

Quando conviene usare scp al posto di rsync?

scp resta lo strumento giusto in una manciata di casi:

• Un file piccolo, una volta. Scrivere scp app.conf user@host:/etc/myapp/ è più corto di qualunque invocazione rsync, e non c’è nulla da riprendere.
• rsync manca dall’altra parte. rsync ha bisogno del suo binario su entrambi i lati. Molti container minimali e appliance includono il server SFTP di scp ma non rsync.
• Non vuoi un server rsync esposto. Raro, ma alcuni ambienti bloccano specificamente il demone rsync.

Una sfumatura che vale sapere: il progetto OpenSSH ha deprecato anni fa il protocollo originale di scp, e lo scp moderno in realtà parla SFTP sotto il cofano. Ha corretto un difetto di escape dei percorsi, ma non è cambiato nulla sulle due limitazioni che contano qui — niente resume, niente trasferimento a delta. Il cambio di protocollo non rende scp rsync.

Anche collegato: se la tua domanda è in realtà «rsync vs cp», la risposta specchia questa — cp è l’equivalente solo-locale di scp (niente resume, niente delta, niente attributi se non aggiungi flag), e rsync funziona sia in locale sia da remoto. Per le copie locali una-tantum, cp va bene.

Quali flag di rsync contano di più?

Alla maggior parte della gente basta una riga:

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

Flag	Cosa fa
-a (archive)	Ricorsivo + preserva permessi, orari, gruppo, symlink, device
-v (verbose)	Elenca ciò che trasferisce
-h (human)	Dimensioni leggibili
--partial	Mantiene i file trasferiti parzialmente, così il re-run riprende
--progress	Progresso per file — la cosa che scp non ha mai avuto
-z	Comprime in transito (CPU lente su LAN veloci: saltala)
--delete	Replica anche le cancellazioni — pericolosa, abbinala sempre a un dry run
--dry-run (-n)	Mostra cosa accadrebbe, non cambia nulla

Due abitudini che vale adottare. Primo, dry-run su qualunque cosa con --delete:

rsync -avh --delete --dry-run src/ user@server:/srv/dest/   # controlla
rsync -avh --delete src/ user@server:/srv/dest/             # poi esegui

Secondo, attenzione alla barra finale — /srv/src copia la directory stessa dentro la destinazione, mentre /srv/src/ copia il suo contenuto. Ci casca tutti una volta; rsync avverte persino «no bytes transferred» quando intendevi l’altra forma.

Per una sincronizzazione giornaliera o settimanale, metti rsync in un timer systemd e lascialo copiare solo i delta — il lato journalctl della schedulazione è coperto nel journalctl cheat sheet.

Rsync vs scp: il verdetto

	scp	rsync
Arriva con OpenSSH	Sì	Sì (serve su entrambi i lati)
Riprende i trasferimenti interrotti	No	Sì (--partial)
Trasferimento a delta nei re-run	No	Sì
Preserva permessi/symlink	In parte	Completamente (-a)
Pattern di esclusione	No	--exclude
Dry run	No	--dry-run
Replica le cancellazioni	No	--delete
Adatto a	Copie rapide una-tantum	Backup, sincronizzazioni, alberi grandi

Il predefinito è rsync per i backup, gli alberi grandi, tutto ciò che passa per un collegamento che può cadere e tutto ciò che lancerai più di una volta. Usa scp quando il comando è più corto del pensiero. Se porti via una sola flag, porta --partial — trasforma ogni futura connessione caduta da riavvio in pausa.