Newsgroup: it.comp.os.linux.sys
Titolo: Aiuto ! TAR vuoto - backup MySQL

Ho una procedura di backup che genera tar.gz del tipo
-rw------- 1 backup_db backup_db 1,9G 30 dic  2011 Backup_mysql_12-30-2011-00:01:01.tar.gz
 
Sono file da 1,9 e più Giga.
Se lo scompatto con tar -zxvf lo scompatta in un attimo e trovo solo:
-rw-r--r-- 1 root      root             300 30 dic  2011 backup-my.cnf
 
Senza nessun errore nella scompattazione.
 
I backup sono generati da:
innobackupex $DESTDIR --defaults-file=/etc/mysql/my.cnf -user=$mysqluser -password=$mysqlpass --stream=tar | gzip - > ${FileBK}
 
Qualche idea ?
Grazie mille!!
 
-- Yena --


Dai uno sguardo qui:
https://bugs.launchpad.net/percona-xtrabackup/+bug/607779
 
 
 
 
 

Senza nessun errore nella scompattazione.
 
"tar tzvf" cosa dice?
 
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?


  Che non è un tar!!
 
-- Yena --

  Che non è un tar!!
 
Non e' possibile, altrimenti neanche tar xzvf funzionerebbe. Sarebbe il caso
di dare un'occhiata ai primi byte di quel file.
 
Prova a postare il risultato di
 
	hex file | head -n 20
 
tante volte si capisse qualcosa... secondo me, e' un .tgz con qualcosa messo
davanti.



 
prova con file <nomefile> e leggi cosa ti dice
 

prova con file <nomefile> e leggi cosa ti dice
 
Eh, in un caso del genere non e' ne' completo, ne' indicativo: alcuni formati
li individua lo stesso, altri li individua nonostante non siano leggibili, ed
altri ancora non li riconosce (ma un occhio umano potrebbe).
 
La tecnica del magic non e' stata pensata come aiuto forensico.
 
Se quel file fosse costituito da due .gz accodati, ci sta che file lo veda in
termini di file .gz (perche' il file comincia per \037\213), e non si accorga
di tutto quel che c'e' dopo, forse un .gz, forse no.



 
Caro Leonardo, lo so benissimo
E' solo un tentativo per trovare una soluzione
Ciao
 

E' solo un tentativo per trovare una soluzione
 
Si', scusa; a ripensarci, potrebbe dare un aiuto per identificare l'origine
dell'eventuale "primo pezzo".
 
Ma senza un campione del file penso si possa fare ipotesi fino a Natale...


 -- Yena --
 
questo perche' prima crei il tar, poi lo passa a gzip, quindi il file
risultante e' un gzip (tra l'altro te lo dice anche il nome del file:
xxx.tar.gz)
Devi prima scompattarlo con gzip e poi fare tar -x.
IMHO eh.
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 Devi prima scompattarlo con gzip e poi fare tar -x.
 
Sta usando -z.
Tra l'altro a te sembra normale che -x non dia problemi e -t invece sì?


 
Probabilmente il primo comando della pipe fallisce
Se la shell � la bash, come probabilmente �, � errato testare $? per 
verificare l' errore in una pipe
Occorre testare la variabile PIPESTATUS
 
basta provare:
(exit 1) | gzip > xx.gz
echo $?
0
 
(exit 1) | gzip > xx.gz
echo $PIPESTATUS
1
 
 
 
 
 
 


Dimenticavo:
echo ${PIPESTATUS[*]} per avere su una riga gli exit code dei singoli 
comandi della pipe
 
 
 
 


 
Già provato .. non è quello
 
-- Yena --

 -user=$mysqluser -password=$mysqlpass --stream=tar | gzip - > ${FileBK}
 
C'� qualcosa che non va qui
 
-user=$mysqluser -password=$mysqlpass --stream=tar | gzip - > ${FileBK}
 
perch� creando il tar successivamente al backup quindi senza l'opzione 
--stream=tar
 
viene fuori corretto...
 
mah ..
 
-- Yena --


OK, ma senza quella opzione il comando far� altre cose
Se funziona senza quella opzione non vuol dire che funziona 
correttamente con quella opzione
Secondo me dovresti testare, come specificato sopra da me, il valore di 
PIPESTATUS per prendere decisioni (tipo inviare una email per i casi di 
errore) e visualizzare lo standard error