Newsgroup: it.comp.os.linux.sys
Titolo: rsync

Ho sempre usato scp per farmi delle copie di backup di una directory su un
server. Ma ora ho scoperto rsync e mi domandavo come funziona. Cioe',
1) se uso rsync copio solo quanto e' stato aggiornato in una data directory
e quindi e' molto piu' efficiente e veloce?
2) Ho letto un poco man rsync, ma in pratica, se voglio farmi una copia di
backup della directory pippo/ basta
rsync -r pippo/ miuse...@server.com:/miopath/
grazie
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 rsync -r pippo/ miuse...@server.com:/miopath/
meglio con queste opzioni: -avz

 fatta tramite algoritmo md5)
per essere precisi ;-)
Rsync  finds  files that need to be transferred using a "quick check" algorithm (by default)
that looks for files that have changed in size or in last-modified time.  Any changes in the
other  preserved  attributes  (as  requested  by  options)  are made on the destination file
directly when the quick check indicates that the file's data does not need to be updated.
    -c, --checksum              skip based on checksum, not mod-time & size
-- 
Never try to teach a pig to sing.
It wastes your time and annoys the pig.



Questo switch può non essere adatto a tutte le situazioni.
Ci sono diverse opzioni di "skip", tra le quali una basata sul timestamp 
che è sicuramente moooolto più veloce.
Quindi: se hai migliaia di file difficilmente userai "-c", piuttosto 
userai "-u".
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 userai "-u".
confermo ... -c l'ho provato una sola volta ... e mai piu' !
;-)


 rsync -r pippo/ miuse...@server.com:/miopath/
Tie`, se lo migliori, mandami una copia:
---------
#!/bin/bash
BAKTG={destinazione}
if test -d ${BAKTG}
then
   CURRBACKUP=`date +%Y%m%d`
   LASTBACKUP=`ls ${BAKTG} | grep -v ${CURRBACKUP} | tail -1`
   for d in /home /etc ... {varie ed eventuali}
   do
     BACKUPLINK=${BAKTG}/${LASTBACKUP}
     BACKUPPATH=${BAKTG}/${CURRBACKUP}
     test -d ${BACKUPPATH} || mkdir -p ${BACKUPPATH}
     rsync -va --exclude=lost+found -delete --delete-after \
               --link-dest=${BACKUPLINK} ${d} ${BACKUPPATH}
   done
else
   echo "No backup media found." 1>&2
fi
--------
bye,
-- 
piergiorgio


Ciao,
ScriptJus 

> userai "-u".
Serve per non sovrascrivere i files trovati piů nuovi nella destinazione.
Per usare l'algoritmo base (quello che guarda date e dimensione) basta non 
mettere -c (utile in caso tu voglia riverificare un intero albero se hai 
dubbi che qualche file si sia corrotto).
Quindi basta il normale -a.
Ciao,
ScriptJus 

 Ps non avevo capito dal man la potenzialità di --link-dest.
Neanche io, un mio collega mi ha "illuminato" di recente.
bye,
-- 
piergiorgio

 LASTBACKUP=`ls ${BAKTG} | grep -v ${CURRBACKUP} | tail -1`
e, oltre a fare meglio, elimini un bug.

 e, oltre a fare meglio, elimini un bug.
Spiega.
bye,
-- 
piergiorgio

 meglio con queste opzioni: -avz
Il parametro -z ha senso su connessioni remote. Se il link è veloce perdi 
più tempo a comprimere/decomprimere che a trasmettere.
Se poi vuoi essere ancora più veloce, e la rete dove passi è tra server e 
server switchata non hubbata (quindi relativamente sicura), puoi permetterti 
anche di non usare ssh per far passare i dati, ma usare invece rsync tramite 
xinetd, evitando l'overhead causato dalla crittografia dei dati.
In questo caso devi editare/creare il file rsyncd.conf, creare un file di 
password, ed aggiungere un altro duepunti al comando.
Se vuoi solo un statistica sulle operazioni effettuate, invece della lista 
di tutte le cose fatte sostituisci -v con --stats.
C'è infine un parametro da aggiungere, fondamentale in base a quello che 
devi fare: --delete.
Di fatti per impostazione predefinita i files che spariscono sulla 
destinazione non vengono cancellati.
Per riassumere:
rsync -a --stats --delete pippo/ miuse...@server.com::risorsa/miopath/
Aggiungo che se usi --backup --backup-dir i files cancellati o le versioni 
precedenti di quelli cancellati li trovi in una cartella x (che con un po di 
codice puoi rinominare prima di rilanciare il comando).
Solo oggi scopro esistere --link-dest che permette in più di creare un 
hard-link a tutti i files non modificati.
In questo caso ti conviene creare un disco con un numero decisamente più 
alto di inodes.
Infine, guardate la pagina resources su 
rsync.samba.org
, ci sono un sacco di 
tool già pronti sviluppati sopra.
Ne cito due:
1) 
http://www.dirvish.org/
Accompaganto da due documenti interssanti: 
http://www.mikerubel.org/computers/rsync_snapshots/
, 
http://wiki.dirvish.org/plugin/attachments/Presentations/2007Sep.pdf
.
2) 
http://backuppc.sourceforge.net/
Ciao,
ScriptJus 

 Spiega.
Dopo gli innumerevoli thread spesi a dire che ls è il 
comando meno indicato per essere usato negli script
e che usarlo in quel modo è MALE, devo ancora spiegare?
In aggiunta a questo,mancano i controlli sulla integrità 
dei dati; non c'è nessuna garanzia che $LASTBACKUP si 
riferisca all'ultimo backup, quello più recente.
Basta che ls non ordini alfabeticamente il suo output
(ricordi? ls è inaffidabile negli script) oppure che 
sia presente una directory estranea, che tutto il tuo
schema di backup va in cerca di donnine allegre.

 schema di backup va in cerca di donnine allegre.
Niente affatto, dato che "rsync" cerca il file
corrispondente, ma se non lo trova (directory
estranea), semplicemente fa la copia.
Ad ogni modo, mi e` poco utile sapere il motivo
per cui, secondo te, quel metodo non va bene.
Mi interesserebbe sapere quale metodo sia piu`
affidabile, o migliore.
In particolare, come fare a trovare l'ultimo backup
fatto, sapendo che hanno un ordine cronologico.
bye,
-- 
piergiorgio

 
me grandissimo distrattone.... il '-u' non crea due copie uguali ma 
lascia inalterata la destinazione se è più nuova.
come hai scritto tu, nella norma si usa '-a'... ed è quello che io uso 
tutti i giorni. 


Piergiorgio Sartor wrote:

Forse riguarda quello che succede se vengono trattati file con spazi o se ls
non ha nessun file da listare e altre condizioni fuori dai casi previsti.

 non ha nessun file da listare e altre condizioni fuori dai casi previsti.
Mah, la directory di backup dovrebbe/potrebbe
essere solo ed esclusivamente per il backup,
contenere solo directory nella forma "yyyymmdd".
Ora, avento questo "constraint", non vedo alcun
problema nell'uso di "ls".
Ovviamente, come scritto inizialmente, se qualcuno
ha dei miglioramenti... li faccia girare!
Una possibilita`, che vedo io, sarebbe quella di
avere una dir speciale, tipo ".backup", contenente
le informazioni necessarie per far funzionare la cosa.
bye,
-- 
piergiorgio

 schema di backup va in cerca di donnine allegre.
