Come accelererei un intero disco dd?

51

Sto facendo un dd su due unità identiche con questo comando:

 dd if=/dev/sda of=/dev/sdb bs=4096

Entrambi i dischi rigidi hanno lo stesso numero di modello ed entrambi hanno 1 TB di spazio di archiviazione. /dev/sda utilizza un blocco di 4096. /dev/sda è un'unità locale e /dev/sdb è un caddy remoto. Potrei essere in grado di utilizzare i seguenti protocolli:

  • USB2.0 HighSpeed ​​(attualmente il piano)
  • Clone Gigabit Over-The-Network (in realtà non voglio nemmeno provarlo)
  • USB3.0 (se trovo il mio altro caddy per unità)
  • eSATA (se trovo / acquisto un cavo)
  • SATA (Se trovo / acquisto un cavo, devo amare le unità CD portatili)

Esiste un modo per eseguire questa copia dell'unità che richiede meno di 96 ore? Sono aperto all'utilizzo di strumenti diversi da dd .

Ho bisogno di clonare le seguenti partizioni (inclusi gli UUID)

  • Partizione EFI Fat32 (*)
  • Partizione Windows NTFS (*)
  • Partizione HFS + OSX
  • EXT4 Ubuntu Partition (*)
  • Scambia partizione (*)

* supportato da Clonezilla

Ho provato Clonezilla (ed era MOLTO più veloce), ma non supporta la copia intelligente HFS +, di cui ho bisogno. Forse la versione più recente supporta questo?

Quando ho creato il mio primo clone, ho fatto tutte le partizioni tranne HFS + e sono andato molto rapidamente. (Non più di 3 ore in totale)

    
posta Kaz Wolfe 12.09.2014 - 04:39

9 risposte

54

Nella mia esperienza, non penso ci sia qualcosa di più veloce nella riga di comando come dd . La regolazione del parametro bs può aumentare la velocità, ad esempio, ho 2 HDD che so avere una velocità di lettura / scrittura superiore a 100 MB / s, quindi faccio questo:

dd if=/dev/sda of=/dev/sdb bs=100M

C'è anche pv (deve essere installato per primo) che controlla la velocità più veloce su entrambe le unità e procede quindi alla clonazione. Questo deve essere fatto ovviamente da root:

pv < /dev/sda > /dev/sdb

Con PV ho ottenuto 156 MB / s

La cosa bella di pv a parte la velocità è che mostra il progresso, la velocità attuale, il tempo trascorso dall'inizio e l'ETA. Per quanto riguarda HFS +, non lo so, sto solo cercando di aiutare sulla parte "velocità". Con pv o un parametro bs molto ottimizzato, puoi eseguire un'unità da 4 TB in meno di 7 ore (6 ore e 50 minuti a una velocità corrente di 150 MB / s).

Ho fatto un paio di test con i tipi di connessione che stavi utilizzando e altri che avevo a disposizione. Stavo usando Asus Z87 Pro e Intel DZ68DP. Questo è stato il mio risultato, ma prima dobbiamo sapere che le velocità teoriche per molte velocità di trasferimento (velocità Raw) sono proprio questo, theory . Fare test reali ha rivelato che sono tra il 40% e l'80% di quella velocità grezza. Questi test possono variare in base al dispositivo utilizzato, al tipo di connessione, alla scheda madre, al tipo di cavo di connessione, al tipo di filesystem e altro. Con questo in mente, questo è quello che ho ottenuto (ho solo testato la velocità di scrittura sul dispositivo, la lettura è in genere più alta):

Connected Device  -  Connection Type  -  Speed (Write Speed)
  USB 2.0                 USB 2.0              25 MB/s
  USB 3.0                 USB 2.0              35 MB/s
  USB 3.0                 USB 3.0              73 MB/s
  eSata                   eSata                80 MB/s
  Sata 2G HDD             Sata 2G              120 MB/s
  Sata 3G HDD             Sata 2G              140 MB/s
  Sata 3G HDD             Sata 3G              190 MB/s
  Sata 2G SDD             Sata 2G              170 MB/s
  Sata 3G SDD             Sata 2G              210 MB/s
  Sata 3G SDD             Sata 3G              550 MB/s 
    
risposta data Luis Alvarado 12.09.2014 - 05:27
12

Il problema è il tipo di connessione e la dimensione del blocco. Per i risultati più rapidi, le dimensioni del blocco devono corrispondere alla metà della velocità di scrittura più bassa che si riceve normalmente. Questo ti darà un margine di sicurezza, ma permetti comunque un numero elevato; ovviamente è necessario avere abbastanza ram per contenere anche i dati.

