
Chiunque si sia trovato, prima o poi, a dover trasferire grosse quantità di file da un server Linux a un altro (ma vale anche per Mac OS X o qualunque altro UNIX moderno) avrà scoperto l’esistenza di un comando tanto potente quanto semplice da usare: rsync.
Brevemente, rsync – come può suggerire il nome stesso – è un tool per sincronizzare il contenuto di due cartelle sullo stesso computer o su due computer remoti. Si sostituisce in questo senso ai classici ftp ed scp.
Ad esempio, se volessimo sincronizzare la cartella “/var/www/” presente sul nostro PC locale con quella del nostro server Web dedicato, ci basta aprire un terminale e digitare:
rsync -avz /var/www root@indirizzo_ip_server:/var/www
Proprio come scp, rsync richiederà la password di root, ma poi provvederà a fare tutto da solo, con grandissimi vantaggi in termini di affidabilità e prestazioni. I vari flag, davvero parecchi, sono spiegati con la classica dovizia di particolari nella pagina di man e non ha senso farne un elenco qui.
Ciò che ci interessa adesso, perché è un dubbio che prima o poi verrà a chiunque di noi, è “Cosa succede se adesso lancio un rsync? Quali file verranno modificati? Cancellerò qualcosa?”. In particolare, se usiamo spesso l’opzione --delete
potremmo cancellare file o directory importanti, e perciò abbiamo bisogno di sapere prima costa sta per succedere. Certo, --dry-run
, che mostra l’output senza eseguire i cambiamenti, ci da già una buona approssimazione, ma può non bastare.
La soluzione perfetta ce la da un’opzione non molto conosciuta, chiamata --itemize-changes
, che usata in combinazione con --dry-run
fornisce un output di questo tipo:
.d..t..g... ./
.f...p.g... Documento.pdf
.f.....g... Test.txt
.f...p.g... prova.rb
.d.....g... immagini/
.f...p.g... immagini/fiore.jpg
.f...p.g... metadata/.log
.f...p.g... metadata/version.ini
>f+++++++++ Parameter_Usage.txt
Ovvero, per ciascun elemento (file o directory) viene premessa una lista di operazioni che verranno effettuate sullo stesso. Questa lista è conosciuta con l’impronunciabile acronimo YXcstpoguax, e stiamo per scoprirla nel dettaglio:
YXcstpoguax percorso/del/file
|||||||||||
`----------- Il tipo di aggiornamento che verrà effettuato:
|||||||||| <: file trasferito dall'host locale al remoto (inviato)
|||||||||| >: file trasferito dall'host remoto al locale (ricevuto)
|||||||||| c: modifica o creazione locale per l'elemento:
|||||||||| - creazione di una directory
|||||||||| - modifica di un symlink
|||||||||| - ecc...
|||||||||| h: l'elemento è un hard link verso un altro elemento
|||||||||| .: l'elemento non viene aggiornato (potrebbero esserlo alcuni suoi attributi)
|||||||||| *: è presente un messaggio nel resto della riga (ad es. "deleting").
||||||||||
`---------- Il tipo di file:
||||||||| f = file,
||||||||| d = directory,
||||||||| L = symlink,
||||||||| D = device,
||||||||| S file speciale (ad es. named socket, fifo).
|||||||||
`--------- c: checksum differente (per i file normali) oppure
|||||||| valore modificato (per symlink, device, e altri file speciali)
`-------- s: Dimensione differente
`------- t: Orario di modifica differente
`------ p: Permessi differenti
`----- o: Proprietario differente
`---- g: Gruppo differente
`--- u: Riservato per usi futuri
`-- a: Sono cambiate le informazioni sull'ACL
`_ x: Sono cambiati degli attributi estesi
In questo modo sapremo perfettamente quali cambiamenti stiamo per compiere, e lavoreremo meglio e con più tranquillità.