ONLINE netcat - oppure - mirrordir.. ma anche ndmpcopy.. il tempo di copia ovviamente nn cambia o cambia in modo percentualmente minimo.
OFFLINE backup e restore.. se la copia la dovrai eseguire con cadenze regolari allora pensa a qualcosa di piu' consolidato, ad es replica via mogileFS o qualche altro sistema replica oriented... ciao Enrico 2011/12/22 Giovanni <[email protected]> > 8 Mb = 1 Megabite al secondo > > Se e' cosi ti ci vogliono 17 gg. > > A quel punto come ha detto Marco, copiare, *criptare* il contenuto, e > inviare per via aerea un hd sarebbe probabilmente piu' veloce. > > Cmq per prova una copia con rsync di solo un paio di file la farei. Giusto > per vedere la differenza. > > > g > > > > Il giorno 22 dicembre 2011 15:18, Pietro Pau <[email protected]> ha > scritto: > > >> Non posso entrare nel dettaglio ma non è uno scherzo, è roba da far >> impazzire.... credimi sulla parola. >> >> Siamo in LAN aziendale, i file da 500 mb sono prodotti ogni 5 minuti e >> devono essere salvati per almeno 5 anni (non tutti sono da salvare ma >> almeno 10/20 GB al giorno), il problema è che ho una FIFO di 6 mesi, per >> ora ho un server dove storicizzare i dati è un distante ma la soluzione è >> temporanea. >> Con scp la velocità media è stata di 8 Mb/s, la prossima settimana provo >> con rsync, ora guardavo scp2 che con l’opzione –u (cancella i file dalla >> cartella sorgente). >> >> p.s. i file sono binari per risparmiare spazio :-) >> >> ciao, >> Pietro >> >> >> Il giorno 22 dicembre 2011 15:07, Marco Marongiu <[email protected]>ha >> scritto: >> >> On 22/12/11 14:47, Paolo De Michele wrote: >>> > rsync sicuramente la soluzione migliore per tenere tutto sincronizzato >>> >>> Rimango dell'idea che, a seconda della velocità di trasferimento, >>> l'opzione disco + aereo sia valida. Non condivido su rsync, del quale >>> sono e resto un fan. >>> >>> Se i file sono molti e in una struttura molto articolata, rsync perderà >>> un sacco di tempo a esplorare l'albero per decidere poi che deve >>> trasferire tutto. >>> >>> Inoltre, il trasferimento rimarrebbe comunque troppo lento. La >>> crittografia dei dati in transito è una bella cosa, ma dal punto di >>> vista della velocità di trasferimento dati è una grossa palla al piede. >>> >>> Forse, qualcosa potrebbe essere guadagnato passando su una VPN che >>> inserisca la crittografia allo strato più basso possibile, e su quella >>> usare un protocollo in chiaro. E, ovviamente, si fa compressione in >>> transito. >>> >>> Infine, se puoi partizionare i dati, ti suggerirei di sfruttare al >>> massimo la banda usando più processi paralleli, ciascuno a copiare una >>> partizione dei dati. >>> >>> Ciao >>> -- bronto >>> _______________________________________________ >>> Gulchelp mailing list >>> [email protected] >>> http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp >>> >> >> >> _______________________________________________ >> Gulchelp mailing list >> [email protected] >> http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp >> >> > > _______________________________________________ > Gulchelp mailing list > [email protected] > http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp > > -- Le password? meglio non usarle ma, se usate, andrebbero ciclicamente rigenerate! Rigenerare gli utenti invece, per quanto possibile, sarebbe alquanto fastidioso! Chi rinuncia a libertà fondamentali per ottenere una fittizia sicurezza, non merita nè la libertà nè la sicurezza. (Benjamin Franklin)
_______________________________________________ Gulchelp mailing list [email protected] http://www.gulch.crs4.it/cgi-bin/mailman/listinfo/gulchelp
