Newsgroup: it.comp.os.linux.software
Titolo: Backup alternativo a tar

Buongiorno, avrei bisogno di un consiglio: per il backup di un server 
dati ho sempre usato tar, inviando i backup su usb e anche tramite scp 
su un altro server; ora nel reinstallare il server per aggiornare il 
sistema ho usato per il ripristino l'ultimo file di backup, il risultato 
è stato che mancava circa la metà dei dati.
Fortunatamente avevo fatto alcune copie manuali prima della 
formattazione dei dischi, sicuramente indagherò sul perchè è accaduto, 
ma ora cerco un sistema di backup non complicato ma che mi segnali 
eventuali errori tramite email e che faccia un controllo di 
corrispondenza dei dati al backup.
Il comando che ho sempre usato è il seguente:
tar cvfz /pippo/$(date +"%Y-%m-%d").tar.gz /home /etc /var/log /var/mail
In pratica mi interessa solo che crei un file con la data del giorno.
Grazie
Saluti
Fabio

 
google -> backup script linux example -> "mi sento fortunato"
ne troverai almeno un milione
S.

 è stato che mancava circa la metà dei dati.
Il problema, secondo me, non e` dovuto tar, ma a come esegui il backup. 
Controlla bene il tuo script, per me ha dei problemi che gli fanno sscartare 
dei dati. Controlla anche la mail di root (o dell'utente a cui la rigiri), 
in quanto cron ha il vizio di rigirare lo stdout e lo stderr in mail 
all'amministratore
Enrico

 
Può darsi che tu abbia tentato di archiviare file che sono stati
modificati durante la lettura.
Come alternativa, nel migliore dei casi, troverai solo cose all'incirca
analoghe, e che falliranno anche più di tar.
Fidati: ho fatto prove di tutti i tipi, con tanti e tanti tool.
Devo dire che ultimamente mi è piaciuto un tool (per la verità ancora un
po' in erba) fatto sulla falsa riga di Veritas NetBackup che si
chiama: BAR
Però è overkilled e per quello che devi fare tu va bene tar.
-- 
Wikipedia Admin: "wikipedia non è un blog"
Iosif Stalin: "i compagni hanno scambiato il partito per un circolo di
discussione"

 S.
Non cerco script, ma consigli su quale software usare, grazie comunque.
Ciao

 Enrico
Grazie del consiglio, adesso purtroppo il sistema non esiste più, ma ho 
l'immagine del disco fatta subito prima della reinstallazione e proverò 
a recuperarla in un sistema virtuale, giusto per studiare cosa è andato 
storto.
Forse l'errore è stato di fargli fare il backup dei log anche se 
venivano continuamente modificati, ma non ne sono molto convinto.
In pratica nel ripristino mi sono trovato una cartella (non dei log) al 
posto di un file e dentro c'era la root dei file da ripristinare (vedevo 
/etc /home /var/log); in pratica avevo /home/fabio/pluto.xls (pluto in 
realtà era un nome molto lungo) che invece di un file era diventato una 
cartella.
La fortuna, e un po' di prudenza (dischi sas in raid 1 + spare), ha 
fatto si che non accadesse nulla fino ad ora, ma se fosse accaduto 
qualcosa avrei perso quasi tutto, non oso pensarci :-(
Ciao e grazie
Fabio

 Però è overkilled e per quello che devi fare tu va bene tar.
Grazie del consiglio, come copia di emergenza cosa mi consigli? Vado con 
un brutale "cp" su usb?
Ormai, anche se l'errore quasi sicuramente è mio, non riesco più a 
fidarmi di "tar", continuerò ad usarlo ma con qualche timore.
Ciao
Fabio

 con un brutale "cp" su usb?
vedo che molti usano rsync. E se l'USB fosse un collo di bottiglia
potresti provare ad usare lo switch -z per attivare la compressione dei
dati che vengono trasferiti. 


 dati che vengono trasferiti.
Ottimo! Studio come organizzare al meglio e modifico gli script.
Grazie.
Buona domenica

 venivano continuamente modificati, ma non ne sono molto convinto.
Tieni presente che i log sono gestiti da logrotate, in modo che tu possa 
fare il backup del log relativo al giorno precedente senza problemi
Enrico

 dati che vengono trasferiti.
Concordo su rsync però ora ragiona.
-z   --compress compress file data during the transfer
Rsync sta per "remote sync" ed è nato per sincronizzare file e directory 
su sistemi "REMOTI". 
La sincronizzazione implica che sorgente e destinazione, alla fine, sono 
IDENTICI.
Quando vai a sincronizzare file su sistemi remoti, può essere utile 
comprimere i dati in transito e decomprimerli dall'altra parte perchè si 
risparmia tempo e banda.
In questa ottica, il flag -z, è utilissimo.
Ora: rsync può essere utile anche per sincronizzare anche interi alberi 
di directory tra una parte ed un'altra del filesystem.
Quando tu parli di USB, si suppone che attraverso USB tu stia montando un 
file system LOCALE.
Mi spieghi che senso ha comprimere i dati per passarli a me stesso e poi 
scriverli su USB ??
Non mi risulta che via USB si possano trasmettere dati zippati che poi 
vengono unzippati automaticamente dallo storage dal lato opposto.
Mi sbaglio io o ti sei appena esibito in una tua tipica uscita ??

 ha scritto:

Quindi, mi stai dicendo che la compressione *potrebbe* non funzionare
anche su un mount point NFS.
Oppure, in caso di automount, rsync si accorgebbe
che /net/<host>/bla/bla è montato remotamente e attiverebbe la
compressione?
IO leggo le info della man page come segue: i dati vengono compressi,
indi *inviati*, indi decompressi.
Potresti anche avere ragione, ma dove leggi che la compressione viene
attivata solo in funzione della remote shell?
Se lo trovi dimmelo.


 attivata solo in funzione della remote shell? Se lo trovi dimmelo.
Capovolgi il discorso, visto che sei tu che ti inoltri in consigli 
alquanto dubbi e poco professionali (e come dimostri da quanto scrivi, 
senza nemmeno averli mai provati).
Che senso ha comprimere dei dati quando sto copiando dei file su un hard 
disk attaccato localmente ed il file, alla fine, è pari pari quello di 
partenza ??
Avrebbe senso (e non ci vuole una volpe per capirlo) se i dati passassero 
sul cavo USB zippati ed il controller USB dall'altra parte provvedesse a 
decomprimerli prima di salvarli.
Non mi pare che tale "feature" esista.

anche su un mount point NFS.
No, la compressione funziona sempre (mamma dici "-z" e picciotto va e fa).
Il problema č che quando arriva al connettore USB, il file compresso viene
decompresso, perché sulla chiavetta USB va scritto in chiaro.
Quindi, -z non ti toglie il collo di bottiglia dell'USB - aggiunge solo un
certo costo per la compressione/decompressione.
Casomai si potrebbe, ninzň, montare l'USB in loop compresso, e usare rsync
*senza* -z. Cosě sullo storage finiscono i dati compressi.
Oppure usare tar, e di nuovo sullo storage c'e' roba compressa.
Oppure stai collegando due macchine via USB (cioč USB č il transport e non
lo storage). Allora sě, -z ti puň fare: 400 Mbps di dati compressi, invece
che 400 Mbps di dati non compressi, potresti arrivare ai gigabit.
===
Non e' che hai detto "USB" e stavi pensando "ETH"?
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

 
IMHO - da prove - funziona anche localmente.
Ho usato "rsync --compress --compress-level=9" e ho visto che:
1. la cpu schizza costantemente tra il 99% e il 100%
2. il trasferimento locale di alcuni file grossi impiega del tempo (il
tempo della compressione). Il trasferimento di un file di 15 mega, in
locale, con la compressione, impiega una decina di secondi.
Ho tolto le opzioni di compression e la cpu si mantiene al 30%, con
picchi del 40%.
Il trasferimento del file di cui sopra è immediato.
p.s.: se fai rsync della /boot lo noti subito ad occhio.... ci sono
differenze nel comportamento.


 Se lo trovi dimmelo.
La compressione viene attivata, se glielo dici.
E' solo inutile.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 differenze nel comportamento.
Tipica dimostrazione del fatto che la compressione, in locale, non solo è 
inutile ma è anche deleteria, al contrario di quanto suggerivi.
Un'altra occasione persa.

 solo un certo costo per la compressione/decompressione.
mmmmhhh ... ma rsync non crea dei file di spool, che rappresentano il
trasferimento parziale, e il cui nome è random o giù di lì?
Dici che quel file di spool è già decompresso??


 quel file di spool è già decompresso??
ti avevo chiesto di ragionare qualche post fa.
Evidentemente non è possibile.
Aiutino...
Se il file fosse compresso (cosa che non è), allora rsync poi dovrebbe 
rileggerselo, decomprimerlo e riscriverlo su disco in forma originale, 
utilizzando il bus (USB o qualunque sia) per:
- scrivere il file compresso
- rileggerlo
- (decomprimerlo in memoria)
- scriverlo nuovamente in forma non compressa.
- rinominarlo nel file corretto
Invece, rsync (pensa un pò) lo scrive non compresso e, quando ha finito, 
se ha finito in maniera corretta, lo rinomina facendo un mv sul file 
corretto. In altre parole, salta i primi 3 passi.
Così, ad occhio, secondo te quale è l'approccio migliore ?

 originale, utilizzando il bus (USB o qualunque sia) per:
nel frattempo ho fatto un prova "sul pezzo" e ne è venuto fuori che il
file di spool *NON* è compresso. 
Ok: torno a cuccia.


 
ah: mi sono auto-chiarito il resto dell'arcano.
La compressione avviene per blocchi di dati. Ciò rendo possibile la
scrittura, non esattamente continua, ma per aggiunta di blocchi che
vengono decompressi di volta in volta.


Dici che quel file di spool è già decompresso??
Non ci stiamo intendendo. Tu mi parli di collo di bottiglia dell'USB. Per
fissare le idee diciamo che il connettore del disco USB è stretto, okay?
Chiunque copi i file, comunque li copi, devono passare dal connettore. E,
dall'altro lato, devono essere identici all'originale (tali sono i poteri
di rsync o chi ne fara' le veci); cioe' non compressi.
Per ridurre il collo di bottiglia all'USB devi intervenire sul connettore
USB stesso, ed e' roba sostanzialmente hardware:
	* lavori in USB3
	* usi un disco USB con un firmware furbo E UN DRIVER APPOSITO, in
	  grado di comprimere i dati prima del connettore e decomprimerli
	  dopo il connettore.
Via software devi intervenire a livello di fs; per esempio usi compFUSEd,
anche se in alcuni casi (tabelle di database, ecc.) c'e' un overhead vuoi
di relocation usando rsync, vuoi per dover ricopiare tutto il file.


Tornando al problema della copia, mi dite che un "cp -fR" può andare 
bene per essere tranquilli? Anche se non è sofisticato mi interessa che 
funzioni, ed è una copia in più che ogni giorno sovrascriverei.
Grazie
Fabio



Usa rsync che è fatto per questo.
Tralasciando la parte inventata del -z, il consiglio di Max Adamo era 
buono per questo.