Newsgroup: it.comp.os.linux.sys
Titolo: backup grezzo

Ciao a tutti,
per implementare un backup grezzo del mio server pensavo di fare un rsync
della / su un secondo disco.
Oltre alla dir /proc, la dir /dev e la dir di destinazione del backup, cosa
devo esculdere dall'rsync mediante l'opzione --exclude-from ??
Grazie mille
-- 
g4b0, linux user n. 369000
http://gabo.homelinux.com

 devo esculdere dall'rsync mediante l'opzione --exclude-from ??
La dev in genere non conviene escluderla, visto che occupa poco posto e in
caso di restore su altra macchina fa comodo avere una dev già popolata.
Quindi sono da escludere:
/proc
/sys
/tmp
/var/run
/var/lock
/var/tmp
A scelta e se opportuno le seguenti o loro subdir
/var/backups
/var/cache/...
/var/spool/...
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 
Se le copio comunque posso incappare in problemi oppure va tutto liscio?


 devo esculdere dall'rsync mediante l'opzione --exclude-from ??
Le directory /sys e /tmp e molte delle subdirectory di /var.  Se non 
usi udev devi fare il backup anche di /dev
PS ma cosa è un backup grezzo?
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 PS ma cosa è un backup grezzo?
un backup da 'ignorante' :)


 
Ricapitolando, il se lancio il seguente backup.sh funziona?
g4b0@sun:~$ more backup.sh
#!/bin/sh
/usr/bin/rsync -arvu --progress --stats 
--delete --exclude-from=/home/g4b0/not_rsync / /multimedia/bkp
g4b0@sun:~$ more not_rsync
/proc
/sys
/tmp
/var/run
/var/lock
/var/tmp
/mp3
/multimedia
g4b0@sun:~$
E per il restore basta rsyncare al contrario da una live-distro? ecco il mio
fstab:
g4b0@sun:~$ more /etc/fstab
/dev/hda2        swap             swap        defaults         0   0
/dev/hda3        /                reiserfs    defaults         1   1
/dev/hda1        /boot            reiserfs    defaults         1   2
/dev/hdb1        /multimedia      reiserfs    defaults         1   2
/dev/hdc1        /mp3             reiserfs    defaults         1   2
/dev/cdrom       /mnt/cdrom       auto        noauto,owner,ro  0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner     0   0
devpts           /dev/pts         devpts      gid=5,mode=620   0   0
proc             /proc            proc        defaults         0   0


 Se le copio comunque posso incappare in problemi oppure va tutto liscio?
Se le copi occupi inutilmente spazio. Le uniche che creano problemi se
copiate sono la /proc e la /sys.
In ogni caso ti consiglio di usare rsnapshot.


 devo esculdere dall'rsync mediante l'opzione --exclude-from ??
Dipende anche da quel che vuoi fare. Io direi:
/sys, /mnt, eventualmente /media... i cestini...
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
__________________________________
Combatti l'AIDS col tuo computer: 
http://fightaidsathome.scripps.edu/

 /dev/hda3        /                reiserfs    defaults         1   1
Tu ti vuoi male, molto male...
Enrico

 Enrico
-- 
-------------------------------------------------
linux slackware
tutto il resto e' inutile
-------------------------------------------------

 X quale motivo ?
Perché ormai reiserfs è "deprecato", essendo nullo lo sviluppo del ramo 3.x,
con dei problemi riconosciuti che non verranno mai risolti, e l'adozione del
ramo 4.x è assolutamente sconsigliabile per gioventù del prodotto e mancata
inclusione nel kernel.
Non offrendo ormai alcun vantaggio rispetto a ext3 con opzione dir_index
abilitata, né rispetto a XFS o JFS, non si ravvede alcun motivo per usarlo,
specie sul root filesystem


 né rispetto a XFS
Sì, buono questo! Questo sì qualche problemino lo dà, per esperienza
personale.
No, piuttosto: un dump sulla root sarà advvero necessario?
Soprattutto, dump NON funziona con reiserfs (a meno di usare
reiserfsdump, col quale bisogna appunto sostituire dump).


 personale.
