'dd' pode ser usado para clonar em um HDD menor, sabendo que as partições precisarão de edição?

Question 1

Como outros mencionaram aqui, o uso simplesmente ddnão funciona devido à cópia da tabela GPT colocada no final do disco.

Consegui realizar uma migração para uma unidade menor usando o seguinte método:

Primeiro - inicialize na distribuição liveCD de sua escolha.

Redimensione as partições da unidade de origem para realmente caberem nas restrições da unidade menor (usando, gpartedpor exemplo). Então, assumindo que sdaé o disco de origem, usando sgdisk, primeiro crie um backup da tabela GPT da unidade de origem para garantir a segurança: `

    sgdisk -b=gpt.bak.bin /dev/sda

Supondo sdbque seja o destino, replique a tabela da unidade de origem para o destino:

    sgdisk -R=/dev/sdb /dev/sda

sgdiskagora reclamará que tentou colocar a cópia do cabeçalho fora dos limites do disco de destino, mas depois retornará e colocará o cabeçalho corretamente no limite superior do disco de destino.

Verifique se um clone correto da tabela de partição foi criado na unidade de destino usando a ferramenta de sua escolha ( gpartedpor exemplo).

Usando dd, copie cada partição da unidade de origem para a de destino:

dd if=/dev/sda1 of=/dev/sdb1 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda3 of=/dev/sdb3 bs=1M conv=sync,noerror,notrunc status=progress
etc...

Obviamente, se você confundir os nomes das unidades ao replicar a tabela de partição GPT sem um backup ou ao ddfazer o download do conteúdo, você pode dar adeus ao seu conteúdo :)

Answer

Como outros mencionaram aqui, o uso simplesmente ddnão funciona devido à cópia da tabela GPT colocada no final do disco.

Consegui realizar uma migração para uma unidade menor usando o seguinte método:

Primeiro - inicialize na distribuição liveCD de sua escolha.

Redimensione as partições da unidade de origem para realmente caberem nas restrições da unidade menor (usando, gpartedpor exemplo). Então, assumindo que sdaé o disco de origem, usando sgdisk, primeiro crie um backup da tabela GPT da unidade de origem para garantir a segurança: `

    sgdisk -b=gpt.bak.bin /dev/sda

Supondo sdbque seja o destino, replique a tabela da unidade de origem para o destino:

    sgdisk -R=/dev/sdb /dev/sda

sgdiskagora reclamará que tentou colocar a cópia do cabeçalho fora dos limites do disco de destino, mas depois retornará e colocará o cabeçalho corretamente no limite superior do disco de destino.

Verifique se um clone correto da tabela de partição foi criado na unidade de destino usando a ferramenta de sua escolha ( gpartedpor exemplo).

Usando dd, copie cada partição da unidade de origem para a de destino:

dd if=/dev/sda1 of=/dev/sdb1 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda2 of=/dev/sdb2 bs=1M conv=sync,noerror,notrunc status=progress
dd if=/dev/sda3 of=/dev/sdb3 bs=1M conv=sync,noerror,notrunc status=progress
etc...

Obviamente, se você confundir os nomes das unidades ao replicar a tabela de partição GPT sem um backup ou ao ddfazer o download do conteúdo, você pode dar adeus ao seu conteúdo :)

Question 2

A unidade física não deve começar a fumar, pelo menos, mas há grandes chances de que seu sistema de arquivos não funcione mais (quero dizer, o sistema de arquivos de destino; se você apenas copiou e não tocou em nada na fonte, a fonte em si deve estar bem ). Os dados dentro de uma partição não são necessariamente alocados em ordem crescente. Parte disso pode estar no final da partição, mesmo que a partição não esteja cheia (na verdade, acho que isso acontece de forma determinística com algum sistema de arquivos, mas não sei o suficiente para entrar em detalhes). Os dados podem ser essenciais para a integridade do sistema de arquivos. Portanto, recomendo fortemente que você não confie nessa cópia.

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

Pelo bsvalor, geralmente a melhor ideia é fazer alguns testes antes de iniciar a cópia real. Existem algumas ferramentas que ajudam a automatizar essa verificação, mas não lembro o nome. Na minha experiência, o melhor intervalo geralmente fica entre 4M e 16M. Acima disso você não ganha mais muito. Mas isso depende de muitas coisas, inclusive dos próprios discos. Por exemplo, raramente trabalhei com discos realmente topo de linha, que podem ser adequados para valores mais altos devido à maior velocidade e tamanho do cache.

EDITARSe uma partição for totalmente copiada, você poderá usá-la sem problemas. No entanto, como outros sublinharam, você também deve ter certeza de que a tabela de partições está intacta (pelo menos as entradas relevantes). Com as quatro partições primárias do MBR não há problemas, pois elas estão descritas 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 a partir do primeiro. É claro que é aconselhável fazer isso o mais rápido possível; outras respostas foram mais precisas com relação a isso.

