[Risolto] Errore hash check via ssh (RClone/md5sum)

[korda]

PREMESSA: posto in questa sezione, dal momento che non conosco l'algoritmo e vorrei sapere se ci sono margini di miglioramento...

Come avrete letto in altre discussioni faccio solitamente il backup dei miei dati via rete usando RClone: per quanto riguarda il trasferimento dei dati viene impiegato rsync in multithreading. Fin qui tutto molto molto bene: il collo di bottiglia ora è a fine copia quando, a livello locale, c'è da fare il check dell'hash.

Tipicamente il mio device rimane appeso per indicativamente 20 minuti sull'immagine del disco di virtualbox (circa 40GB di file): scrivo indicativamente perché, in questa fase, non viene fornito un ETA.

Guardo meglio sui processi: vedo che in questa fase RClone fa una chiamata su md5sum, che gira su un thread singolo usando a malapena il 20% della CPU.

La domanda è molto ingenua perché, ripeto, non conosco l'algoritmo: c'è modo di parallelizzare md5sum e/o renderlo un poco più performante? Eventualmente avete qualche consiglio su come compilarlo, se questa fosse l'ultima spiaggia?

[DoctorStrange]

Dubito che un algoritmo per il calcolo di un hash possa essere parallelizzato e, comunque lascerebbe spazio a diverse tipi di problemi. Il calcolo dell'hashing andrà fatto sempre solo sul nodo master, per assicurarti che tutti i dati elaborati dai vari nodi siano stati "centralizzati" sul master, per evitare di lasciare indietro eventuali frammenti di dato.

Il problema che hai di solito si risolve con politiiche di backup un po diverse. Ad intervalli regolari si fanno dump logici, incrementali e fisici, in modo da avere copie dei tuoi dati che possano essere di diverse dimensioni.

[korda]

Dubito che un algoritmo per il calcolo di un hash possa essere parallelizzato e, comunque lascerebbe spazio a diverse tipi di problemi. Il calcolo dell'hashing andrà fatto sempre solo sul nodo master, per assicurarti che tutti i dati elaborati dai vari nodi siano stati "centralizzati" sul master, per evitare di lasciare indietro eventuali frammenti di dato.

Il problema che hai di solito si risolve con politiiche di backup un po diverse. Ad intervalli regolari si fanno dump logici, incrementali e fisici, in modo da avere copie dei tuoi dati che possano essere di diverse dimensioni.

Vero quanto scrivi su politiche di backup differenti: ma su un file vdi di grosse dimensioni (che cambia ad ogni scorreggia di virtualbox, se mi passi la metafora) come potrei fare un backup incrementale efficiente?

Edit: quello che mi interessa di quel file vdi non sono tanto i dati (che trasferisco di solito sulla macchina host ed evito di lasciare sulla guest per quanto possibile) quanto la configurazione del sistema in sé e del software ivi installato con relative patch e aggiornamenti.

[vaeVictis]

Fai pacchetti più piccoli. Caricali sul server. Usa il comando parallel per parallelizzare (più o meno) il calcolo dell'hash.
No?

[korda]

Fai pacchetti più piccoli. Caricali sul server. Usa il comando parallel per parallelizzare (più o meno) il calcolo dell'hash.
No?

Mmmh... avrei voluto evitare di aggiungere un'ulteriore fase preparatoria, e post, al flusso del job.

Però hai ragione: potrebbe essere un'idea intelligente da valutare. Grazie del consiglio.

[vaeVictis]

Comunque algoritmi parallelizzati per il calcolo dell'hash esistono. Non danno lo stesso hash della procedura sequenziale, ma è comunque univoco. Dividi il file in blocchi, calcoli l'hash sui singoli blocchi, concludi calcolando l'hash della lista degli hash precedentemente ottenuti.

L'alternativa al metodo precedentemente suggerito consiste nel prendere il codice del programma, cambiare la procedura di hash con una cosa analoga a quella precedentemente riscritta, sperare che l'hash calcolato non venga usato in altre parti del programma. Ricompilare. Usare il tuo nuovo fantastico programma.

Forse due righe di bash ti risolvono il problema più rapidamente.

Io considererei l'ipotesi di aprire una discussione in https://crypto.stackexchange.com/ e poi ovviamente metti il link qui perché è interessante

[korda]

Io considererei l'ipotesi di aprire una discussione in https://crypto.stackexchange.com/ e poi ovviamente metti il link qui perché è interessante

Potrebbe essere un'idea...

Devo pensarci bene su cosa/come porre il problema, perché su stackexchange ti masticano e ti sputano tranquillamente se scrivi uno svarione anche minimo

[vaeVictis]

Devo pensarci bene su cosa/come porre il problema, perché su stackexchange ti masticano e ti sputano tranquillamente se scrivi uno svarione anche minimo

Puoi tranquillamente segnalare chi mastica e sputa violando le norme del sito, che lo permettono ma fino a un certo punto. Anche se da una parte ha senso e chi davvero vuole rimanere (tipo me) si istruisce e si adegua alle norme che hanno portato quel sito ad essere onnipresente nei risultati di Google, purtroppo il disagio è diffuso in modo trasversale e non credo sia esclusiva di questo.
Se ritieni di gradire aiuto su come impostare la cosa, vai pure di MP (non contribuisce alla soluzione del problema esposto, quindi credo che se ne parliamo in privato va bene).

[korda]

Devo pensarci bene su cosa/come porre il problema, perché su stackexchange ti masticano e ti sputano tranquillamente se scrivi uno svarione anche minimo

