1 23/04/2026 12/05/2026 7 min

rsync è ancora uno degli strumenti più affidabili per sincronizzare directory locali e remote, ma il suo valore non sta nel “copiare file velocemente”: sta nel farlo in modo verificabile, ripetibile e con un controllo fine su cosa entra, cosa resta fuori e cosa viene rimosso. Per backup operativi, repliche di contenuti web, allineamenti tra ambienti o copie incrementali, resta difficile trovare un’alternativa altrettanto pratica su Linux.

La logica è semplice: rsync confronta sorgente e destinazione, trasferisce solo le differenze e può preservare metadati importanti come permessi, timestamp, link simbolici e, se richiesto, anche ACL e attributi estesi. Questo lo rende molto più adatto di un cp per scenari ricorrenti. Il rovescio della medaglia è noto: alcune opzioni sono potenti al punto da diventare rischiose se usate senza prima verificare il piano di esecuzione.

La regola operativa corretta è sempre la stessa: prima osservi con un test, poi sincronizzi davvero, infine automatizzi. Prima di toccare dati di produzione, conviene chiarire tre aspetti: direzione del flusso, metadati da preservare e livello di rischio accettabile sul target.

Il punto che crea più errori: sorgente, destinazione e slash finale

La sintassi base è questa:

rsync [opzioni] sorgente destinazione

Il dettaglio che confonde più spesso è la barra finale. /path/dir e /path/dir/ non indicano sempre la stessa cosa: con la barra finale sulla sorgente, in genere sincronizzi il contenuto della directory; senza barra, copi anche la directory come contenitore. È una differenza piccola solo in apparenza, perché cambia la struttura finale sul target.

Se vuoi copiare il contenuto di /srv/site/ dentro /backup/site/, usa la sorgente con slash finale. Se invece vuoi ottenere una directory annidata, togli lo slash. Questa distinzione diventa critica quando usi --delete: un path interpretato male può portare a cancellazioni che non volevi.

Sincronizzazione locale: il caso più semplice da fare bene

Per una copia locale affidabile, parti sempre con un dry-run. È il modo più rapido per vedere cosa farebbe rsync senza modificare nulla, quindi è la prima verifica da fare quando stai definendo inclusioni, esclusioni o regole di cancellazione.

rsync -avhn --delete /home/app/data/ /mnt/backup/app-data/

Qui:

  • -a attiva la modalità archivio e preserva permessi, timestamp, link simbolici e altri metadati utili.
  • -v aumenta il dettaglio dell’output.
  • -h rende le dimensioni più leggibili.
  • -n simula l’operazione senza toccare i file.
  • --delete rimuove dalla destinazione ciò che non esiste più nella sorgente.

Nel dry-run cerca sempre tre segnali: file che verrebbero copiati, file che verrebbero ignorati e file che verrebbero cancellati. Se compaiono eliminazioni inattese, il problema di solito non è rsync in sé, ma il path sbagliato, la slash finale o un filtro troppo aggressivo.

Quando il piano ti convince, togli -n e rilancia. Se la directory contiene molti file piccoli, il costo può spostarsi sulla CPU e sulla gestione dei metadati; se invece hai pochi file grandi, il collo di bottiglia tende a diventare I/O o banda. Il vantaggio di rsync cresce proprio negli scenari ripetuti, perché evita di ritrasferire ciò che non è cambiato.

Sincronizzare verso un host remoto via SSH

Nel caso remoto, la scelta standard è SSH. È quasi sempre la soluzione giusta perché non richiede servizi aggiuntivi esposti e usa un canale già cifrato. La forma più comune è questa:

rsync -avh -e ssh /var/www/html/ user@server:/var/www/html/

Il parametro -e ssh dice a rsync di usare SSH come trasporto. Su molte installazioni funziona anche senza specificarlo, ma dichiararlo esplicitamente rende il comando più chiaro e ti permette di aggiungere opzioni SSH in modo controllato.

Se devi usare una porta non standard o una chiave specifica, conviene mettere tutto nel comando o, meglio ancora, in una configurazione SSH dedicata. Esempio:

rsync -avh -e 'ssh -p 2222 -i /home/admin/.ssh/id_ed25519' /var/www/html/ user@server:/var/www/html/

