slacky.eu

Salve,
tempo fa scrissi uno script per fare dei backup incrementali. Man mano che la mia conoscenza di bash cresceva, il codice dello script è stato ampliato e rivisto una miriade di volte e, allo stato attuale, è una cosa piuttosto efficiente... ma non mi convince il feedback che da durante l'esecuzione.
Il cuore sello script è questo: dove
DESTDIR è la directory dove tengo tutti i backup, "old" è il backup precedente e NEW quello che si sta creando. ORIG è, ovviamente, la directory di cui fare il backup ( di solito, / ).

L'efficienza dello script ruota attorno al parametro "--link-dest" che, per i file presenti in tutti e due i backup senza variazioni, crea hardlinks invece di copie, risparmiando su tempo e spazio occupato.
Il problema è che, rsync, anche quando forzato a dare statistiche "totali" con "--info=name0 --info=progress2", è una fonte del tutto inattendibile, perché fa la scansione della sorgente _durante_ la copia e non prima... per cui ci sono casi in cui si passa dal 90% al 60% di completamento....
La soluzione sarebbe lanciare due volte rsync, la prima in "dry run" da usare come fonte per creare una barra di avanzamento; oppure forzarlo ad indicizzare tutti i file prima della copia... ma entrambi i sistemi sono del tutto inefficienti: il primo quasi raddoppia il tempo d'esecuzione dello script, mentre il secondo ne aumenta di pareccio l'uso di CPU e memoria...

Ora, possibile che non ci sia un modo di ottenere dati attendibili sulla durata del processo e, magari, convertirli in una elegante progressbar ascii??

Se serve, posso postare l'intero script, ma è piuttosto lungo e non credo che altre sue parti siano rilevanti...

sono ignorante in materia, ma anche la semplice copia non ha mai una tempistica certa.
Credo sia pressoche impossibile sapere con esattezza il tempo necessario.
Se copi 1 file da 1 tera o 10.000 file che sommati fanno un tera il tempo necessario, credo, sia molto superiore nel secondo caso.
E questo, sempre secondo me, ti fa sballare il tempo residuo o la percentuale di avanzamento. In base alla dimensione dei file che sta copiando in quel momento.

Sì, infatti l'idea di base era quella di usare il numero di file copiati/numero da copiare (o la dimensione in byte) come base per lo scorrimento. E' quello che rsync "cerca" di fare di suo, ed è quello che fanno praticamente tutti i tool con barre simili (wget, lftp, pv, bar...)... uno dei problemi che ho, è quello di reperire la dimensione/numero di file in un tempo decente e poi utilizzarla come base per la progress bar. Diciamo che più che sapere quanto "tempo" manca, mi interessa sapere a che punto è la copia...

Per capirci, lo script fa il backup di circa 400GB in 3h e qualcosa (meno se non uso il pc, visto che usa "ionice -c3")... se dovessi fare un dry run con rsync, starei sulle 6 ore...

"se dovessi fare un dry run con rsync" cos'è egiziano antico
ma rsync non copia solo ciò che è cambiato?

... sì, rsync copia solo ciò che è cambiato, SE ha qualcosa con cui confrontarlo. Se è il primo "backup" della serie, la directory di destinazione è vuota e quindi deve copiare ogni cosa. Senza considerare che, in alcuni casi, anche in un backup successivo posso avere differenze di una o due centinaia di GB tra backup vecchio ed attuale... e comunque, in ogni caso, rsync deve leggere l'intera sorgente per sapere "cosa è cambiato".
Tra l'altro, per misurare l'efficienza di uno script, io mi metto nel caso peggiore: è ovvio che se lancio 2 volte di fila rsync con gli stessi parametri, la seconda volta l'esecuzione sarà quasi immediata, visto che non troverà niente da copiare, ma che senso ha? A me importa che non impieghi mezze giornate quando poi deve fare lavoro serio.

Riguardo a "dry run", preferisci il termine "simulazione"? Ok, la chiamo simulazione: se lancio rsync 2 volte, la prima come "simulazione", rischio di trovarmi con tempi di esecuzione proibitivi. Meglio? Andiamo avanti...

Grazie delle risposte.