Beh, ls e` uno dei comandi storici in unix e linux, esiste da 30 o piu' anni, io 
lo uso negli script da 20 e non mi ha mai rotto le scatole, quindi sinceramente 
credo che "il meno indicato" sia un po' esagerato e che sia il caso di 
focalizzare su altri problemi ben piu' critici o su casi veramente particolari.
Magari cita qualche esempio o caso pratico, anche perche' se non ci si deve piu' 
fidare di ls....
-- 
"Benvenuto nel mondo vero."
Roy Batty

 deve piu' fidare di ls....
Il problema non e` la fiducia o meno in "ls",
bensi` l'alternativa al suo uso in questo caso.
Per esempio, sarebbe meglio usare "find"?
E come?
bye,
-- 
piergiorgio

 previsti.
No e sí.
No perchè nel caso specifico uno spazio nel nome del file
è un problema minore.
Sí perché rappresenta comunque un caso fuori dal previsto
e programmare andando a fiducia è sempre pericoloso ed 
inaccettabile. Trattandosi poi di una script di backup 
non esiste proprio.

 problema nell'uso di "ls".
Rispondo nell'altro post.



Se sai in anticipo che in quella directory ci sono n file, che hanno tutti
nomi nello stesso formato (senza spazi), non e' affatto "andare a fiducia",
ma e' invece scrivere codice conoscendo cio' su cui si va ad operare, e
sapendo cosa si puo' fare e cosa no.

 deve piu' fidare di ls....
Il problema è proprio che il comando ls ha più di quaranta 
anni. Nel tempo sono state fatte talmente tante versioni 
diverse che forse ls è il comando meno portabile che esista.
Di sicuro l'output di ls è quello che presenta le più forti 
variazioni tra una installazione e l'altra.
L'output di ls è sensibile ai vari alias, alle localizzazioni
alle molte variabili di ambiente, alla presenza di accentate
ed all'UNICODE.
Fin qui sono quisquilie, basterebbe usare un comando come:
 
/bin/ls -1 ... | 
e si evitano questi problemi di formattazione.
Mi spiace non funziona. ls è intrinsecamente insicuro.
Leggi qua.
http://wooledge.org:8000/ParsingLs
http://wooledge.org:8000/BashFAQ/099

 E come?
CURRBACKUP=${BACKUPNAME}-$(date +%Y%m%d)
# Se esiste il backup odierno stampa errore ed esci
LASTBACKUP=$(find . -maxdepth 1 -type d \
-name ${BACKUPNAME}-'[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' |
sort -r | head -1)
... 

 E come?
CURRBACKUP=${BACKUPNAME}-$(date +%Y%m%d)
# Se esiste il backup odierno stampa errore ed esci
LASTBACKUP=$(find ${BAKTG} -maxdepth 1 -type d \


 operare, e sapendo cosa si puo' fare e cosa no.
Non sono d'accordo. Programmare in difesa è l'unico modo 
per salvare il culo. Come un pugile che sta sempre in 
guardia non perchè è fico stare in guardia ma perchè sa 
che se abbassa la guardia prende un pugno in faccia.
Ed allora vedi che il pugile porta le mani al volto 
anche nella vita di tutti i giorni perchè è la sua 
/forma/ /mentis/, perchè non può rischiare di non farlo 
quando sale sul quadrato.
Ed allora tu sai che il formato del nome del file è 
fisso e contiene una data allora cerchi un file che
ha quel formato ma non prendi tutti i file buoni e 
non buoni e poi filtri sulla data perchè cosí permetti
a un file estraneo di intrufolarsi.
La differenza sta proprio su sapere cosa si può fare 
e cosa non si può fare. Abbassare la guardia non si 
può fare. Se si dà ad un dato un certo formato si 
deve sfruttare quel formato e trarne vantaggio 
altrimenti è inutile aver dato quel formato.
Poi due parole su ls: serve solo per listare i file
su schermo e non va usato per altro.
Per produrre elenchi di file c'è find ed è molto 
più versatile.
Io ho dato un esempio di come si usa find al posto 
di ls. Volutamente non lo ho fatto perfetto; ha 
ancora problemi per trattare i nomi di file con 
ritorni a capo e caratteri speciali. 
A voi trovare altri errori.

 più versatile.
Stesso discorso: in certe situazioni della versatilita' non te ne fai   
nulla, e' come avere un coltellino svizzero con 200 strumenti quando a te 
ne serve solo uno.


Ma allora puoi anche usare "ls 20*", con tanto di
"--sort" in caso di preoccupazioni.
Tra l'altro quel find ha un problema, risolvibile
ovviamente.
La prima cifra e` sempre e solo "2" e la seconda e`
sempre e` solo "0" (non intendo fare backup oltre
il 2099).
Un altra soluzione sarebbe creare un file, tipo
".lastbackup", nella directory, contenente, appunto,
il nome del l'ultimo backup.
Tutti questi metodi hanno comunque problemi.
Se c'e` la possibilita` di una directory aliena,
allora c'e` anche la possibilita` di confondere
il "find".
bye,
-- 
piergiorgio

 ammessa.
