aiuto: progress bar per rsync

[Eberoth]

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:

Codice: Seleziona tutto

rsync -azhv --stats --info=name0 --info=progress2 --del --exclude-from=$EXFILE --link-dest="$DESTDIR"/old "$ORIG"/ "$DESTDIR"/$NEW/

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...

[lablinux]

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.

[Eberoth]

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...

[lablinux]

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

[Eberoth]

... 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...

[lablinux]

Grazie delle risposte.