can 'dd' pode ser usado para clonar em um disco rígido menor, sabendo que as partições precisarão ser editadas?

Question

Eu usei dd para clonar discos como este:

 dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync

E sempre funcionou bem. Qualquer e todos os documentos em 'dd' se esforçam para lembrar que o disco de destino deve ser do mesmo tamanho ou maior que a fonte. Isso absolutamente tem que ser verdade?

Agora, eu entendo que se eu clonar em um disco menor, não posso esperar que nenhuma partição que esteja parcialmente 'fora dos limites' no alvo esteja intacta.

No entanto, sabendo muito bem que eu precisaria editar minhas partições no alvo mais tarde, excluindo as 'out of bounds', eu ainda poderia usar o 'dd' para fazer uma cópia de força bruta da fonte até o limites do tamanho físico do alvo? Ou "dd" reduzir o alvo a uma pilha de destroços quando atingisse o limite de seu tamanho; -)

BTW, pesquisando isso, eu já vi valores recomendados para bs= de tudo, de bs=1024 até bs=32M , o que realmente é melhor?

    

Answer 1

A unidade física não deve começar a fumar, pelo menos, mas é muito provável que seu sistema de arquivos não funcione mais (quero dizer, o sistema de arquivos de destino; se você acabou de copiar e não tocou em nada na fonte, a própria fonte deve estar bem). Os dados dentro de uma partição não são necessariamente alocados em ordem crescente. Algumas delas podem estar no final da partição, mesmo que a partição não esteja cheia (na verdade, acho que isso acontece deterministicamente com algum sistema de arquivos, mas eu não sei o suficiente para entrar nos detalhes). Os dados podem ser essenciais para a integridade do sistema de arquivos. Então, eu recomendo strongmente que você não confie em tal cópia.

Se você quiser fazer essa cópia, você primeiro tem que reduzir a partição com alguma ferramenta que esteja ciente de sua estrutura interna e seja capaz de remapear tudo em boa ordem em uma partição menor. Então você pode fazer a cópia. gparted é uma boa interface gráfica para fazer esse tipo de coisa.

Para o valor bs , geralmente a melhor ideia é ter alguns testes antes de iniciar a cópia real. Existem algumas ferramentas que ajudam a automatizar essa verificação, mas não me lembro do nome. Na minha experiência, o melhor intervalo é geralmente entre 4M e 16M. Mais do que isso, você não ganha muito mais. Mas isso depende de muitas coisas, incluindo os próprios discos. Por exemplo, eu raramente trabalhei com discos high-end reais, o que pode ser adequado para valores mais altos devido à maior velocidade e ao tamanho do cache.

EDIT Se uma partição é totalmente copiada, então você pode usá-la sem problemas. No entanto, como outros sublinharam, você também precisa ter certeza de que a tabela de partição está intacta (pelo menos, as entradas relevantes). Com as quatro partições primárias do MBR, não há problemas, pois são descritos nos primeiros 512 bytes do disco. As partições lógicas são descritas em toda a partição estendida, portanto, as entradas podem ser perdidas (mas descreveriam partições que seriam perdidas de qualquer maneira). Com o GPT, há uma cópia da tabela de partições no início e no final do disco. Você perde o segundo, mas pode reconstruí-lo desde o primeiro. Claro que é aconselhável fazer isso o mais rápido possível; outras respostas foram mais precisas em relação a isso.

    

Answer 2

Embora a princípio o "desafio" proposto possa parecer difícil, não viável ou soar ingênuo, como alguns comentaram, não é. A idéia principal por trás do uso do dd para migrar de um disco maior para um menor é perfeitamente adequada e traz benefícios para a migração dos dados. Obviamente, ter espaço livre suficiente para que os dados ocupados caibam no disco de destino é um requisito necessário.

A idéia é pensar em dding em cada partição individualmente e não no disco inteiro de uma vez como inicialmente proposto. Ainda mais pode ser realizado: as partições que seriam truncadas também podem ser migradas com segurança com uma pequena ajuda de ferramentas de redimensionamento do sistema de arquivos. De fato, esse tipo de migração é interessante para preservar matadados do sistema de arquivos e atributos de arquivos estendidos que não podem ser facilmente copiados com ferramentas como cp, rsync, pax, ... que operam na camada do sistema de arquivos e não bloqueiam a camada do dispositivo. Usar o dd elimina a necessidade de reinstalar o sistema operacional ou ter que reclassificar o FS para evitar problemas com o SELinux.

Abaixo está o que eu costumo fazer para realizar tarefas semelhantes:

