Vejo quatro respostas viáveis aqui:
O hdparm
método publicado por garethTheRed provavelmente é o melhor se você estiver conectado diretamente ao seu computador. Aparentemente, porém, se você tentar conectar via USB, poderá bloquear sua unidade. Se você estiver fazendo isso para uma unidade que está prestes a descartar, isso pode ser uma coisa boa. No entanto, você provavelmente deseja apagar com segurança antes de descartar.
A técnica relatada por imz - Ivan Zakharyaschev funcionará, mas pode ser muito lenta. Eu sugeriria que se você não quiser que os dados sejam recuperáveis, use em /dev/urandom
vez de /dev/zero
; por exemplo,
dd iflag=fullblock oflag=direct conv=noerror,notrunc if=/dev/urandom of=/dev/sdX
Eu aconselharia contra o seguinte. Para algo mais rápido que faça a mesma coisa, use a técnica relatada por maxschlepzig (na pergunta):
ddrescue --verbose --force --nosplit /dev/urandom /dev/sdX
Isso será mais rápido que o dd
comando, mas não tão rápido quanto o hdparm
comando. Veja abaixo por que eu não recomendo isso ...
O badblocks
comando também funcionará, mas você não pode randomizar os dados dessa maneira e, novamente, será muito lento.
Por fim, seria negligente se não apontasse a principal razão pela qual as pessoas desejam apagar completamente um disco porque estão prestes a descartá-lo. Nesse caso, se você ainda não o fez, convém tentar recuperar o disco primeiro. Se você ler um bloco e ele retornar o erro de E / S, da próxima vez que você gravar no mesmo bloco, o disco tentará realocar um bloco diferente de uma lista de reserva. Quando a lista de reserva estiver cheia, você receberá erros de E / S nas gravações. É aí que você realmente deve descartar a unidade.
Então você pode fazer algo simples como:
dd if=/dev/sdX of=/dev/null conv=noerror
E, então, para reescrever os blocos defeituosos, algo como:
dd if=/dev/zero of=/dev/sdX bs=128k
Se esse comando funcionar, se você for corajoso, poderá reformatar seu disco e usá-lo novamente.
Como alternativa, você pode executar o badblocks
comando no disco duas vezes. Na segunda vez, ele deve relatar sem bloqueios ...
badblocks -v -s -w -t random /dev/sdX
badblocks -v -s -w -t random /dev/sdX
Isso levará mais tempo, mas é mais confiável.
Também é importante notar que nenhuma das técnicas realmente faz uma exclusão segura, exceto o hdparm
comando. Lembra de todos aqueles blocos ruins? Esses ainda têm alguns dos seus dados originais praticamente intactos. Um especialista em recuperação de dados pode acessá-los para ver uma pequena quantidade do que estava anteriormente no seu disco rígido.
Em relação ao ddrescue e por que aconselho contra, tenho o seguinte antídoto:
O problema é que o ddrescure será MUITO bom em ignorar erros. Eu tinha um disco rígido que consistentemente com o dd diminuiu a velocidade de gravação na marca de 102 GB e começou a produzir erros de gravação na marca de 238 GB. Fiquei bastante impressionado com o fato de o ddrescue continuar agitando o disco a uma velocidade constante, mesmo sem relatar erros. 17 horas depois, quando eu estava com 1300 GB quando notei que a luz da unidade parou de piscar. Uma verificação rápida revelou que todo o gabinete USB ficou offline. Puxei a unidade para fora do berço. Percebi que o ddrescue simplesmente relatou que ainda estava copiando sem erros, mesmo com o disco em minhas mãos. Liguei o disco a outra máquina e descobri que agora era um tijolo.
Não culpo o ddrescue por fazer da unidade um tijolo. A unidade estava falhando e se tornaria um tijolo. Eu apenas acho que o perturbador ddrescue nem dá uma contagem de erros de quantos erros de gravação ele está ignorando. Nesse uso, o ddrescue deixa você achar que foi completamente bem-sucedido, independentemente de todas as falhas de gravação. O fato é que não deveria ter sido capaz de continuar a toda velocidade na seção com a desaceleração. A razão pela qual a seção foi lenta é que muitos blocos foram realocados pela unidade, causando muitas buscas ao acessar essa seção. Então esse é provavelmente o ponto em que a produção de ddrescue se tornou fictícia.
dd conv=noerror
pode ser uma extensão GNU, não tenho certeza. De qualquer forma, deve funcionar. Porém, vale a pena investigar a resposta SATA para dizer a unidade para apagar a si mesma.