Usb 2.0 è 12 megabit al secondo (Mbps), Usb 2.0 ad alta velocità è 480 Mbps. Questa è ovviamente la velocità grezza; con 8 bit in un byte e overhead di framing, la velocità utilizzabile in MB / s è solitamente una cifra decimale sopra. Quindi, ad esempio 480 raw, diventa utilizzabile 48 MB. Tieni presente che questo è il migliore matematico, nel mondo reale sarà un po 'più basso. Per le connessioni USB 2.0 ad alta velocità, è necessario attendere circa 30-35 MB di velocità massima di scrittura, a condizione che il dispositivo di archiviazione effettivo possa equiparare o superare la velocità di connessione.

    
risposta data Fellow 12.09.2014 - 08:17
11

Per copiare una partizione all'ingrosso, utilizza cat anziché dd . Ho eseguito benchmarks un po 'di tempo fa, copiando un file di grandi dimensioni piuttosto che una partizione, tra due dischi (sullo stesso disco, i tempi relativi sono diversi):

dd bs=64M    51.3
dd bs=1M     41.8
dd bs=4k     48.5
dd bs=512    48.9
cat          41.7
cp           45.3

La conclusione di questo benchmark è che la scelta della dimensione del blocco per dd è importante (ma non tanto), e cat trova automaticamente il modo migliore per fare una copia veloce: dd può solo rallentarti . Con una piccola dimensione del blocco, dd fa perdere tempo perdendo letture e scritture minuscole. Con un blocco di grandi dimensioni, un disco rimane inattivo mentre l'altro sta leggendo o scrivendo. La velocità ottimale si ottiene quando un disco legge mentre l'altro disco scrive.

Per copiare una partizione, potrebbe essere più veloce copiare i file con cp -a . Questo dipende da quanti file ci sono e da quanta parte del filesystem è lo spazio libero. La copia dei file ha un sovraccarico che è approssimativamente proporzionale al numero di file, ma d'altra parte copiare lo spazio libero fa perdere tempo.

La velocità massima di trasferimento dati per USB2 è di poco inferiore a 50 MB / s, che si risolve in 6-7 ore per trasferire 1 TB. Questo presuppone un disco rigido abbastanza veloce da saturare il bus USB; Penso che le più veloci unità a 7200 rpm possano farlo, ma 5900 rpm potrebbero non essere così veloci (forse sono per scritture lineari?).

Se un disco è in uso in parallelo, questo può rallentare notevolmente la copia in quanto le teste del disco dovranno spostarsi.

    
risposta data Gilles 12.09.2014 - 14:46
5

Sono d'accordo sul fatto che la velocità grezza di un comando sintonizzato con dd ('pv') o 'cat' è difficile da battere, ma se c'è qualche problema con la copia (settore danneggiato, interruzione di corrente, errore dell'utente, ecc. ) quindi devi ricominciare da capo.

Vorrei suggerire ddrescue - uno strumento FOSS che ha tutta la velocità di dd ma funzionerà attorno agli errori del disco e riprendi in un secondo momento se si verifica un errore.

    
risposta data dan_linder 17.09.2014 - 05:21
2

Sto spostando Windows 7 da un HDD a SSD e ho trovato questo e alcune altre risposte ... Qualcosa che ho imparato che potrebbe aiutare gli altri. Nel mio caso, l'unità sorgente è più grande, altrimenti avrei lavorato su / dev / sda - & gt; / dev / sdb device level.

Win7 e le sue 3 partizioni ... Ho usato Xbuntu 14.04 live cd su un usb. È saltato fuori il DVD del computer della vincita e messo l'SSD al suo posto. Installato partclone e provato questo:

partclone.ntfs -b -N -s /dev/sda3 -o /dev/sdb3

Partpunk vomitato sul ntfs che necessitava di chkdisk eseguito in Windows, quindi una soluzione rapida è diventata felice per la parte:

ntfsfix -b /dev/sda3
ntfsfix -d /dev/sda3

Tutti i comandi vengono eseguiti come root. L'interfaccia utente di ncurses di Partclone (l'opzione -N) ha detto che il trasferimento era di 7 GB / min e si è concluso a 5 GB / min, che equivale a 83 MB / sec. La parte migliore è che partclone non copia lo spazio inutilizzato, quindi questo ha reso il clone notevolmente veloce.

