Imagine que você acabou de instalar um Linux, configurou serviços, criou contas de usuários, instalou e configurou uma ou outra aplicação adicional baixada da internet. Agora, imagine que do seu lado tem outra máquina igualzinha e você vai ter que fazer a mesma coisa nela, tudo de novo? Neste outro artigo explicamos a diferenças entre SSD e SSD NVME.

Provavelmente no mínimo um suspiro de resignação você vai soltar antes de começar. Agora imagine que você não tem S.O. uma, mas cinquenta maquinas ali do lado esperando pelo mesmo tratamento. Dai você não vai mais estar suspirando, ira isso sim atrás de alguma aplicação capaz de gerar e copiar imagens de hds, como o Ghost(R) por exemplo.

E talvez nem saiba você que já possui uma ferramenta que muito provavelmente poderá resolver seu problema na linha de Comando do linux mesmo. Essa solução, ou melhor, comando, tem o simples e pequeno nome de dd (igual ao comando para apagar linhas no vi). Se você visitar a man page do dd, recebera a explicação de que ele copia e converte um arquivo, da entrada padrão para a saída padrão, a não ser que especificado em contrário. Mais um caso de man page que fala muito pouco em termos práticos, mas vamos esmiuçar um pouco.

Comandos Linux para clonar um disco SSD, HDD e até pendrive!

Você pode especificar outra entrada ou saída através das opções “if” e “of”. Sendo que:

• if = especifica o fluxo de entrada do comando
• of = especifica o fluxo de saída do comando

Assim e que se você executar o comando
# dd if=texto.txt of=texto2.txt
Terá algo equivalente a se tivesse executado
# cp texto.txt texto2.txt

O legal disso e que, se você especificar um dispositivo de blocos como fluxo de entrada, fara uma leitura, bit a bit, desse dispositivo. Relembrando, um dispositivo de bloco pode ser um HD, uma partição de um HD, um cd, um disquete, ou afins… E se você especificar como fluxo de saída um dispositivo de blocos, estará escrevendo nesse dispositivo os bytes que vierem pela entrada.

Para dar um exemplo que vai deixar isso bem claro, vamos copiar um disquete usando o dd:

1. Insira o disquete original no drive, mas não monte o seu sistema de arquivos
2. Execute o comando: dd if=/dev/fd0 of=disquete.img
3. Troque o disquete no drive por outro nao gravado
4. Execute o comando: dd if=disquete.img of=/dev/fd0

No passo 2, o dd leu o dispositivo de blocos /dev/fd0 (disquete) e jogou, byte a byte, tudo que conseguiu ler num arquivo chamado disquete.img. Esse arquivo sera uma imagem exata do sistema de Arquivos contido no disquete, com tabelas de alocação de arquivos e tudo mais. Quando executou o passo 4, você jogou esse conteudo num outro disquete, bit a bit. O resultado sera que o segundo disquete sera uma cópia perfeita do primeiro. E detalhe, se você tivesse duas unidades de disquete (muito incomum nas maquinas de hoje, mas…..) poderia ter feito diretamente:

Sendo /dev/fd0 a unidade que contem o disquete original. Se duvida que funcione, pode pegar um disquetinho e experimentar a vontade, eu espero Muito bem, agora imagine que ao invés de especificar dispositivos relativos a unidades de floppy disk, tivéssemos especificado dispositivos como /dev/hda ou /dev/hdb, teria funcionado? SIM, pode ter certeza disso, e aqui que voltamos ao problema de copiar a imagem de um HD.

Retornando ao cenário inicial, você tem uma máquina na qual acabou de instalar linux, e quer jogar a imagem daquela instalação para outro HD igual ao da primeira maquina. Você vai precisar colocar os dois HDs em uma máquina de onde você já possa dar boot num linux que não seja o do HD recém instalado, pois nenhum dos sistemas de arquivos no HD a ser lido pode estar montado. Entao o que você pode fazer e instalar esses HDs em /dev/hdc (ide2 master) e /dev/hdd (ide2 slave) numa máquina qualquer que já tenha um hd com linux bootavel (ou então use um desses live cd para dar boot) e execute:

E uma cópia exata do HD no ide2 master sera feita no ide2 slave. Aqui cabe um aviso importante sobre linux em geral: se você instalou o linux com o HD no primário master, e mudá-lo para primário slave ou secundário master, o sistema não vai dar boot.

E, obviamente, uma cópia desses sistema também não. Ou seja, quando for instalar esses HDs numa máquina, certifique-se de que estão no mesmo ide e com a mesma configuração (master ou slave) com que aquele linux foi instalado. Agora, a boa notícia e que a princípio não importa o SO que você tem no hd original. O dd não faz discriminação, e vai copiar bit a bit o que estiver no primeiro HD para o segundo. Legal né?

