CUIDADO com o comando "dd", embora muito útil ele pode ser perigoso

Todos sabem que os primeiros 512 bytes de um dispositivo de armazenamento (HD, pendrive, cartões de memória etc) são usados para guardar informações sobre o MBR certo? Quase certo, na verdade apenas 446 bytes dizem respeito ao MBR, 66 bytes dos 512 são referentes à tabela de partições do HD. É justamente aí onde mora o perigo.

[ Hits: 19.353 ]

Por: INACIO CORDEIRO ALVES em 04/11/2009


O dd e os "512" bytes do MBR



Ao contrário do que muitos falam a respeito do Master Boot Record (O famoso MBR), ele não possui um total de 512 bytes e sim 446. Dos 512 normalmente citados, 66 bytes são usados para guardar informações sobre a tabela de partições do dispositivo.

Creio que muitos já conhecem os problemas de se ter mais de um HD SATA em um computador. Na verdade o problema mais comum ocorre quando dois ou mais dos HDs estão marcados como inicializáveis, isto faz com que na maioria das vezes o sistema para durante a inicialização, acusando que não foi possível encontrar a referida imagem de boot.

Pensando desta maneira, logo me ocorreu uma ideia (correta até certo ponto): se eu apagar os dados do MBR de um HD não terei problemas em ligar o computador com dois HDs SATA conectados a minha placa-mãe.

A ideia está correta porque, realmente, se apenas um HD estiver marcado como inicializável (isto é, apenas um deles possui dados gravados no MBR), então não temos problemas na inicialização, como se pode constatar ao comprarmos um HD novo (não particionado, não inicializável) e instalarmos em nosso computador.

O problema: o comando dd usado como segue:

# dd if=/dev/zero bs=512 count=1 /dev/sdX

"Apaga" (na verdade ele preenche com zeros) os primeiros 512 bytes do dispositivo /dev/sdX. Mas como citado acima, bastaria apagar os primeiros 446 bytes. Se usarmos o comando como ele está, apagaremos também a tabela de partições do nosso HD. Consequentemente, "perderemos" as referências necessárias para nossos arquivos.

Mas nem tudo está perdido!

Fazendo backup do MBR com dd ou recuperando com o testdisk

Se você for um homem prevenido (vale por 2 hein?), então deve possuir um backup do MBR + tabela de partições do seu HD em algum lugar seguro. O comando:

# dd if=/dev/sdX bs=512 count=1 of=mbr-tabela-particoes.backup

irá criar uma cópia dos primeiros 512 bytes contento as informações de que precisaremos para uma futura restauração com o comando:

# dd if=mbr-tabela-particoes.backup of=/dev/sdX

Mas se você, assim como eu, não se preveniu, é hora de conhecer o testdisk. O testdisk é um programa livre de código aberto que permite você fazer uma varredura no disco corrompido listando tudo o que um dia foi partição e te dando a possibilidade de escrever uma (velha) nova tabela de partições para o HD.

Vá ao site de download no endereço:
e você encontrará versões disponíveis para Linux e Windows.

Se você usa Debian ou derivados, basta usar o comando apt-get. Se usa o BackTrack, ele já vem com o utilitário instalado.

Inicie o utilitário, surgirá então a tela:
Linux: CUIDADO com o comando 'dd', embora muito útil ele pode ser perigoso.
onde você poderá escolher o dispositivo a ser recuperado. Em seguida a tela:
Linux: CUIDADO com o comando 'dd', embora muito útil ele pode ser perigoso.
pergunta qual o tipo de particionamento. A maioria das pessoas deve escolher Intel aqui, a menos que você use um Mac ou outro tipo de máquina.

Na tela seguinte:
Linux: CUIDADO com o comando 'dd', embora muito útil ele pode ser perigoso.
você escolhe a opção [quick search], que dependendo da capacidade do dispositivo deveria se chamar [slow search]. Após algum tempo (no meu caso, quase duas horas) será mostrada uma lista contendo todas as possíveis partições. Se você já formatou e particionou seu HD várias vezes é provável que as diferentes partições usadas sejam listadas nessa hora.

Você pode então escolher as partições desejadas (usando as setas para cima/baixo) em seguida usar as setas para esquerda/direita e decidir se a partição é primária (P), inicializável (*) ou lógica(L).

Ao final escolha a opção [write] que sua tabela de partições será restaurada.

Conclusão

Cada dia se aprende mais um pouco, quem diria que eu precisaria saber que o MBR possui 446 bytes e não 512?

Mas é assim mesmo, é apanhando que se aprende!

Uma das coisas interessantes do testdisk é que juntamente com o pacote de vem um outro utilitário chamado photorec. Este utilitário permite recuperar arquivos apagados do seu sistema. Infelizmente ele não recupera os nomes de tais arquivos, porém o mais importante ele consegue obter, que é o seu arquivo de volta.