Io ho avuto problemi con *tutti* i filesystem. Quindi non è quello il
parametro più indicativo della qualità/affidabilità di un FS


 abilitata, 
Vorrei saperne di più: hai qualche sito/articolo di rivista da
consigliarmi? Non sono riuscito a trovare nulla su Google ;S
Per esempio sarebbe interessante sapere che svantaggi comporta l'uso di
dir_index e se può essere abilitata su una partizione già esistente senza
incorrere in qualche problema.
TIA
-- 
no signature yet

 incorrere in qualche problema.
man tune2fs


 detti precedentemente.
Bah... Io conto meno di tutti, porò resta la mia prima scelta per /.


 kernel non ha speranze.
Senza prendere posizione, solo per curiosità, ecco una delle querelle
in merito: 
http://kerneltrap.org/node/6844


 X quale motivo ?
Tralasciando i motivi detti da ZiPMaN, l'uso di ReiserFS sulla root (e,
probabilmente, anche su /boot) comporta che se hai uno spegnimento sporco
(ovvero un reset), ti ritrovi che per far ripartire il sistema devi per
forza agire tramite una distribuzione live, in quanto il file system si
trova in uno stato inconsistente e GRUB non riesce a mettere alcuna pezza
(cosa che invece non si verifica con ext3). Questa, ovviamente, e` la mia
esperienza
Enrico

 Bah... Io conto meno di tutti, porò resta la mia prima scelta per /.
Guarda, e` proprio per le esperienze da me fatte che evito ReiserFS su /
Enrico

 Bah... Io conto meno di tutti, porò resta la mia prima scelta per /.
Mi associo.
Da valutare ci sarebbe anche l'accoppiata kernel/distro.
Spiego: una o due release fa, avevano tolto da opensuse la possibilità
di utilizzare jfs durante l'installazione perché non avevavo
sviluppatori in grado di metterci mano. Qualcuno che conoscesse _bene_
gli internals di quel fs, quindi non in grado di sistemare eventuali
bug.
In quel caso, scegliere JFS (utility e supporto nel kernel ovviamente
erano presenti..) sarebbe stato IMHO un grosso errore.
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 esperienza
Personalmente concordo e rilancio dicendo che sul rootfs andrebbe sempre
messo il filesystem più stabile, ancorché lento, tra quelli disponibili.
Sul rootfs non vanno fatti grandi accessi, quindi le performance sono
assolutamente secondarie, mentre è importante che sia molto resistente a
corruzioni et simila.


 forza agire tramite una distribuzione live
La boot l'ho sempre fatta separata in ext2, ma ti garantisco che
avere reiserfs sulla root non mi ha mai comportato alcun problema coi
reset (e di spegnimenti sporchi, reset, freeze e chi più ne ha più ne
metta, quando testo gli overclock, ne ho una valanga).


 Enrico
-- 
Ciao.
Alessandro 
"Ubuntu" - an African word, meaning "Slackware is too hard for me".

 Sicuro che il problema non fosse altrove ?
Può essere fosse *anche* altrove, ma perché rischiare inutilmente se la
soluzione è indolore?


 soluzione è indolore?
Beh, direi perché bisogna vedere (ammesso che quella soluzione sia
sempre una soluzione a qui problemi) se comunque tale soluzione non
comporti diversi rischi e diversi possibili problemi.
Per esempio, cercando su 
http://bugzilla.kernel.org/query.cgi
nella sezione filesystem, per ext3 trovo 6 bug aperti, per reiserfs 7
(totali 38 a 41).


 La boot l'ho sempre fatta separata in ext2
Probabilmente e` questo che ti salva
Enrico

 Per fortuna solo la tua. Sicuro che il problema non fosse altrove ?
Considerando che mi capita ogni qualvolta che va via la corrente? No, non
penso che il problema sia altrove
Enrico

Enrico 'Henryx' Bianchi wrote:

Mah, allora non so che dirti, a me e' successo ad esempio anche stamani, un
mio collega ha inavvertitamente spento l'interruttore della 'ciabatta'
delle prese mentre infilava un altra spina, e tutto e' ripartito come se
niente fosse, e comunque non e' certo la prima volta che spengo o resetto
brutalmente, e con reiser mai avuto problemi. Al massimo mi e' accaduto in
passato di dover lanciare manualmente un ckfs, ma all'epoca usavo ext2.
L'unica cosa che ho notato, in special modo sul portatile, e' che un boot
senza aver chiuso correttamente il fs e' piu' lento, perche' immagino
faccia dei check di consistenza in piu'. 


 soluzione è indolore?
Boh, forse perche' se il problema non e' il fs ci sta che si presenti anche
usandone uno diverso... 


 niente fosse
L'unica cosa che mi viene in mente, e` che tu ti trovi in una situazione
tipo quella di Lem Novantotto, ovvero hai /boot separata e formattata con
un altro file system o montata in ro
Enrico

 un altro file system o montata in ro
Il problema che hai tu (incapacità di reboot dopo power loss) è in
effetti ben noto, anche se pare colpire anche altri filesystem,
persino ext3. Solo una minoranza (sfortunata) di utenti, però, pare
ne sia affetta, e generalmente risolve cambiando fs.
Cito da
http://www.linuxquestions.org/questions/slackware-14/reiserfs-with-slackware-and-freebsd-301068/
| one big negative of ext3 over reiserfs is file system corruption if
| power loss occurs. I've had my ext3 partitions damaged multiple
| times with power losses and turning the system down without
| umounting. since i switched to reiserfs i can't get my file system
| messed up no matter what happens.
Altrove leggo:
| Since I started using it, I have never had a crash and on power
| loss rieserfs has repaired every error and continued booting
XFS, per esempio, in caso di crash o power loss è noto per riempire
facilmente di 0 i file aperti (e a me è capitato, ragion per cui io e
XFS ci detestiamo cordialmente): credo sia il fs con cui il problema
del mancato reboot si presenta più spesso.


 del mancato reboot si presenta più spesso.
Aggiungo, durante il beta-testing della opensuse 10.3, al primo
riavvio '/' non veniva smontata perché occupata da non ricordo cosa.
Bene, con XFS la partizione era _persa_.


 un altro file system o montata in ro
Macche', stessa partizione , ovviamente sempre in reiser. Quello che mi fa
pensare a cause diverse e' questa assenza di mezzi toni : a te (e ad altri)
succede sistematicamente, a me (ed altri) invece mai successo. Vabbe', mi
sa che rimarremo con la curiosita'.


Io ho quasi sempre usato reiserfs su / e non ho mai perso dati o visto
particolari tragedie, nonostante svariati spegnimenti bruschi.
Ho sempre però lasciato /boot su ext2, forse è anche grazie a questo.

 | power loss occurs. 
Assolutamentre opinabile. Ci sono dei *fatti* che lo provano? Perche` se 
no sono solo esperienze personali. E se dobbiamo basarci su quelle io, 
ad esempio, in piu` di 10 anni non ho mai visto una partizione ext2/etx3 
perdere dati dopo un crash.
-- 
Vincenzo

 no sono solo esperienze personali.
Intendevo appunto presentare anche quella come tale. Per questo
scrivevo di "minoranze di utenti sfortunati".
Mi spiace non esser stato chiaro.


 fosse controproducente escluderla.
Se usi udev e` inutile backuppare la /dev.
Molto meglio backuppare /dev/.static/dev come /dev, perche` e` la 
versione "statica" di dev, coi device fisicamente creati sul disco, 
mentre la /dev viene gestita dinamicamente da udev, appunto.
Bye.

 mentre la /dev viene gestita dinamicamente da udev, appunto.
Non tutte le distribuzioni (o meglio non tutte le versioni di udev) 
hanno una directory che rappresenta la copia statica sul disco.
Nelle mie macchine (slackware 11.0) la copia statica è nascosta dal 
mount fatta da udev.  Una lista ridotta al minimo per il boot fino 
alla partenza di udevd è presente in /lib/udev/devices
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 alla partenza di udevd è presente in /lib/udev/devices
Anche in openSUSE.
