[BACKUP] error in rsync protocol data stream

[wodan]

Ciao a tutti!

Premetto che ho postato qui perche' l'inconveniente l'ho incontrato configurando i backup di un server, mi scuso se la sezione e' sbagliata.

Come dicevo si tratta di un server Ubuntu 6.06 per il quale ho realizzato al meglio delle mie capacita' uno script per il backup.

Il dispositivo scelto per ospitare le copie di sicurezza e' un Western Digital My Book World Edition II connesso direttamente alla LAN dell'ufficio: il proprietario mi ha vietato di agire sul dispositivo stesso (per non perdere la garanzia) al fine di attivare il protocollo NFS, quindi non mi e' rimasto altro che ricorrere a Samba.

Riesco a montare correttamente l'hdd sul server ed iniziare la sincronizzazione delle cartelle, solo che dopo un po' si inceppa tutto.

La mole di dati da processare che risiede nel server e' di 128GB, suddivisi in 5 directory principali.

Ho provato due strade nel mio script: richiamare in sequenza rsync per ciascuna di queste cartelle (pensando di agevolare e ottimizzare la procedura) e richiamare una volta solo rsync agendo sulla cartella contenitore delle precedenti.

Nel primo caso, mentre lo script e' in funzione, il comando "ps aux" mi elenca 3 istanze distinte del programma rsync tutte relative alla prima cartella. Se io le termino con il comando "kill" compaiono subito altre 3 istanze di rsync relative alla seconda cartella e cosi' discorrendo fino all'ultima, terminate le quali lo script non risulta piu' essere attivo.
Specifico questo perche' lasciandolo lavorare quando torno trovo sempre le 3 istanze di rsync attive in quel momento in stato dormiente o in pausa, ovvero sono contrassegnate dal valore "S" nella colonna STAT di "ps aux". Ecco perche' le termino assistendo all'attivazione delle altre 3 e via discorrendo.
Qualcosa pero' e' stato sincronizzato, solo poi si inceppa tutto.

Nel secondo caso invece una volta terminato le uniche 3 istanze di rsync tutto si ferma, perche' anche in questo caso le 3 istanze di rsync le trovo in pausa.

In entrambi i casi l'exit status di rsync e' il 30, ovvero
http://samba.anu.edu.au/ftp/rsync/rsync.html

30
    Timeout in data send/receive

la mia domanda e': perche'?


Ho allora lanciato direttamente da shell rsync facendolo agire sulla directory decisamente meno grossa in termini di dati delle 5 citate in precedenza, circa 2GB, proprio alla maniera del primo caso.
Ho usato le medesime opzioni per rsync inserite nello script dopo aver montato a mano l'hdd (lo script prevede mount ed umount al termine della sincronizzazione) ovvero:

Codice: Seleziona tutto

rsync -rlptDv --progress $SOURCE/dir_1/ $DEST/dir_1

Preciso che ho ricopiato la stringa dello script mentre avviandolo da schell non ho fatto uso delle variabili.
Inoltre non posso usare l'opzione "-a (archive mode; equals -rlptgoD (no -H,-A,-X))" perche' mi restituisce un errore di tipo "chown"  quando deve riportare proprietario e gruppo dei file in quanto li ho specificati nel comando "mount" tramite le opzioni uid= e gid=.
Morale della favola tutto perfetto, sincronizzazione completata correttamente.

Forte di questo risultato allora ho lanciato il medesimo comando per la cartella due, decisamente piu' grossa: 50GB.
Ha funzionato bene per un po' facendomi vedere a video il progresso parziale dei vari file e poi... di brutto... si e' interrotto cosi':

Codice: Seleziona tutto

[...]
rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown" [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (1741375 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(434)
rsync: connection unexpectedly closed (1254482 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(434)
$

Come posso risolvere il mio problema? Da cosa e' causato?

Grazie davvero a tutti,

wodan


EDIT: questa la versione di rsync presente sul server

Codice: Seleziona tutto

rsync  version 2.6.6  protocol versione 29

[paper0k]

SOURCE e DEST si trovano sullo stesso server? O trasferisci i dati ad un altro server?
Nel primo caso, DEST, con che tipo di filesystem è stato formattato? Ci potrebbero essere problemi nella scrittura di files troppo grandi, controlla con "dmesg"

[wodan]

Ciao!

SOURCE e DEST si trovano sullo stesso server? O trasferisci i dati ad un altro server?
Nel primo caso, DEST, con che tipo di filesystem è stato formattato? Ci potrebbero essere problemi nella scrittura di files troppo grandi, controlla con "dmesg"

SOURCE e' un raid1 formattato in ext3 su un server Ubuntu 6.06.

DEST e' un My Book® World Edition™ II che non mi sembra abbia limiti legati al file system che per altro non ho inteso quale sia.

Il prima possibile verifico la dimensione dell'ultimo file che ha tentato di sincronizzare e ve la comunico: dovrebbe essere l'ultimo file che ha creato problemi, giusto?

wodan

[paper0k]

O l'ultimo o il successivo che stava tentando di trasferire

[wodan]

Eccomi, sono tornato nell'ufficio dove si trova il server.

O l'ultimo o il successivo che stava tentando di trasferire

L'ultimo file correttamente trasferito e' un pdf da poche decine di MB, mentre quello su cui si e' piantato un file iso da 2.4GB.

Ho pero' fatto la prova copia/incollando da VVindows quest'ultimo file terminando il tutto senza errore in circa 15min (ho aperto la finestra con la condivisione al server e un'altra finestra sulla condivisione dell'hdd), quindi possiamo escludere limiti legati al file system.

Aggiungo che mi sono portato (sempre da VVindows) all'interno dell'hdd esterno nel path dove dovrei trovarmi la copia di questo file iso (che chiamo pippo.iso) e con mia grande sorpresa mi sono trovato n file "nascosti" del tipo

Codice: Seleziona tutto

.pippo.iso.itAwr9
.pippo.iso.UdnLGp
.pippo.iso.rEs2ap
[...]

con date di creazione compatibili con l'esecuzione dello script schedulate in crontab piu' questa ultima prova "a mano" da shell, e tutti questi file occupano uno spazio su disco di 2GB ciascuno.

Ho poca esperienza in merito, ma non esiste un'opzione, o piu' opzioni, da passare ad rsync specifica per la sincronizzazione attraverso il protocollo Samba? L'unico altro backup che ho realizzato, tra due server distinti collegati tramite NFS non soffre di queste anomalie.

Server e hdd esterno comunicano attraverso l'unico switch presente in ufficio, se puo' servire.

Grazie sinceramente per il supporto.

wodan



EDIT1: ho trovato queste opzioni in http://www.samba.org/ftp/rsync/rsync.html

-W, --whole-file
With this option the delta-transfer algorithm is not used and the whole file is sent as-is instead. The transfer may be faster if this option is used when the bandwidth between the source and destination machines is higher than the bandwidth to disk (especially when the "disk" is actually a networked filesystem). This is the default when both the source and destination are specified as local paths.

--bwlimit=KBPS
    This option allows you to specify a maximum transfer rate in kilobytes per second. This option is most effective when using rsync with large files (several megabytes and up). Due to the nature of rsync transfers, blocks of data are sent, then if rsync determines the transfer was too fast, it will wait before sending the next data block. The result is an average transfer rate equaling the specified limit. A value of zero specifies no limit.

EDIT2: ho lanciato rsync specificatamente sulla cartella contenente questa iso (dimesioni totali 4,6GB):

Codice: Seleziona tutto

rsync -rlptDv --delete --progress "SOURCE/cartella specifica/" "DEST/cartella specifica"

racchiudendo i percorsi tra doppi apici perche' il path contiene nomi con spazi ed utilizzando l'opzione "--delete" per cancellare i file temporanei descritti prima.
Tutto il processo di sincronizzazione sta vertendo sulla copia del file pippo.iso che e' iniziato e rimasto a circa 8KB/s per qualche minuto (tempo previsto >77h) ed ora si e' stabilizzato su ~1.5MB/s (tempo previsto circa 15m).
Nulla di fatto:

Codice: Seleziona tutto

[...]
pippo.iso
rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown" [sender]: Broken pipe (32)
io timeout after 30 seconds -- exiting
rsync error: timeout in data send/receive (code 30) at io.c(183)
$

rsync ha generato una nuova copia temporanea ".pippo.iso.3X9ZfJ" di dimensioni poco superiori ai 2GB prima di abortire con l'output copiato sopra.

[paper0k]

MMM... Prova a modificare il timeout (opzione --timeout=SECONDS) portandolo da 30 a 600 e vedi che succede...

[wodan]

MMM... Prova a modificare il timeout (opzione --timeout=SECONDS) portandolo da 30 a 600 e vedi che succede...

Ciao!!

Premetto che ho risolto questo problema pero' me ne e' sorto un altro (o quanto meno ho un dubbio).

Andando con ordine, cio' che faceva crollare o meglio interrompere il trasferimento del file da 2.4GB non era rsync quanto piuttosto le opzioni di Samba per il mount dell'hdd: in sostanza ho scoperto che non era abilitato il supporto per i file di grandi dimensioni (lfs), limitando a 2GB appunto la dimensione massima trasferibile.
Ecco quindi le opzioni per il mount che utilizzo ora:

Codice: Seleziona tutto

mount -t smbfs -o uid=xxxx,gid=xxxx,lfs,rw //IP_device /mount_point

Per completezza di informazione la versione di Samba e' la 3.0.22: da qualche parte ho pure letto che ora Samba dovrebbe gestire di default questi file di grandi dimensioni, ad ogni modo siccome compariva tra le opzioni di smbmount ed usandola funziona tutto penso che la manterro'. (yes)



Ecco pero' il dubbio: terminata questa notte e con successo la sincronizzazione della cartella da 50GB (quella contenente il file .iso), questa mattina ho rilanciato il comando rsync sulla medesima cartella.
Io mi aspettavo che il controllo/sincronizzazione durasse veramente poco considerando che nessun file e' stato modificato da ieri notte ad oggi, invece e' dalle 9.30 di questa mattina che la sincronizzazione va avanti ed e' ben lontana dall'essere finita (in pratica sta sovrascrivendo tutti i file).
E' normale? Magari mi allarmo per niente, ma considerando che sono 128GB totali da backuppare significa che forse 24 ore non mi sono sufficienti... :-\

A questo punto temo che le opzioni che passo ad rsync non siano le piu' adatte, soprattutto per quanto riguarda il mantenimento dei permessi secondo me.

Se non ho inteso male, l'opzione -a e' l'ideale per effettuare i backup incrementali, come nel mio caso.

Il fatto pero' che io abbia specificato uid e gid in fase di mount dell'hdd vanifica di fatto l'uso di questa opzione essendo la sintesi di -rlptgoD, dove g e o servono proprio per il mantenimento owner:group dei file: sul server i vari file hanno proprietari/gruppi diversi dalle loro copie di backup per le quali li ho forzati tramite le opzioni di mount.

C'e' qualcosa che posso fare? Io ho forzato uid e gid perche' mi sembra che il mount sia piu' stabile, diversamente che opzioni dovrei usare a parte "-o lfs,rw"?

Ancora grazie,

wodan

[pezcurrel]

Forse questo può aiutare:

Codice: Seleziona tutto

man rsync

--modify-window
	When  comparing  two  timestamps, rsync treats the timestamps as
	being equal if they differ by no  more  than  the  modify-window
	value.   This  is  normally  0 (for an exact match), but you may
	find it useful to set this to a larger value in some situations.
	In  particular,  when  transferring to or from an MS Windows FAT
	filesystem (which represents times with a 2-second  resolution),
	--modify-window=1 is useful (allowing times to differ by up to 1
	second).

Ciao