Finalmente, não façam como eu. Tomem cuidado ao usar o "dd". Se seu desejo é apenas excluir o MBR, use o valor do bs=446 ou então desmarque a flag de inicializável usando o fdisk.

   

Páginas do artigo
   1. O dd e os "512" bytes do MBR
Outros artigos deste autor
Nenhum artigo encontrado.
Leitura recomendada

Docker + Cluster DRBD + SQL Server - Database as a Service Utilizando Volumes Replicados

Reaproveitamento e meio ambiente

Problema no GRUB no Debian Squeeze 6.0.7 [Resolvido]

Configurando dispositivo CD-R/CD-RW e gravando CD em modo texto

Linux_logo: customizando até o SHELL do seu GNU/Linux

  
Comentários
[1] Comentário enviado por Credmann em 04/11/2009 - 07:03h

O dd é ainda mais perigoso em volumes criptografados. Se pegar um byte da chave está rudo perdido. Nem o testdisk poderá fazer algo a respeito.
Há novos esquemas de particionamento que não usam o MBR. O GPT, por exemplo.

[2] Comentário enviado por grandmaster em 04/11/2009 - 08:32h

Bom alerta :)

---
Renato de Castro Henriques
CobiT Foundation 4.1 Certified ID: 90391725
http://www.renato.henriques.nom.br

[3] Comentário enviado por GilsonDeElt em 04/11/2009 - 09:11h

D+, cara
um artigo simples, técnico, e direto!
Congratulations!

[4] Comentário enviado por Teixeira em 04/11/2009 - 09:26h

Valeu pelo alerta e pela informação em si.
Muito embora eu soubesse de antemão que os 512 bytes não eram totalmente utilizados pelo MBR, eu sempre desconheci onde terminava o MBR e onde começava a tabela de partições.
Agora, existem uma segunda tabela de partições e uma segunda FAT que ficam gravadas em algum lugar do HD e eu nunca soube exatamente onde.
Especificamente no caso da FAT, quando o outro sistema operacional "embola o meio de campo" seria útil saber isso. Mas existem programas (sempre de terceiros) que conseguem ler a segunda FAT e realizar o seu sincronismo.

[5] Comentário enviado por davidxtwo em 04/11/2009 - 09:38h

Muito bom o artigo inacioalves, isso me ajuda a não cometer erros quando fuço o sistema.

[6] Comentário enviado por cleitão em 04/11/2009 - 09:39h

Bom dia caro amigo Inácio,

li seu artigo e achei muito interessante, mas gostaria de tirar uma dúvida com você.
A pouco tempo utilizei o para clonar uns 30 maquinas todas trabalham apenas com 01 HD, então configurei um do jeito que era preciso e depois colocava o hd espetado na máquina e passava dd if=/dev/sda of=/dev/sdb fazia o procedimento blz finalizou eu pegava o hd colocava na máquina que era para rodar e levanta o sistema normal.
Num tipo de procedimento desse você tem algum histórico de problemas?
Basicamente utilizei o dd para uma cópia fiel apenas.

Muito obrigado pela atenção.

[7] Comentário enviado por gustavo luis em 04/11/2009 - 12:53h

otimo artigo mais pra mim meio tardio heheheh
mais resolveu um problemao graças a Deus XD

[8] Comentário enviado por removido em 04/11/2009 - 13:44h

eu tive uma experiencia dessa
me passaram o comando errado, no caso.
daí, passei nos 4 hds do meu pc
resultado: ADEUS dados
XD
ainda bem que existe o testdisk

[9] Comentário enviado por manoserpa em 04/11/2009 - 15:49h

Parabéns, também não sabia deste detalhe.

Valeu.

[10] Comentário enviado por femars em 04/11/2009 - 16:06h

é, só mais um comentário, a ferramente testdisk é simplismente fantástica, nela vem outra ferramente chamada Photorec, voltada para recuparação de arquivos específicos. Muito bom o artigo!

[11] Comentário enviado por inacioalves em 04/11/2009 - 21:12h

Primeiramente agradeço a todos pelos comentários.

Em segundo lugar, postei este artigo como um aviso para que ninguém mais cometa o mesmo erro que eu. Mesmo sabendo que em breve alguém estará por aqui (ou em outros sites) procurando uma forma de recuperar dados perdidos acidentalmente.

Teixeira,
Não sei te dizer a esse respeito já que eu desconhecia esta informação.