Potenti gotchya aggiuntivi:

  • se l'unità su cui si sta effettuando il trasferimento è stata precedentemente utilizzata, potrebbe avere residui di un GPT. Le installazioni di fabbrica di Windows 7 sono in genere tabelle di partizioni msdos / mbr. Dovrai rimuovere i frammenti GPT dall'unità di destinazione. Questo Unix & amp; Il QA di Linux mi ha aiutato in questo. Devi utilizzare gdisk sul dispositivo, utilizzare x then z e yes per zappare i dati GPT e assicurarti di mantenere l'MBR.

  • E non dimenticare che se non fai un dd a livello di dispositivo, dovrai copiare l'MBR usando
    dd if=/dev/sdb of=/dev/sda bs=446 count=1
    dove sdb è sorgente o vecchia unità e sda ​​è la destinazione o il nuovo disco ( source )

risposta data Chris K 21.12.2014 - 10:37
1

Recentemente ho creato un'immagine della partizione da 100 GB (HDD) e la scrivo sul nuovo disco SSD.

Ecco un suggerimento che può velocizzare drasticamente il processo:)

Dividi il file in parti più piccole (più grande è il file, più lentamente funziona)

sudo dd if=/dev/sda3 conv=sync,noerror bs=2M | split -a 3 -d -b 1G - /maindisk.img

Durante il processo, puoi controllare la velocità usando (in un terminale separato)

pgrep -l '^dd$' #to find PROCESSID
kill -USR1 PROCESSID #to check the speed

Quindi, quando hai una directory piena di file dei risultati (maindisk.img000, maindisk.img001 e così via ...) usare

sudo cat maindisk.img* | sudo dd of=/dev/sda1

per "masterizzare" l'immagine nella nuova partizione di SSD (la parzializzazione deve essere della stessa dimensione di quella precedente)

Per me ha funzionato in modo più veloce del solito (senza dividere). La velocità media di creazione dell'immagine era di ~ 13 MB / s. Quando uso il modo "normale" inizia con ~ 15 MB / se poi diminuisce fino a 1 MB / s.

    
risposta data matowc1991 01.12.2014 - 16:33
0

Per chiunque trovi questo thread, è molto più facile e veloce usare solo uno strumento progettato per il recupero dei dati come ddrescue . Cerca di salvare prima le parti buone in caso di errori di lettura. Inoltre puoi interrompere il salvataggio in qualsiasi momento e riprenderlo più tardi nello stesso punto.

Esegui due volte:

Primo giro, copia ogni blocco senza errore di lettura e registra gli errori su rescue.log.

sudo ddrescue -f -n /dev/sdX /dev/sdY rescue.log

Secondo giro, copia solo i blocchi danneggiati e prova 3 volte a leggere dalla fonte prima di arrendersi.

sudo ddrescue -d -f -r3 /dev/sdX /dev/sdY rescue.log

Ora puoi montare la nuova unità e controllare il danneggiamento del file system.

Maggiori informazioni:
link

    
risposta data goetzc 20.02.2016 - 21:05
0

Id consiglia di inserire / leggere - file / disco su SATA per aumentare la velocità di lettura. L'alta velocità USB 2.0 è buona anche perché ottengo una velocità media di 33816 kb / s con ddrescue rispetto a quando l'impostazione era da USB 2.0 a SATA a 2014 kb / s

    
risposta data NateNjugush 24.10.2016 - 13:07
0

Utilizza una dimensione di blocco diversa. È la quantità di dati che dd legge alla volta. Se stai leggendo troppo poco, una maggiore parte del tempo viene speso per la logica del programma e se letto troppo, si impiega molto tempo a spostare i dati di grandi dimensioni.

Per misurare la velocità con dimensioni di blocco diverse, utilizza il seguente script bash :

  • imposta $dev sul dispositivo
  • correggi cbtotal per avere almeno 5 volte la velocità di lettura prevista
    (set -o errexit; skip=0; cbtotal=$((120*1024**2)); bs=256;
    for power in 'seq 10'; do
      bs=$((bs*2)); skip=$((skip/2)); count=$((cbtotal/bs));
      if [ "$count" -lt 1 ]; then break; fi;
      echo $bs;
      dd if=$dev of=/dev/null skip=$skip bs=$bs count=$count
      skip=$((skip+count))
    done)

Il risultato potrebbe essere distorto verso una dimensione maggiore a causa della lettura del disco in anticipo: ecco perché è importante impostare cbtotal abbastanza grande.

    
risposta data ivan_pozdeev 30.06.2017 - 00:13

Leggi altre domande sui tag