Puoi tranquillamente segnalare chi mastica e sputa violando le norme del sito, che lo permettono ma fino a un certo punto. Anche se da una parte ha senso e chi davvero vuole rimanere (tipo me) si istruisce e si adegua alle norme che hanno portato quel sito ad essere onnipresente nei risultati di Google, purtroppo il disagio è diffuso in modo trasversale e non credo sia esclusiva di questo.
Se ritieni di gradire aiuto su come impostare la cosa, vai pure di MP (non contribuisce alla soluzione del problema esposto, quindi credo che se ne parliamo in privato va bene).

Ci penso su: un'altra via preliminare percorribile sarebbe quella di postare sulla community di RClone, dal momento che il passaggio md5sum è integrato nel workflow di quel software. Ho visto già dei GitHub relativi ad altri profili (principalmente Google Drive e Photos): magari ne hanno uno anche per SFTP.

Comunque a questo giro md5sum si è incraniato perché il file è risultato corrotto. Ho poi scoperto che, sull'SFTP, RClone ha un piccolo bug: il client è "sensibile" alla presenza di altre sessioni ssh presenti in contemporanea, tra sorgente e destinazione. Avevo aperto un secondo ssh per monitorare i processi sulla destinazione. Volevo vedere quanto venivano caricate le risorse (CPU, RAM, IO su disco) durante il trasferimento: chiudendo quella sessione prima che il trasferimento fosse completato (che girava su un'altra sessione) il logfile di RClone mi ha buttato fuori messaggi di errore relativi ad una connessione chiusa (anche se quella di RClone era ancora su e attiva). Ho provato più volte per riprodurre questo comportamento: ogni volta che chiudevo una sessione secondaria entrava un errore nel logfile. Ho il sospetto che quello sia la causa del file corrotto individuato da md5sum (NON è la causa del perché md5sum stia appeso parecchio tempo: quello accade comunque anche quando il backup va a buon fine).

[vaeVictis]

Credo di aver capito quale sia il problema: dovete assumere uno stagista

Non avevo proprio pensato alla comunità del programma, meglio!
Mi manderesti il link e anche il link ai sorgenti? E se mi dai pure il riferimento alla parte interessata nel codice mi fai un piacere.

[korda]

Credo di aver capito quale sia il problema: dovete assumere uno stagista

Non avevo proprio pensato alla comunità del programma, meglio!
Mi manderesti il link e anche il link ai sorgenti? E se mi dai pure il riferimento alla parte interessata nel codice mi fai un piacere.

I link ai sorgenti, relativi a repo RClone/SFTP, li devo cercare, nel frattempo ho cercato qualche alternativa veloce...

Ho trovato diversi link su come splittare vdi pachidermici, ma sono un po' datati (circa 5-10 anni fa), non saprei quanto siano fattibili sulle versioni di VirtualBox attuali. Bisognerebbe testarli.

https://www.google.com/search?q=linux+s ... iple+files

Come ultima spiaggia si potrebbe disabilitare l'hashcheck, se dovessi essere proprio alla frutta e non avessi sbatta

https://rclone.org/sftp/#sftp-disable-hashcheck

Ci dormo su e poi ci ragionerò meglio...

P.S.: pure sull'ipotetico bug dell'ssh dovrei approfondire, hai visto mai che abbia preso un abbaglio

[korda]

*** UPDATE ***

Mi sono raccapezzato un po' sulla mia problematica....

A quanto pare la questione secondo cui md5sum fallisce l'hashcheck potrebbe essere dovuta alle dimensioni del file .vdi.
Sono circa 75GB, attualmente, e l'hashcheck sembra fallire in concomitanza con un timeout sulla connessione ssh secondo quanto leggo nel log file... (ho appurato che non ha a che vedere con altre connessioni ssh in simultanea, devo quindi rettificare su questo punto). Finora non avevo trasferito un file singolo così grosso tutto d'un pezzo: con file da 40GB regge bene (come scrivevo nel post originale).

Ho provveduto quindi a fare uno split preventivo del file, prima di partire con il trasferimento (ho fatto uno script usando il comando split, nel caso dovessi trattare anche altri file generici di grosse dimensioni).

In termini di tempo non ho risolto un granché: quello che guadagno rispetto all'md5sum del file integro lo perdo in fase di split e di trasferimento multiplo della copia splittata.

Devo ancora verificare se con chunck più ridotti (8GB l'uno, devo ancora stabilire la dimensione ideale) l'errore dell'hashcheck possa rientrare. Sto facendo un trasferimento per verificare...

[korda]

Ho risolto disabilitando l'hash check* su file grossi (nel mio caso le immagini .vdi di VirtualBox)

Rilevo un bug comparso probabilmente con gli aggiornamenti di RaspberryOS (Debian11 - 64bit). Il bug credo sia dovuto agli aggiornamenti perché:
1) RClone l'ho installato come precompilato e non l'ho mai aggiornato;
2) l'hash check viene fatto con una chiamata su md5sum;
3) il fallimento dell'hash check non si è mai verificato prima dell'ultimo apt dist-upgrade (vedi data del primo post di questo thread).

Ho replicato l'errore mantenendo la stessa destinazione (RaspberryOS) e cambiando sorgente (Kubuntu 20.04 e Windows10). L'hash check fallisce solo con file di grosse dimensioni: non so definire quanto grossi, sicuramente l'ho riscontrato pure su file di 8GB. Per file più piccoli il log file di RClone non ha segnalato alcun errore.

Provo a postare la questione sulla community di RClone e vi darò aggiornamenti nel caso. Sarebbe utile verificare se questo bug riguardi solo RaspberryOS o sia presente pure su altre distribuzioni.

*: la disabilitazione viene effettuata specificamente per i profili SFTP con l'opzione --sftp-disable-hashcheck

N.B.: lanciando in locale md5sum sul file originale e quello trasferito (senza hash check) l'hash in output è identico