Re: dd e velocità

[gerlos]

Il giorno lun 19 set 2016 alle 13:09, gerlos  ha 
scritto:


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 
-


Ops!
Volevo scrivere:

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


Così copi il file system di /dev/sda1 in /mnt/nuovodisco, e allo 
stesso tempo salvi un backup in /mnt/backup/backup.dump.gz.


saluti,
gerlos

Re: dd e velocità

[Piviul]

Piviul ha scritto il 19/09/2016 alle 11:16:

[...]
Sapete dirmi qualcosa in più?
grazie mille a tutti quanti, un paio di ore ed aveva fatto... tutto 
sommato veloce.


Mille grazie a tutti quanti

Piviul

Re: dd e velocità

[gerlos]

Il giorno lun 19 set 2016 alle 12:09, Mauro  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!

Re: Re: dd e velocità

[Gian Uberto Lauri]

> "M" == Mauro   writes:

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

Che blocksize hai usato? Se non hai specificato niente a naso va
avanti a blocchi da 1024 byte, facendo 4 seek e 4 read per blocco da 4
K. Se è un blocco fisico fallato moltiplichi per 4 tutti i tentativi a
vuoto.

http://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html#dd-invocation
http://www.gnu.org/software/coreutils/manual/html_node/Block-size.html#Block-size

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

A naso rsync ha bisogno delle informazioni sulla struttura del file
system per ricuperare i dati. Se c'è un errore su quelle informazioni
puoi perdere molto più di parte di un file.

Una volta portati i dati su un disco sano puoi provare a ricostruire a
mano le strutture mancanti.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: dd e velocità

[Mauro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



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.

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCAAGBQJX37lnAAoJEGBLG3R4+/FlYqUIAIY6otvZh7b6+zhplK/k1e3E
s4S+lw3s9XGlNpnWYirj0Zg2m3CiRMuHWCy1eS5fNQx00Oe9xtEwdxQ/xvCz1+Aq
m7hWsvR5bo1YN/19iCfdwWku5McuZbyqoNRjgYo6tAiVQBxoVwJsSCOA4XS/R9zw
/410xpA/gEIhJ4ZDyEXX4MlSNt4jdSF1cKnGQ2ju0bV8qqNhiLrEv89DrDLCLxLA
Ke0SoNZx6Q/j859Ce10UvkEKkkhdjuZOUS8WUOXgUx6TUgNaYIO6NxW8zdeZOKCJ
gqqUiMDdkCZapZz7ogupFmMpAKWbqE/obGP6sQT0/vGVosVy3ho3YtIEoDsjwvM=
=g/iz
-END PGP SIGNATURE-