cleitão,
Até agora não desconheço problemas com este uso do comando. Mas ainda assim vale algo semelhante. O único cuidado é com o que tem no HD que vai receber os dados, pois neste caso não terá mais volta. Explicação: O que é dd faz é uma cópia bit-a-bit. Assim, se você usar o testdisk no segundo HD após a utilização do dd então, você verá apenas os dados que estavam no seu primeiro HD.
No seu caso em particular, eu já devo ter citado em outros lugares aqui no VOL que eu tenho uma preferência pelo partimage. Ele copia apenas os dados de uma partição (não a partição inteira). Deste modo, se tinha algo importante no HD que recebeu a cópia ainda será possível recuperar alguns arquivos (possivelmente com um grau de dificuldade bem maior). Ademais, o partimage permite que você rode um servidor e guarde diversas imagens compactadas. Por exemplo, aqui no IFCE Maracanaú (Região metropolitana de Fortaleza), todo semestre reinstalamos a versão mais recente do Ubuntu nas máquinas. Enquanto que a instalação inicial demora certa de um dia inteiro (que programas serão usados no laboratório durante o semestre, pois com disciplinas diferentes surgem necessidades diferentes), no outro dia conseguimos instalar 30 máquinas em questão de 3 ou 4 horas (buscando as imagens, atualizadas, no servidor).


xiiico,
Realmente me esqueci do Photorec que é uma ferramenta excelente. O único problema que tive com ela é que ele não recupera a estrutura de diretórios pre-existente nem os nomes dos arquivos.
O maravilhoso desta ferramenta é que ela consegue trazer de volta o mais importante: O conteúdo(desde que você não esteja tentando recuperar aquela instalação do eclipse com 250MB e diversos plugins que você tanto suou para juntar).

[12] Comentário enviado por albfneto em 04/11/2009 - 21:38h

nunca é demais recomendar cuidado...
testdisk também é perigoso,não é só o dd...
hdparm também.

[13] Comentário enviado por edgarlemke em 04/11/2009 - 22:41h

Olá!

Gostei bastante do artigo.
Pessoalmente não conhecia o partimage que você citou, seria um software semelhante ao PQDI e ao Norton Ghost? Se sim, seria muito útil porque aqui no curso nós estávamos com problemas quanto a isso, procurando uma solução free. ;D

[14] Comentário enviado por albfneto em 05/11/2009 - 10:37h

edgar, para copiar partição toda, tem também o Clonezilla.

[15] Comentário enviado por Diede em 05/11/2009 - 13:42h

edgarlemke,

O partimage é "semelhante" ao Ghost sim. Ele não é como uma cópia "total" feita com o "dd", pois copia apenas os setores utilizados da partição, e ainda há opção de compactação (gz, bzip2)!

[16] Comentário enviado por cleitão em 05/11/2009 - 17:36h

Boa tarde amigo Inácio,

dúvida resolvida neste caso que estou comentando não tem problemas com o HD que está recebendo os arquivos, pois são micros novos que estou apenas utilizando o dd para uma clonagem.
Mas se algum dia eu for fazer algo que va copiar em cima de outros dados vou seguir suas dicas com certeza.

Obrigado.

[17] Comentário enviado por ramontcruz em 05/11/2009 - 19:13h

realmente acrescentou :-)
parabens!!!!

[18] Comentário enviado por inacioalves em 05/11/2009 - 20:00h

Caro albfneto,

Não sei qual perigo poderia representar o testdisk, talvez o fato de você tentar recuperar arquivos gravando na mesma partição que você está recuperando.
Partindo do pré-suposto que os arquivos não foram fisicamente apagados, mas que apenas seus inodes foram perdidos, todos devem saber que não é seguro recuperar dados de uma partição para ela mesma, requerendo assim uma segunda partição ou um outro HD para se realizar tal tarefa.

Se é isto, acho que já nos entendemos. Se não é, gostaria que você exibisse um exemplo do perigo para que todos nós possamos nos precaver contra ele.
Desde já agradeço sua colaboração e alerta.


edgarlemke,
Tinha me esquecido por um instante do artigo do Morimoto que explica como usar o partimage e como clonar a "MBR" (olhe o título do meu artigo quando estiver lendo o artigo do Morimoto) que você pode ver no link abaixo.
http://www.guiadohardware.net/artigos/clonagem-backup-partimage/
Além de ensinar a "clonar" uma partição, ele ensina como montar um servidor partimage permitindo que você recupere as cópias via rede, evitando assim o uso de um HD externo. Se você tiver uma rede separada em seu laboratório com as máquinas conectadas através de um switch, é possível recuperar até três máquinas simultaneamente em uma rede fast ethernet 100mbps. Dependendo do tamanho das imagens, a recuperação demora em média 10 minutos. Assim, neste curto tempo você terá 3 máquinas prontas para uso, enquanto que uma instalação manual pode levar o dia todo e uma recuperação com o dd e um HD externo pode demorar algo em torno de 30 minutos.

[19] Comentário enviado por vinipsmaker em 06/11/2009 - 09:14h

Muito bom seu artigo, parabéns.

[20] Comentário enviado por removido em 27/07/2014 - 19:09h

Artigo muito bom, favoritado;


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts