Il giorno lun 19 set 2016 alle 12:09, Mauro <ma...@altemica.com> ha scritto:


Il 19/09/16 11:16, Piviul ha scritto:
 Ciao a tutti, smart diceva che un vecchio hd pata da 60GB stava
 morendo sicché ho fatto il boot da una live e sto provando con dd a
 copiare il disco da 60GB su un altro HD pata da 80GB. dd da qualche
 errore di lettura ma il tutto sembra andare... ma quanto tempo ci
 metterà? Periodicamente da un output tipo

 265677+25 records in 265702+0 records out 17413046272 bytes (17 GB)
 copied, 2101,81 s, 8,3 MB/s

 Da una parte sono confortato perché sembra che abbia già copiato
 17GB, dall'altra leggo 8,3MB al secondo e sono molto preoccupato
 perché copiare 60GB a 8MB al secondo indica un tempo che supera il
 tempo a mia disposizione per recuperare la partizione...

considerando che:
quanto e' vecchio il discho pata da cui leggi (i dischi piu' vecchio
andavano a 33MB/s e pure a 7MS/s). ?
quanto tempo perde a superare gli errori di lettura (cosa di non poco
conto, visto che a ogni errore deve ritentare piu' volte prima di
tornare fault allo strato superiore)
a che velocita' scrive il disco di destinazione, magari senza cache
(hdparm) attivate?
ci potrebbe anche stare.

forse non sarebbe stato piu' conveniente copiare con rsync e soci?
Saltavi per lo meno il fatto di dover copiare bit x bit una struttura
che comunque avresti dovuto lasciare andare. Con Rsync avresti potuto
copiare solo la parte dati, e lasciare perdere il resto del disco.

La penso come Mauro: invece che copiare il disco bit a bit, che ti tocca aspettare la copia anche dei settori inutilizzati, fai prima ad usando uno strumento di livello superiore.

Io per esempio preparerei il nuovo disco partizionandolo e formattando i file system necessari, e poi ripristinerei i contenuti dei vari file system (per esempio usando cp -a /src /dest).

Tra l'altro così alla fine del lavoro puoi sfruttare subito la capacità addizionale che hai, senza dover pasticciare ulteriormente con le partizioni.

Nella mia esperienza il modo più rapido per farlo con file system ext2/3/4 è usando le care, vecchie, utility dump e restore (sudo apt-get install dump e poi man 8 dump e man 8 restore).

Supponendo che il file system originale sia in /dev/sda1, e che tu lo voglia ripristinare in /dev/sdb1, montato in /mnt/nuovodisco, i comandi da usare sono (fai tu le modifiche opportune):

$ sudo mount /dev/sdb1 /mnt/nuovodisco
$ cd /mnt/nuovodisco
$ sudo  dump -0 /dev/sda1 -f - | restore -r -f -

In questo modo sei solamente limitato dalla velocità dell'hardware. Inoltre, mentre lavora dump ti dirà, di volta in volta, a che punto è e quando dovrebbe terminare.
Quando finisce, puoi confrontare  l'originale con la copia usando:

$ cd /mnt/nuovodisco
$ sudo dump -0 /dev/sda1 -f - | restore -c -f -

Alla fine, l'unica cosa da fare sarà ripristinare il boot loader grub.

Bonus: se hai un terzo disco disponibile, puoi usare tee per salvare una immagine di backup sul disco *nello stesso momento* in cui copi il file system sul nuovo disco. Per esempio:

$ cd /mnt/nuovodisco
$ sudo dump -z -0 /dev/sda1 -f - | tee backup.dump.gz | restore -r -f -

In questo esempio, per risparmiare spazio sul disco di backup, abbiamo usato la compressione sul backup con dump, il limite potrebbe essere la velocità della CPU e non solo dei dischi. Ad ogni modo puoi gzippare il file generato da dump anche dopo, a lavoro finito. Che sia compresso o no, restore potrà leggerlo ugualmente.

In bocca al lupo,
gerlos


PS Se vuoi comunque copiare il disco bit a bit, ti suggerisco di usare pv invece che dd (sudo apt-get install pv): sarà più veloce e ti mostrerà una bella barra di avanzamento!


Rispondere a