Como eu aceleraria um dd de disco completo?

53

Estou fazendo um dd em duas unidades idênticas com este comando:

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

Ambos os discos rígidos são exatamente o mesmo número de modelo, e ambos têm 1 TB de espaço de armazenamento. /dev/sda usa um tamanho de bloco de 4096. /dev/sda é uma unidade local e /dev/sdb é um caddy remoto. Eu posso usar os seguintes protocolos:

  • USB2.0 HighSpeed (atualmente o plano)
  • Clone Gigabit Over-The-Network (Realmente não quero nem tentar isso)
  • USB3.0 (se eu encontrar meu outro caddy de unidade)
  • eSATA (se eu encontrar / comprar um cabo)
  • SATA (Se eu encontrar / comprar um cabo, tenho que amar unidades de CD de laptop)

Existe uma maneira de executar essa cópia da unidade que leva menos de 96 horas? Estou aberto a usar ferramentas diferentes de dd .

Eu preciso clonar as seguintes partições (incluindo UUIDs)

  • Partição EFI Fat32 (*)
  • Partição Windows NTFS (*)
  • Partição HFS + OSX
  • Partição do Ubuntu EXT4 (*)
  • Alternar partição (*)

* suportado pelo Clonezilla

Eu tentei o Clonezilla (e foi MUITO mais rápido), mas ele não suporta cópia inteligente HFS +, que eu preciso. Talvez a versão mais recente suporte isso?

Quando fiz meu primeiro clone, fiz todas as partições, exceto HFS +, e foi muito rápido. (Não mais que 3 horas no total)

    
por Kaz Wolfe 12.09.2014 / 04:39
fonte

9 respostas

55

Na minha experiência, não acho que haja algo mais rápido na linha de comando como dd . Ajustar o parâmetro bs pode aumentar a velocidade, por exemplo, tenho 2 discos rígidos que sei que têm uma velocidade de leitura / gravação superior a 100 MB / s, portanto, faço isso:

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

Há também pv (precisa ser instalado primeiro) que verifica a velocidade mais rápida nas duas unidades e, em seguida, continua a clonagem. Isso tem que ser feito, é claro, a partir do root:

pv < /dev/sda > /dev/sdb

Com PV eu tenho 156 MB / s

O interessante sobre pv além da velocidade é que ele mostra o progresso, a velocidade atual, o tempo desde o início e o ETA. No que diz respeito ao HFS + eu não sei, estou apenas tentando ajudar na parte "velocidade". Com pv ou um parâmetro bs muito otimizado, você pode fazer uma unidade de 4 TB em menos de 7 horas (6 horas e 50 minutos a uma velocidade atual de 150 MB / s).

