Newsgroup: it.comp.os.linux.sys
Titolo: backup su hd usb

Olà, iniziato bene l'anno ?
Dunque, devo implementare un semplicissimo sistema di back su un HD USB.
Evitiamo i commenti please, questo è quello che ho a disposizione.
Situazione: proliant ML 110 con due dischi in RAID 1 che esporta un 
condivisione samba usata da 3 pc con windows.
Devo quindi backuppare i dati presenti sulla condivisione.
Il backup sostanzialmente deve essere una copia 1:1 della condivisione, 
niente backup incrementali etc, etc..
Pensavo quindi ad un banalissimo rsync -av quoditiano per la "copia" 
mentre una volta alla settimana ci aggiungerei il --delete per fare un 
po' di pulizia sul disco.
Che ne pensate?
Si lo so che è una soluzione un po' accrocchiata ma questo è.
Altra cosa, il disco usb è sempre attaccato e accesso, conviene 
montarlo/smontarlo ogni volta o lo lascio sempre montato ?
Ultima cosa, il disco è partizionato strano; partizione estesa con 
dentro una logica. la partizione utile risulta quindi essere sdc5. Ok 
che il disco è grossino (1TB) ma vale la pena tenerlo così o meglio 
ripartizionarlo in modo da avere una più classica partizione primaria ?
Si, tecnicamente non ci sono differenze ma penso sia meglio partire da 
situazioni più "normali"...
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***


Facebook: Massimo Bacilieri

 situazioni pi� "normali"...
Che fatica ti costa rimuovere le partizioni e creare quindi una sdc1?
Sicuramente una fatica minore di quella sprecata per digitare questo
post.... quindi fallo.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 un cretino ha scritto:
"Il microkernel e' morto da molto tempo ed ancora non lo sa." (cit. Bluff)


Perch�?
LVM ti torna utile quando ti vuoi riservare la possibilit� di aggregare
successivamente altri device sullo stesso volume.
In tutti gli altri casi un VM � assolutamente superfluo.... e questo �
chiaramente uno di quei casi.
In ogni caso questo non � un disco con il quale devi operare in modalit�
"hot", anzi gli stiamo dicendo di tenerlo smontato. Quindi, eventuali
(ed improbabili) operazioni di resize puoi farle in tutta tranquillit�
senza l'ausilio di alcun VM.
O mi sto perdendo qualcosa? ... ma non credo.


 Io lo ripartizionerei creando un Physical Volume LVM
Esagerato ! Attualmente ci sono 46Gb da backuppare, il disco è da 1tb.
Lo pazio libero sui dischi interni è poco superiore ai 400Gb.
Mi pare eccessivo..


 backup..
Dovrei comunque inventarmi qualcosa per la gestione (mount/umount) del 
disco..


 Ciao.
ma LOL anche se non fosse cos�, non vedo cosa potresti fare con LVM su
un disco USB. Fai un volume composto da pi� dischi USB? E quando li
plugghi li inserisci, tutti insieme contemporaneamente? Non aggiungo
altro perch� la persona � tra le pi� suscettibili, per� � una cosa che
non va bene.
Il VM � un layer per astrarre l'hardware. Ma se tu sai che il disco �
sempre uno, e tale rimarr� a che serve un VM?


 all'altro è quello di fare dei pipe con tar -c ... | tar -x
Attenzione, ricordo sempre di controllare quale versione di Tar si sta
utilizzando. Personalmente mi sono ritrovato che GNU Tar distribuito con
Debian fosse compilato senza il supporto alle ACL, che ovviamente a me
serviva (risolto con BSD Tar)
Enrico

 disco..
man rsnapshot
/cmd_preexec
Come vedi non c'è nulla da inventare, solo da imparare e da usare.


 Come vedi non c'è nulla da inventare, solo da imparare e da usare.
Già. Bel modo di passare la domenica :)
Grazie.


 il (u)mount del disco.