Answer

A unidade física não deve começar a fumar, pelo menos, mas há grandes chances de que seu sistema de arquivos não funcione mais (quero dizer, o sistema de arquivos de destino; se você apenas copiou e não tocou em nada na fonte, a fonte em si deve estar bem ). Os dados dentro de uma partição não são necessariamente alocados em ordem crescente. Parte disso pode estar no final da partição, mesmo que a partição não esteja cheia (na verdade, acho que isso acontece de forma determinística com algum sistema de arquivos, mas não sei o suficiente para entrar em detalhes). Os dados podem ser essenciais para a integridade do sistema de arquivos. Portanto, recomendo fortemente que você não confie nessa cópia.

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

Pelo bsvalor, geralmente a melhor ideia é fazer alguns testes antes de iniciar a cópia real. Existem algumas ferramentas que ajudam a automatizar essa verificação, mas não lembro o nome. Na minha experiência, o melhor intervalo geralmente fica entre 4M e 16M. Acima disso você não ganha mais muito. Mas isso depende de muitas coisas, inclusive dos próprios discos. Por exemplo, raramente trabalhei com discos realmente topo de linha, que podem ser adequados para valores mais altos devido à maior velocidade e tamanho do cache.

EDITARSe uma partição for totalmente copiada, você poderá usá-la sem problemas. No entanto, como outros sublinharam, você também deve ter certeza de que a tabela de partições está intacta (pelo menos as entradas relevantes). Com as quatro partições primárias do MBR não há problemas, pois elas estão descritas 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 a partir do primeiro. É claro que é aconselhável fazer isso o mais rápido possível; outras respostas foram mais precisas com relação a isso.

Question 3

Embora à primeira vista o “desafio” proposto possa parecer difícil, inviável ou ingênuo como alguns comentaram, não é. A ideia principal por trás do uso do dd para migrar de um disco maior para um menor é perfeitamente correta e traz benefícios para a migração dos dados. É claro que ter espaço livre suficiente para que os dados ocupados caibam no disco de destino é um requisito necessário.

A ideia é pensar em adicionar cada partição individualmente e não o disco inteiro de uma vez como proposto inicialmente. Ainda mais pode ser feito: 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. Na verdade, esse tipo de migração é interessante para preservar os matadados do sistema de arquivos e atributos de arquivo 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. O uso do dd elimina a necessidade de reinstalar o sistema operacional ou de renomear o FS para evitar problemas com o SELinux.

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

1) Primeiro você reduziu o(s) sistema(s) de arquivos nas partições afetadas que seriam truncadas. Para isso, utilize a ferramenta resize2fs (assumindo que estamos falando de um fs ext2/ext3/ext4 - 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 que a partição em que 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ê tem um sistema de arquivos de 1 TB que deseja migrar para um drive de 500 Gig. Neste caso, sugiro reduzir o fs para, digamos, 450 Gig (você precisa 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). Os aparentes 50 GB de espaço desperdiçados serão corrigidos após a migração de dados.

2) Particionar 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 aqui são apenas exemplos; NOTA IMPORTANTE: Ao dd'ing de um dispositivo de partição maior para um menor, dd reclamará da tentativa de escrever post no final do dispositivo de bloco, tudo bem, pois os dados do sistema de arquivos teriam sido totalmente copiados antes de chegar a esse ponto. Para evitar essa mensagem de erro, você pode especificar o tamanho da cópia usando bs=parâmetros count=para corresponder ao tamanho reduzido do sistema de arquivos, mas isso exigirá alguns cálculos (simples), mas se feito incorretamente poderá colocar seus dados em risco.

4) Depois de adicionar 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 especificação de tamanho, resize2fs aumenta o sistema de arquivos para que ocupe o tamanho máximo permitido, portanto, neste 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 tamanhos errados e arrisque seus dados. Observe que unidades GB versus GiB podem ser complicadas).

Nota para operações mais complexas: Se você tiver um gerenciador de inicialização que pretende copiar, o que é muito provável que seja o caso, você pode adicionar 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 válido e intacto). Finalmente, prossiga usando os dispositivos de partição conforme descrito acima para adicionar uma partição por vez. Eu fiz operações como essa muitas vezes. Recentemente, realizei com sucesso uma migração complexa ao atualizar de um HDD contendo uma combinação de instalações MacOSX e Linux para um SDD menor em meu MacMini6,2. Nesse caso, tive que inicializar o Linux a partir de uma unidade externa, fazer o dd no gerenciador de inicialização, executar o gdisk para consertar o GPT no novo disco e, finalmente, fazer o dd em cada partição contendo os sistemas de arquivos recém-reduzidos. (Observe que o esquema de partição GPT mantém duas cópias da tabela de partições, 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 PT após a redefinição da geometria do disco). Este foi um caso muito mais complexo, mas que vale a pena mencionar porque ilustra que este tipo de operação também é perfeitamente viável.

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

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

Answer