Eu fiz alguns testes com os tipos de conexão que você estava usando e outros que eu tinha disponíveis. Eu estava usando o Asus Z87 Pro e o Intel DZ68DP. Estes foram os meus resultados, mas primeiro precisamos saber que as velocidades teóricas para muitas taxas de transferência (velocidades brutas) são apenas isso, teoria . Fazer testes reais revelou que eles estão entre 40% a 80% dessa velocidade bruta. Esses testes podem mudar dependendo do dispositivo utilizado, tipo de conexão, placa-mãe, tipo de cabo de conexão, tipo de sistema de arquivos e muito mais. Com isso em mente, é isso que obtive (testei apenas a velocidade de gravação no dispositivo, a leitura é geralmente mais 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 
    
por Luis Alvarado 12.09.2014 / 05:27
fonte
12

O problema é o tipo de conexão e o tamanho do bloco. Para obter os resultados mais rápidos, o tamanho do bloco deve ser metade da velocidade de gravação mais baixa que você normalmente recebe. Isso lhe dará uma margem segura, mas ainda permitirá um grande número; é claro que você precisa ter memória suficiente para armazenar os dados também.

O Usb 2.0 é de 12 megabits por segundo (Mbps), o Usb 2.0 High Speed é de 480 Mbps. Esta é, naturalmente, a velocidade bruta; com 8 bits em uma sobrecarga de byte e framing, a velocidade utilizável em MB / s geralmente é uma casa decimal. Por exemplo, 480 raw, torna-se 48MB utilizável. Tenha em mente que este é o melhor matemático, no mundo real será um pouco menor. Para conexões USB 2.0 de alta velocidade, você deve esperar algo em torno de 30-35 MBs de velocidade máxima de gravação, desde que o dispositivo de armazenamento real possa igualar ou superar as velocidades de conexão.

    
por Fellow 12.09.2014 / 08:17
fonte
11

Para copiar uma partição por atacado, use cat em vez de dd . Eu corri benchmarks há algum tempo, copiando um arquivo grande em vez de uma partição, entre dois discos (no mesmo disco, os tempos relativos são diferentes):

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

A conclusão deste benchmark é que a escolha do tamanho do bloco para dd é importante (mas não tanto) e cat encontra automaticamente a melhor maneira de fazer uma cópia rápida: dd só pode atrasá-lo . Com um tamanho de bloco pequeno, dd desperdiça tempo fazendo a perda de pequenas leituras e gravações. Com um tamanho de bloco grande, um disco permanece inativo enquanto o outro está lendo ou gravando. A taxa ideal é alcançada quando um disco lê enquanto o outro disco grava.

Para copiar uma partição, pode ser mais rápido copiar os arquivos com cp -a . Isso depende de quantos arquivos existem e quanto do sistema de arquivos é o espaço livre. A cópia de arquivos tem uma sobrecarga que é praticamente proporcional ao número de arquivos, mas, por outro lado, a cópia do espaço livre desperdiça tempo.

A taxa de dados máxima para USB2 é um pouco abaixo de 50 MB / s, o que resulta em 6 a 7 horas para transferir 1 TB. Isso pressupõe um disco rígido rápido o suficiente para saturar o barramento USB; Eu acho que as unidades mais rápidas de 7200 rpm podem fazer isso, mas o 5900rpm pode não ser tão rápido (talvez elas sejam para gravações lineares?).

Se um dos discos estiver em uso em paralelo, isso pode retardar a cópia consideravelmente, já que as cabeças de disco precisarão se mover.

    
por Gilles 12.09.2014 / 14:46
fonte
5

Concordo que a velocidade bruta de um comando dd ('pv') ou 'cat' bem ajustado é difícil de superar, mas se houver algum problema com a cópia (setor defeituoso, falta de energia, erro do usuário, etc. então você tem que começar de novo.

Eu gostaria de sugerir ddrescue - uma ferramenta FOSS que tem toda a velocidade de dd, mas funciona em torno de erros de disco e reinicie em um ponto posterior se houver uma falha.

    
por dan_linder 17.09.2014 / 05:21
fonte
2

Estou movendo o Windows 7 de um HDD para o SSD e descobri isso e algumas outras respostas ... Algo que aprendi e que poderia ajudar outras pessoas. No meu caso, a unidade de origem é maior, senão eu teria trabalhado em / dev / sda - > nível de dispositivo / dev / sdb.

Win7 e suas 3 partições ... Eu usei o Xbuntu 14.04 live cd em um usb. Peguei o DVD do computador vencedor e coloquei o SSD em seu lugar. Partclone instalado e tentei isso:

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

Partclone vomitou no ntfs precisando executar o chkdisk no Windows, por isso uma solução rápida ficou feliz com o partclone:

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

Todos os comandos são executados como root. A UI do ncurses do Partclone (a opção -N) disse que a transferência foi de 7GB / min e acabou em 5GB / min, o que equivale a 83MB / seg. A grande parte é que o partclone não copia o espaço não utilizado, então isso tornou o clone incrivelmente rápido.

Gotchyas potenciais adicionais:

  • Se a unidade para a qual você está transferindo foi usada anteriormente, ela pode ter restos de uma GPT. As instalações de fábrica do Windows 7 são geralmente tabelas de partição msdos / mbr. Você precisará remover os fragmentos da GPT da unidade de destino. Este Unix & amp; O QA do Linux me ajudou com isso. Você precisa usar gdisk no dispositivo, usar x, em seguida, z e sim para zapear os dados da GPT e garantir que você MANTENHA o MBR.

  • E não se esqueça de não criar um dd de nível de dispositivo, você precisará copiar o MBR usando dd if=/dev/sdb of=/dev/sda bs=446 count=1
    onde sdb é origem ou unidade antiga e sda é destino ou nova unidade ( source )

por Chris K 21.12.2014 / 10:37
fonte
1

Recentemente, criei uma imagem de partição de 100 GB (HDD) e gravei no novo disco SSD.

Aqui está uma dica que pode acelerar drasticamente o processo:)

Divida o arquivo em partes menores (quanto maior o arquivo, mais lento ele funciona)

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

Durante o processo, você pode verificar a velocidade usando (no terminal separado)

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

Em seguida, quando você tiver um diretório cheio de arquivos de resultados (maindisk.img000, maindisk.img001 e assim por diante ...) use

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

para "queimar" a imagem na nova partição do SSD (a parição deve ter o mesmo tamanho que a antiga)

Para mim, funcionou muito mais rápido que o normal (sem dividir). A velocidade média de criação da imagem foi de ~ 13MB / s. Quando eu uso o modo "normal", ele começa com ~ 15MB / se diminui para 1MB / s.

    
por matowc1991 01.12.2014 / 16:33
fonte
0

Para qualquer um que encontre este tópico, é muito mais fácil e rápido usar apenas uma ferramenta projetada para recuperação de dados como ddrescue . Ele tenta resgatar as partes boas primeiro em caso de erros de leitura. Além disso, você pode interromper o resgate a qualquer momento e retomar mais tarde no mesmo ponto.

Execute duas vezes:

Primeiro turno, copie todos os blocos sem erro de leitura e registre os erros no arquivo rescue.log.

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

Segunda rodada, copie apenas os blocos ruins e tente 3 vezes para ler a fonte antes de desistir.

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

Agora você pode montar a nova unidade e verificar se há corrupção no sistema de arquivos.

Mais informações: link

    
por goetzc 20.02.2016 / 21:05
fonte
0

Id recomenda que a entrada / leitura - arquivo / disco esteja em SATA para aumentar as velocidades de leitura. O USB 2.0 High Speed também é bom, já que estou obtendo velocidades médias de 33816 kb / s com ddrescue em comparação a quando a configuração era USB 2.0 para SATA 2014 kb / s

    
por NateNjugush 24.10.2016 / 13:07
fonte
0

Use um tamanho de bloco diferente. É a quantidade de dados que dd lê de cada vez. Se ler muito pouco, uma parte maior do tempo é gasta na lógica do programa e, se for ler muito, gasta-se muito tempo movendo os dados grandes.

Para medir a velocidade em tamanhos de bloco diferentes, use o seguinte script bash :

  • defina $dev para o dispositivo
  • corrija cbtotal para ter pelo menos 5x a velocidade de leitura esperada
    (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)

O resultado pode ser inclinado para um tamanho maior devido à leitura do disco à frente - é por isso que é importante definir cbtotal grande o suficiente.

    
por ivan_pozdeev 30.06.2017 / 00:13
fonte