In ambienti gestiti bene, è preferibile usare una chiave dedicata con permessi stretti, invece di riutilizzare chiavi personali. Sul file della chiave, il controllo minimo è banale ma indispensabile:

chmod 600 /home/admin/.ssh/id_ed25519

Se il target è un server remoto usato per backup o replica, verifica anche lato SSH che l’utente abbia solo i permessi necessari sulla destinazione. rsync non sostituisce il principio del privilegio minimo: lo eredita.

Esclusioni: il vero discriminante tra copia utile e copia rumorosa

Le esclusioni sono la parte che rende rsync davvero utile in produzione. Copiare tutto quasi mai è la scelta giusta: cache, file temporanei, log rotanti o directory generate dall’applicazione spesso non devono entrare nella replica.

rsync -avh --dry-run --delete \ --exclude='cache/' \ --exclude='tmp/' \ --exclude='*.log' \ /srv/app/ /backup/app/

Le regole di esclusione vanno sempre testate con --dry-run. Se il filtro non funziona come previsto, il problema può essere nel pattern, nel livello della directory o nel fatto che stai escludendo il nome sbagliato rispetto al punto di partenza. Un’esclusione efficace non è quella “più lunga”, ma quella coerente con la struttura reale dei file.

Se le regole diventano molte, conviene spostarle in un file dedicato con --exclude-from. È più leggibile, più facile da versionare e meno soggetto a errori da shell quoting.

rsync -avh --dry-run --delete --exclude-from=/etc/rsync/app.excludes /srv/app/ /backup/app/

Opzioni utili che vale la pena conoscere

La modalità archivio -a è il punto di partenza, ma non basta sempre. In scenari reali possono servire opzioni aggiuntive, soprattutto quando vuoi preservare più metadati o controllare meglio il comportamento in caso di file speciali.

  • -A preserva le ACL, se supportate dal filesystem.
  • -X preserva gli attributi estesi.
  • -H preserva i link fisici, utile ma più costoso su alberi grandi.
  • --numeric-ids evita traduzioni tra nomi utente e gruppi, utile nei backup tra sistemi diversi.
  • --partial conserva i trasferimenti incompleti, utile su linee instabili.
  • --info=progress2 offre una vista più utile del progresso rispetto al vecchio output di default.

Non tutte le opzioni vanno usate insieme per abitudine. Per esempio, -H e alcuni settaggi di metadati aumentano il costo del confronto; su alberi enormi conviene abilitarli solo se servono davvero. La scelta giusta dipende sempre dal tipo di dato che stai proteggendo.

Verificare prima di automatizzare

Un rsync lanciato a mano può essere abbastanza sicuro; uno schedulato male può diventare un problema serio. Prima di metterlo in cron o in systemd timer, fai tre verifiche: output del dry-run, comportamento su cancellazioni e coerenza delle esclusioni. Se una di queste tre cose non è chiara, non automatizzare ancora.

Per chi vuole un controllo più esplicito, è utile salvare anche il log dell’esecuzione reale. Un esempio semplice:

rsync -avh --delete /srv/app/ /backup/app/ | tee -a /var/log/rsync-app.log

Il log non sostituisce la validazione, ma aiuta quando devi ricostruire cosa è successo in un run precedente. In ambienti con più job, conviene distinguere i log per sorgente o per servizio, così da non perdere il contesto.

Quando rsync non è la scelta giusta

rsync è ottimo per sincronizzare alberi di file, ma non è un sistema di backup completo e non sostituisce uno snapshot a livello di storage o un vero versioning. Se ti serve storico dei cambiamenti, retention granulare o ripristino point-in-time, devi affiancarlo a un meccanismo diverso.

Inoltre, se il dataset è molto volatile o l’applicazione scrive file in continuazione, una sincronizzazione “a caldo” può catturare stati intermedi. In quei casi conviene fermare il servizio, usare snapshot del filesystem o lavorare su una copia consistente. rsync resta valido, ma va inserito nel flusso giusto.

Usato con criterio, rsync è uno strumento preciso: non fa magie, ma fa bene il suo lavoro. Ed è proprio questo il suo pregio maggiore.