Uhm, stai faccendo degli assunti che potrebbero non
essere corretti al 100%.
Per esempio, il punto di backup potrebbe essere montato
solo ed esclusivamente durante la procedura di backup,
fatta a macchina sconnessa dalla rete, cioe` senza
utenti, per ovvie ragioni.
Quindi l'unica possibilita` di file/directory alieni
e` data da bug nello script.
bye,
-- 
piergiorgio

 più versatile.
Indubbiamente, ma ne vale la pena?
Bisogna stare attenti, anche perche` persino "find"
non e` compatibile con se stesso. Anche se piu`
stabile di ls.
In questo contesto, l'unica soluzione piu` sicura e`
salvare l'informazione sull'ultimo backup in uno o
piu` file.
bye,
-- 
piergiorgio

 ne serve solo uno.
E questo strumento unico, quello più adatto allo scopo, 
quello che è stato progettato solo per questo unico scopo, 
quello che l'antitesi del coltellini svizzero, è find.

 e` data da bug nello script.
Oppure hai usato per errore lo stesso nastro per il 
backup di due macchine molto diverse.
Oppure che ne hai scambiato l'etichetta.
Oppure che tuo figlio ha registrato su quella 
penna le foto della gita scolastica.
Oppure hai dato un comando sbagliato.
Oppure...
Vale la legge di Murphy: Gli errori capitano.
ï¿œ inutile domandarsi quali sono i motivi dell'errore, 
piuttosto cerca di individuarli e di prevenirne gli 
effetti programmando dannosi in modo robusto.

 quello che l'antitesi del coltellini svizzero, è find.
ROTFL (cit.)

> Marco scrisse:
Volevo starmene fuori da questa discussione, ma un consiglio te lo do,
Marco: stai perdendo il tuo tempo.

 effetti programmando dannosi in modo robusto.
In modo *robusto* significa anche *semplice*.
Il fatto di rendere "complesso" il controllo
sulla directory non vuol dire che sia piu`
robusto, perche` potresti introdurre bug a
non finire, proprio per tener conto dei casi
piu` svariati.
Questo e` la base del risk management.
Certo, deve essere robusto, ma si inizia dai
rischi piu` probabili e si continua finche`
si raggiunge un giusto compromesso fra rischi
e benefici.
Tra l'altro, il problema di trovare l'ultimo
punto di backup rimane irrisolto.
bye,
-- 
piergiorgio