On 030706, 14:46, Fabio Muzzi wrote:
> FKB> Domanda di logica più che hardwarosa:
> FKB> ma dei sync al posto di portarsi in giro tar da decine e decine di gb
> FKB> non sono più convenienti?
>
>
> dipende. Se vuoi fare versioning, rsync non va bene (credo, almeno).
Se per versioning intendi uno storico, in se no... ma puoi lavorarci con
gli hard link. Personalmente tengo una dir temporanea .pippo dove synco
giornalmente, finito il sync hardlinko il tutto in una dir
annomesegiorno (poca roba in quanto occupazione di spazio). In caso di
eliminazione di $file in .pippo a seguito del sync con --delete l'hard
link rimane persistente per definizione, in caso di non eliminazione,
nella dir annomesegiorno+1 avrò un ulteriore hardlink senza perdita di
spazio.
Ovviamente, oltre allo spazio, c'è da tener d'occhio anche gli inode per
evitare che finisca la possiblità di hardlinkare :)
> Inoltre, rsync e` efficiente solo se rsync stesso e` installato su
> tutti e due gli host. Se ho un host che vede l'altro come "disco",
> vuoi a mezzo usb2, sata, o samba, rsync si legge comunque tutti i
> files (anche del disco "lento") per decidere se e come
> sincronizzare... ergo a questo punto copiare tutto non fa mica molta
> differenza...
Teoricamente non so come funzioni, praticamente però non mi pare sia così.
Io uso un disco usb esterno dove faccio copia "ogni tanto quando mi
ricordo" dello storico giornaliero visto prima (il quale è organizzato
su un _po'_ di dischi (/me terrorizzato dalla perdita di dati dorme con
disco usb... se va a fuoco il computer coi dischi ho lui, se va a fuoco
anche l'esterno vuol dire che vado a fuoco anche io... onde per cui dei
dati non è che mi interessi granchè)).
Da script monto usb esterno ext3 e poi lancio il sync (analogo
storicioso come sopra)... non ho tanti dati, saranno un 30Gb, pero' nel
giro di un minuto (forse meno) _capisce_ cosa deve fare e poi _fa_...
copiare 30 gb di tar non credo impiegherebbe cosi' poco.
Su un'altra macchina in giro ho un'archivio di un centinaio di giga
backuppato allo stesso modo dove pero' nella settimana che intercorre da
un baco esterno all'altro modificano pochi dati... il
sync+bakcup+storico ci mette una manciata di minuti.
Inoltre, in questo modo, puoi assegnare ad un utente di rete skillato la
possiblità di leggere lo storico e se per caso $segretaria cancella
$file che serve puoi ripercorrere a ritroso nel tempo browsando directory
e semplicemente copioincollare il file erroneamente rimosso senza
scompattare 120 Gb di tar (che io non troverei nessun posto dove
scompattare... :)
Ancora non mi hanno chiamato per dati persi e, personalmente, non ne ho
mai persi in questo modo... (peste, corna, toccata, capriola,
scongiuro)... per la sicurezza non so.. ma non mi pare così insicuro (ma
se qualcuno ha da raccontare tanto mejo :))
In realtà non mi è _mai_ venuto in mente un motivo diverso dal
_risparmio spazio_ per usare tar al posto di sync... risparmiare spazio
ha senso con sistemi in cui il rapporto Prezzo/GB è alto (sistemi scsi
ad esempio) ma se devi stoccare tanti dati e non necessiti di velocità
altissime di trasferimento credo tu possa supporre un rapporto costi/benefici
molto interessante con una batteria di dischi ide/sata il cui costo/GB
è, allo stato attuale ed in continua discesa, molto basso... ovviamente
tutti sappiamo che l'affidabilità dei dischi ide/sata è rapportata alla
quantità di acqua santa con il quale il sistemista benedice il supporto
prima dell' mkfs .... onde per cui, visto il costo, abbondare in
quantita' e sostituire non piu' tardi di 18 mesi anche se sono garantiti
per tre anni, pregando, anche se apparentemente funzionano bene...
Eventualmente usare i sostituiti per stoccare i film xxx del
sistemista...
/me che da quando hai postato il post sul raid non fa più raid 5...
--
.''`. | 22. "Anima le feste...". "Rissa". [la "nimmistica" di Claudio
: :' : | Batta - Zelig]
`. `'` |
`- |
|
|