1) Primeiro você reduz o (s) sistema (s) de arquivos dentro das partições afetadas que seriam truncadas. Para isso, use a ferramenta resize2fs (assumindo que estamos falando de um ext2 / ext3 / ext4 fs - outros FSs modernos também possuem ferramentas de redimensionamento para o mesmo propósito). Observe que, embora - por razões óbvias - um sistema de arquivos não possa ser maior do que a partição em que ele reside, ele pode ser menor com segurança. O truque de segurança aqui é reduzir "mais do que o necessário". Por exemplo: imagine que você tenha um sistema de arquivos de 1 TB que deseja migrar para uma unidade de 500 Gig. Neste caso, sugiro reduzir o fs para, digamos, 450 Gig (você tem que ter espaço livre suficiente para isso, é claro, ou seja, o espaço atualmente ocupado neste sistema de arquivos não pode exceder 450 Gig). O aparente desperdício de 50 Gig de espaço será corrigido após a migração de dados.

2) Particione o disco de destino com a geometria apropriada considerando suas restrições de espaço;

3) dd os dados usando o (s) dispositivo (s) de partição e não o dispositivo de disco (ou seja, use dd if=/dev/sda# of=/dev/sdb# para cada partição em vez de usar if=/dev/sda of=/dev/sdb ). NOTA: sda e sdb são apenas exemplos; OBSERVAÇÃO IMPORTANTE: Ao fazer o dd'ing de um dispositivo de partição maior para um menor, o dd irá reclamar sobre a tentativa de escrever post no final do dispositivo de bloco, já que os dados do sistema de arquivos seriam copiados completamente antes de chegar a esse ponto. Para evitar essa mensagem de erro, você pode especificar o tamanho da cópia usando os parâmetros bs= e count= para coincidir com o tamanho do sistema de arquivos reduzido, mas isso exigirá alguns cálculos (simples), mas se feito incorretamente pode arriscar seus dados. p>

4) Depois de inserir os dados, redimensione o (s) respectivo (s) sistema (s) de arquivos dentro da (s) partição (ões) de destino novamente usando resize2fs. Desta vez, não especifique o novo tamanho do sistema de arquivos. Quando executado sem uma especificação de tamanho, resize2fs aumenta o sistema de arquivos para que ele ocupe o tamanho máximo permitido, portanto, nesse caso, o sistema de arquivos de 450 Gig crescerá novamente para ocupar toda a partição de 500 Gig e nenhum byte será desperdiçado. (A abordagem "reduzir mais do que o necessário" evita que você especifique acidentalmente os tamanhos e arrisque seus dados. Observe que as unidades GB x GiB podem ser complicadas).

Nota para operações mais complexas: Se você tem um gerenciador de inicialização que pretende copiar, o que é muito provável que seja o caso, você pode inserir os primeiros KBs do disco usando o dispositivo de disco em vez dos dispositivos de partição (como dd if=/dev/sda of=/dev/sdb bs=4096 count=5 ) e, em seguida, reconfigure a geometria em / dev / sdb (que conterá temporariamente uma geometria inválida para a nova unidade, mas um gerenciador de inicialização intacto e válido). Por fim, continue usando os dispositivos de partição, conforme descrito acima, para inserir uma partição por vez. Eu fiz operações assim muitas vezes. Muito recentemente, realizei com sucesso uma migração complexa ao atualizar de um HDD contendo uma mistura de MacOSX & Instalações Linux para um SDD menor no meu MacMini6,2. Neste caso, eu tive que inicializar o Linux a partir de uma unidade externa, dd'ed o gerenciador de inicialização, executei o gdisk para consertar o GPT no novo disco e, finalmente, inseri cada partição contendo apenas os filesystes apenas reduzidos. (Observe que o esquema de partição GPT mantém duas cópias da tabela de partição, uma no início e outra no final do disco. O gdisk reclama muito porque não consegue encontrar a segunda cópia do PT e porque as partições excedem o tamanho do disco , mas corrige corretamente o problema de cópia de PT depois de redefinir a geometria do disco). Este foi um caso muito mais complexo, mas vale a pena mencionar porque ilustra que esse tipo de operação também é perfeitamente viável.

Boa sorte! ... e, mais importante, lembre-se de fazer backup de todos os dados importantes antes desse tipo de operação. Um erro e você certamente pode danificar seus dados irrecuperavelmente.

E caso eu não tenha enfatizado o suficiente: faça backup dos seus dados antes da migração! :)

    

Answer 3

Se você quiser encaixar um carro em uma passagem que seja 20cm mais estreita que o carro, e cortar os 20cm da esquerda do carro, o carro ainda funcionará? Provavelmente não.

Se você copiar o início de um disco para outro disco e diminuir a cópia porque o disco de destino é menor, o resultado não funcionará. Mesmo se houvesse espaço suficiente para caber todos os arquivos no disco de destino, cortar após N bytes desde o início do disco não fornecerá um sistema de arquivos em funcionamento.

Se o disco estiver dividido em partições no estilo PC (GPT ou MBR), todas as partições que couberem inteiramente no destino funcionarão. Há uma exceção: com partições MBR, se as partições lógicas não forem numeradas em ordem de disco, assim que a cadeia deixar a área de destino, as partições não serão mais listadas. (Se você não entender isso, essa é mais uma razão para não fazer uma cópia parcial do disco.) Seria muito mais sensato copiar as partições que você deseja manter, em vez de copiá-las desde o início e terminar com qualquer ajuste. . A partição parcialmente copiada no final não será utilizável.