Bom, isto aqui já quebra um galho de quem tem que instalar várias máquinas em série, e essas maquinas em geral costumam ser iguais entre si. Mas e se forem maquinas diferentes, com HDs de capacidades diferente?

HDs de diferentes tamanhos

Primeiro entra uma regra simples e logica, se você quer colocar um sistema de arquivos dentro de um dispositivo, este tem que ter espaço para tanto. Ou seja, sempre copie do HD menor para o HD maior, nunca o contrário. No mais, você pode utilizar o procedimento feito até agora, que a única consequência e que sobrara espaço não particionado ao final do HD de destino.

O qual você sempre pode, posteriormente, particionar e especificar um ponto de montagem para ele. Outra situação e que você pode desejar querer mover aquele linux para outro HD com outro esquema de particionamento. Aqui entra de novo aquela característica do linux: se você especificou que o raiz vai ficar, por exemplo, em /dev/hda3 durante a instalação no HD original, no novo HD este também vai ter que estar em /dev/hda3.

Se especificou que o /boot tem que ficar em /dev/hda2, também tem que ficar em /dev/hda2 no novo HD. Mas a boa notícia e que nada impede essas partições de estarem alguns blocos mais a frente ou mais para trás, o que não pode e haver mais partições antes de as partições a serem copiadas em relação ao HD original. Isto posto, nada impede que você faca algo como:

(admitindo que os HDs estão no ide2 master e slave respectivamente) E repetindo o comando para quantas partições formarem seu sistema, não esquecendo a de swap claro. De novo chamando a atenção, note que foi copiado hdd2 para hdd2, ou seja, segunda partição para segunda partição.

Mas não ha impedimento que no primeiro HD a primeira partição tenha 2G enquanto no novo HD a primeira partição tenha 4G, fazendo com que a partição hdd2 fique bem adiante.

Note que, neste procedimento, você não copiou o boot loader para o segundo HD, ou seja, ele não vai dar boot logo de cara. Você vai ter que instala-lo manualmente. Se for o lilo, e se você tiver o arquivo de configuração do boot loader a ser instalado no novo HD no seu diretório atual do linux que esta usando para executar a cópia, você pode fazer algo como:

O arquivo de configuração pode bem ser o /etc/lilo.conf copiado a partir do HD original, que você montou num ponto qualquer antes de processar a cópia, so para pegar esse arquivo, e logo depois desmontou. Não e meu objetivo entrar em detalhes do comando mount aqui, a não ser uma pequena dica mais a frente. Se você não tem familiaridade com esse comando, recomenda-se um pouco de estudo em cima dele e também sobre como o linux trata sistemas de arquivos antes de tentar algo deste material.

Uma última dica: eventualmente você pode ter problemas por consequência do lilo no linux em que você executou a cópia ser uma versão diferente daquele usado pelo linux que você esta copiando. Pior, você pode ter usado para boot um linux que so usa grub (ou seja, voce tentou o comando lilo e recebeu a clássica mensagem de “command not found”). Não se desespere, você pode montar o HD original num ponto de montagem qualquer, tal como no comando:

Usar co comando chroot para mudar temporariamente a referência da raiz do seu sistema de arquivos:

E agora que seu / esta temporariamente mudado para /mnt/linuxorigem, executar o comando:

Depois e so dar exit para sair da “gaiola” onde se meteu Possivelmente tambem poderia ter funcionado se tivesse feito algo como:

Tudo depende de até que ponto as bibliotecas do linux que usou para dar boot são diferentes daquelas que o lilo do hd origem espera encontrar para sua execução.

Agora, se quer realmente se garantir contra sustos e não ter que fazer essas acrobacias, use como boot um linux idêntico aquele instalado no hd origem, e o primeiro exemplo de uso do lilo não te dará problemas. Note que esta preocupação existe apenas para gerar copias bootaveis de hds onde você copiou partições em separado. Copiando hds inteiros, como no primeiro exemplo, faz com que passe a não importar nem o SO ou SOs que estão ali.

Você também não precisara se preocupar se a partição que copiou contem apenas dados, e nao um SO que precisa dar boot. Por fim, e obvio que se a maquina para a qual o HD recém escrito com o dd tiver componentes de hardware diferentes daquela onde o linux do HD original foi instalado, você tera que reconfigurar video, som, rede, e tantos quantos forem os componentes de hardware que diferem.

Problemas em outros sistemas operacionais

Infelizmente eu não tenho como ter testado com todos os SOs que existem pelo globo (e ainda bem que hoje temos tantas opções, não? ). Mas vamos aos casos que ja testei:

• HD so com linux: normal, já vale tudo o que falei até aqui sem por nem tirar nada.
• HDs iguais, no original tem linux e windows: também sem problemas se feito como na primeira sessão deste texto.
• HDS diferentes, no original tem linux e windows: atenção especial apenas para a partição windows.