Uhmmm. sembra che ci siano dei problemi:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493176
Ho guardato il changelog della 1.3.1 ma non mi pare ci sia nulla a 
riguardo.
e poi questo non mi è mica tanto chiaro:
cmd_preexec and cmd_postexec run immediately before and after the
creation of a snapshot. That means cmd_preexec runs too late to mount
the snapshot root, unmounting in cmd_postexec causes the lazy deletion
to fail (as you saw), and neither command runs when rsnapshot is just
rotating snapshots. You should mount the snapshot root before calling
rsnapshot and unmount it after rsnapshot exits.
A questo punto, per stare sul sicuro, dovrei wrappare rsnapshot _dentro_ 
un mio script.
Hai notizie in merito ?
Ciao.


 
qui non vedo problemi, ma se ti piace di più avere una partizione primaria, 
falla

 un mio script.
Ma perchè non usi autofs, che è pensato apposta per montare i filesystem 
"on access" e smontarli dopo un periodo di inutilizzo?

 perch� dici che � accrocchiata?
boh ma infatti.
come dire: devo cancellare un file. Ho pensato a un banalissimo'rm',
per� mi pare una soluzione accrocchiata :)


 sempre uno, e tale rimarrà a che serve un VM?
Serve perche` ti mette a disposizione anche altre funzionalita`, tipo il
resize a caldo (e.g. creo un LV di 100Gb e gli altri li aggiungo man
mano che mi servono) o gli snapshot. personalmente utilizzerei LVM solo
per la prima funzionalita`
Enrico

 filesystem "on access" e smontarli dopo un periodo di inutilizzo?
Ci avevo pensato. Non ho molto tempo per fare le prove e i problemi che 
ho riportato nell'altro post, si proporrebbero anche con autofs.
Devo comunque implementare una (anche minimale) logica di controllo.
A questo punto, tra montare il disco manualmente e farlo montare ad 
autofs, non c'è praticamente differenza. Anzi, mi sa che farlo 
manualmente offre maggiori garanzie..


Enrico 'Henryx' Bianchi wrote:

Le perplessità mie ma credo anche quelle di Max, sono dovute 
essenzialmente a due fattori:
1) il presupposto era un backup semplice, senza troppi fronzoli
2) il fatto di essere un hd usb.
Ok, un disco è un disco ma come ho detto a Zipman, il giorno che avrò 
bisogno di più spazio, avrò anche bisogno di una soluzione più seria && 
affidabile. Sia per la gestione dei backup a livello software, sia a 
livello hardware.


 livello hardware.
Io sono dell'idea di non chiudersi le porte se non è necessario e non 
complica la vita. In questo caso si tratta solo di dare anche un vgchange 
-ay prima del mount e -an prima del umount. Di contro mi permetterebbe, 
qualora ve ne fosse la necessità, di usare il disco anche per altri scopi 
ovvero, non ultimo per esempio quello di creare un sistema minimale 
assimilabile ad un disaster recovery. :-)


 -ay prima del mount e -an prima del umount
vgchange -an _dopo_ l'umount :)
Comunque, sono d'accordo, in quanto LVM ti permette non solo di non
allocare tutto lo spazio fin da subito, ma anche di gestire
ripartizionamenti al volo in caso di necessita` (mi viene in mente una
partizione temporanea necessaria allo spostamento al volo dei dati). Per
quanto riguarda la rilevazione dei volumi, molto lavoro puo` essere
fatto in automatico da udev
Enrico

 per la prima funzionalita`
Ovviamente so cosa si pu� fare con un LVM.
Enrico il resize a caldo di un disco USB che tutti gli abbiamo
consigliato di tenere smontato, e che lui user� mezz'ora al giorno �
una cosa che fa ridere.


 una cosa che fa ridere.
Nell'altro post mi sono espresso meglio
Enrico

 Nell'altro post mi sono espresso meglio
Dai, dicci che sulla tua chiavetta USB usi Veritas Volume Manager :)
mo' scherzo. Per� non esagerate, eh.
p.s.: eppure uno snapshot settimanale, per avere un backup precedente,
ce lo vedrei pi� di tutto il resto.


 Dai, dicci che sulla tua chiavetta USB usi Veritas Volume Manager :)
Naaa, l'ultima volta che ho usato una chiavetta USB per qualcosa di piu`
serio del trasportare dati l'ho bruciata dopo una settimana ]:)
Enrico

 Devo comunque implementare una (anche minimale) logica di controllo.
questo è l'ultimissimissimissmo dei problemi:
if grep '/blabla' /proc/mount ; then
   rsync xxxxx && umount /blabla
else
   mount /dev/xxx /blabla && rsync xxxxx
fi