Se o disco ou uma partição parcial for um volume físico LVM e você fizer uma cópia parcial desse volume físico, também não poderá ter certeza de obter dados úteis do resultado.

Se você deseja copiar apenas alguns dos dados de um disco grande para um disco menor, crie partições no disco menor. Se você quiser copiar uma partição para uma partição do mesmo tamanho, poderá fazê-lo com cat . Se você deseja copiar uma partição para uma partição menor, crie um sistema de arquivos na partição de destino e faça uma cópia em nível de arquivo com algo como cp -a ou pax -rw -pe -t .

Você pode usar dd em vez de cat se for masoquista. dd tem uma sintaxe estranha e é normalmente mais lento que cat a menos que você encontre o tamanho correto do buffer. Não existe um único valor ideal para o tamanho do buffer, isso depende das características do seu hardware. Se o tamanho for muito pequeno, dd perderá tempo fazendo pequenas transferências. Se o tamanho for muito grande, dd perderá tempo lendo um buffer antes de começar a escrever o próximo. O tamanho ideal para uma transferência de disco para disco é geralmente de alguns megabytes (1024 bytes é ridiculamente pequeno). cat escolherá um tamanho decente sem nenhum esforço de sua parte.

    

Answer 4

Gostaria de compartilhar minha experiência com esse tópico, caso isso seja útil para outro leitor. Recentemente eu usei DDRESCUE para recuperar o primeiro 1/3 de uma partição NTFS de um disco rígido com defeito, e reconstruí com sucesso o segmento recuperado da partição em um disco rígido menor - resgatando assim os arquivos capturados (e perdendo o resto). A seguir estão os passos que eu dei em fazer (definitivamente uma abordagem HACKSAW !!) ...

O disco rígido de origem consistia em 750 GB formatados em NTFS com um MBR filetable. Eu tinha usado apenas algumas vezes para fazer backup de arquivos, então a maioria dos arquivos estava no início do disco, cerca de 160 GB. Um membro da família bateu o disco rígido (montado externamente) no chão - ele nunca funcionou corretamente depois disso! Usando o ddrescue (meticulosamente), consegui recuperar uma grande parte do início da unidade. Devido ao dano físico, ele é desligado com muita freqüência durante todo o processo ...

Eu tinha um disco rígido pequeno portátil disponível 150GB (montado externamente), que eu extraí os dados ddrescue diretamente para. Alternativamente, eu poderia ter extraído os dados para um arquivo de imagem e, posteriormente, montado o arquivo, no entanto, pensei em gravar os dados diretamente em um disco rígido para ser mais estreito.

O principal truque para o resgate foi editar manualmente os dados do MBR e do setor de inicialização do NTFS no disco rígido de resgate. Sem isso, o disco rígido não é reconhecido por nenhum sistema operacional. Eu não fui capaz de encontrar um programa adequado no Linux para fazer isso, então eu virei para o Windows. Existe um pacote prático chamado Windows Support Tools, que não é mais mantido, mas ainda é útil (veja o link abaixo)! A ferramenta que usei para editar a partição é o Disk Probe. Certifique-se de conhecer o valor do setor final do seu disco rígido (usei o fdisk -l no Ubuntu)

link

Usando uma boa calculadora e um pouco de criatividade, carreguei e montei o disco rígido no Disk Probe no Windows e editei os valores do setor final. No MBR, dois conjuntos de valores tiveram que ser alterados, a saber: a) o setor final do disco rígido eb) o setor final da partição NTFS. No Setor de inicialização do NTFS, o valor total de setores da partição teve que ser alterado. Em cada caso, o valor numérico foi diminuído para corresponder à "dimensão" diminuída do disco rígido menor (os setores finais foram alterados de 750 GB para 150 GB). Clique na guia Visualizar para editar esses valores.

Aqui está uma imagem do Disk Probe em ação editando os dados do setor de inicialização do NTFS

Após a edição dos campos mencionados, o Windows reconheceu a partição como uma partição válida, embora danificada. Eu entrei no prompt de comando e executei o programa do Windows Chkdsk no disco rígido danificado (chdsk D :). Foi emocionante ver a partição voltar à vida, arquivo por arquivo! O programa recria a tabela de partições e remapeava com sucesso todos os arquivos que haviam sido copiados do disco rígido danificado. Os arquivos que estavam fora do intervalo (não copiados) não foram encontrados e, portanto, foram eliminados.

A próxima parte eu não entendo a razão para, como o Windows reconstruiu com sucesso o disco rígido de 150GB com arquivos incluídos. No entanto, o Windows nativamente não foi capaz de abrir a partição do disco rígido para visualização de arquivos (houve algum erro). No entanto Ubuntu para o resgate! Eu reiniciei no Ubuntu, montei o disco rígido externo e, sem problemas, todos os arquivos recuperados apareceram!

Espero que este método hacksaw de recuperar arquivos de um grande disco rígido em um disco rígido menor seja útil para outras pessoas que não sejam eu. Felicidades!