Apesar de que isto e uma matéria sobre linux, não me custa dar um conselho: execute o scandisk e o defrag antes de tentar a operação. Se o windows e recém instalado, você ate pode pular esses passos, mas eu tive uma experiência com um windows XP ja em uso ha algum tempo, em que ele travava no hd para o qual foi copiado logo apos o boot. Executar aquelas duas aplicações antes de fazer a cópia resolveu meu problema. A proposito, só testei isso até hoje com windows da linha 98/Me usando fat.

Guardando tudo em um único arquivo

Lembra do exemplo da cópia do disquete? Igual em tudo, mas você vai ter que ter espaço para guardar o arquivo criado, que vai ter o mesmo tamanho que a partição/dispositivo que você copiou. Isso mesmo que parte do sistema de arquivos sendo copiado esteja vazio.

Ou seja, se você esta copiando uma partição de 7G, mas ali dentro a soma dos arquivos guardados tem só 100K, ainda assim o arquivo que você vai gerar vai ter 7G. O dd não entende sistemas de arquivos, tudo que ele entendes ao fluxos de bytes, assim ele lê a partição inteira, até onde não tem gravado nada, e guarda. Isto posto, e só executar:

E sera criado o arquivo particao4.img, que conterá uma imagem exata do sistema de arquivos naquela partição. Agora, o dispositivo conectado em /dev/hdb pode até ser desconectado e, se mais tarde quiser restaurar aquela partição em outro hd, e só fazer:

O mesmo vale para cópias de hds inteiros. O problema de disponibilidade de espaço em disco pode ser diminuído com o auxílio do gzip:

Esse comando gera a imagem do HD, mas que agora estará compactada pelo gzip. Obviamente para utiliza-la você tera que descompacta-la:

A flag -c faz o gzip mandar os dados descompactados para a saída padrão ao invés de para um arquivo sem a extensão .gz, como faria normalmente. Não esqueça que o dd, como dito no início do artigo, copia normalmente a partir da entrada padrão. Por isso aqui não se especificou o parâmetro if= . O preço que se paga neste ultimo exemplo, claro, e um enorme acréscimo de tempo para a realização da compactação e descompactação.

Outra aplicação interessante a que isto nos leva, embora não esteja relacionada a cópia de hds, e gerar uma imagem iso a partir de um cd já gravado, para depois ser usada na gravação de um novo cd. Para fazer isso execute como no exemplo:

Depois, e só passar o arquivo gerado como argumento do cdrecord ou do seu programa de gravação favorito. E uma última dica interessante: Sabia que e possível montar esses arquivos que são cópias de sistemas de arquivos, como se fossem um dispositivo? Digamos que, no caso anterior, você queira dar uma olhada nos arquivos que o cd continha, mas o cd criou pernas e sumiu e você só ficou com o arquivo de imagem Não e preciso gravar o cd para depois montá-lo, pode-ser perfeitamente montar o próprio arquivo de imagem como em:

O segredo esta justamente em passar o parâmetro -o loop no final do comando mount. Se não funcionar, verifique se o seu kernel foi compilado com suporte a loopback device. Um jeito de checar isso e testar se e possível carregar o modulo loop (embora esse tipo de suporte pode ter sido compilado embutido no kernel, mas se assim fosse você não teria problemas e nem teria que fazer esse teste). Por fim, para encerrar esse pequeno desvio (e praticamente o artigo), note que você não está limitado a fazer isso só com imagens geradas a partir de CDs.

Pode ser feito com qualquer imagem desde que você especifique o sistema de arquivos correto com -t. Obviamente, essas imagens são montadas sempre como somente leitura. Não da para modificar o conteúdo de um arquivo de imagem usando essa técnica. Para encerrar, note que as técnicas apresentadas aqui resolvem situações simples, mas havendo a necessidade de algo mais “profissional”, realmente e melhor procurar por um aplicativo dedicado a atender esse tipo de necessidade.

De onde tirei isso tudo?

Acontece que instalo linux desde antes dos CDs bootaveis, e nessa época o que os CDs traziam era uma imagem dos disquetes de boot, e um aplicativo para DOS chamado rawwrite (ou era rawrite?) que exatamente escrevia a imagem num disquete. Me perguntando na época como poderia proceder para gravar essas imagens em um disquete se meu SO já fosse Linux, pesquisei a documentação de texto dentro do CD e la estava a orientação de como usar o dd para isso. A partir dai, foi só experimentar e expandir o conceito principal.

Por Germano Barreiro (germanobarreiro[@]yahoo.com.br)

O post Como clonar disco usando o Linux apareceu primeiro em SempreUpdate.