Je vois quatre réponses réalisables ici:
La hdparm
méthode publiée par garethTheRed est probablement la meilleure si vous êtes connecté directement à votre ordinateur. Apparemment, cependant, si vous l'essayez connecté via USB, vous pouvez briquer votre disque. Si vous faites cela pour un lecteur dont vous êtes sur le point de vous débarrasser, cela peut être une bonne chose. Cependant, vous souhaiterez probablement sécuriser l'effacement avant de le supprimer.
La technique rapportée par imz - Ivan Zakharyaschev fonctionnera, mais peut être très lente. Je suggère que si vous ne voulez pas que les données soient récupérables, utilisez /dev/urandom
plutôt que /dev/zero
; par exemple,
dd iflag=fullblock oflag=direct conv=noerror,notrunc if=/dev/urandom of=/dev/sdX
Je déconseille ce qui suit. Pour quelque chose de plus rapide qui fait la même chose, utilisez la technique rapportée par maxschlepzig (dans la question):
ddrescue --verbose --force --nosplit /dev/urandom /dev/sdX
Ce sera plus rapide que la dd
commande, mais pas aussi vite que la hdparm
commande. Voir ci-dessous pourquoi je ne recommande pas cela ...
La badblocks
commande fonctionnera également, mais vous ne pouvez pas randomiser les données de cette façon, et encore une fois, elle sera très lente.
Enfin, je m'en voudrais de ne pas mentionner la première raison pour laquelle les gens veulent effacer complètement un disque parce qu'ils sont sur le point de s'en débarrasser. Dans ce cas, si vous ne l'avez pas déjà fait, vous voudrez peut-être essayer de récupérer le disque en premier. Si vous lisez un bloc et qu'il renvoie l'erreur d'E / S, la prochaine fois que vous écrivez dans le même bloc, le disque tentera de réaffecter un bloc différent à partir d'une liste de réserve. Une fois la liste de réserve pleine, vous obtiendrez des erreurs d'E / S lors des écritures. C'est à ce moment que vous devez vraiment jeter le lecteur.
Vous pouvez donc faire quelque chose de simple comme:
dd if=/dev/sdX of=/dev/null conv=noerror
Et puis, pour réécrire les mauvais blocs, juste quelque chose comme:
dd if=/dev/zero of=/dev/sdX bs=128k
Si cette commande fonctionne, si vous êtes courageux, vous pouvez reformater votre disque et l'utiliser à nouveau.
Vous pouvez également exécuter la badblocks
commande sur le disque deux fois. La deuxième fois, il ne devrait signaler aucun mauvais bloc ...
badblocks -v -s -w -t random /dev/sdX
badblocks -v -s -w -t random /dev/sdX
Cela prendra plus de temps, mais est plus fiable.
Il convient également de noter qu'aucune des techniques ne fait vraiment d'effacement sécurisé, à l'exception de la hdparm
commande. Rappelez-vous tous ces mauvais blocs? Ceux-ci ont encore certaines de vos données d'origine presque intactes. Un expert en récupération de données pourrait y accéder pour voir une petite quantité de ce qui était auparavant sur votre disque dur.
En ce qui concerne ddrescue et pourquoi je déconseille cela, j'ai l'antidote suivant:
Le problème est que ddrescure sera TROP bon pour ignorer les erreurs. J'avais un disque dur qui, de manière cohérente avec dd, avait baissé la vitesse d'écriture à environ 102 Go et commencé à produire des erreurs d'écriture à 238 Go. J'ai été assez impressionné par le fait que ddrescue a continué à parcourir le disque à une vitesse constante, ne signalant même aucune erreur. 17 heures plus tard, quand il était à 1300 Go quand j'ai remarqué que le voyant du lecteur lui-même a cessé de clignoter. Une vérification rapide a révélé que l'ensemble du boîtier USB était hors ligne. J'ai sorti le lecteur du berceau. J'ai remarqué que ddrescue était heureux de signaler qu'il copiait toujours sans erreur, même avec le disque entre mes mains. J'ai branché le disque sur une autre machine et j'ai trouvé que c'était maintenant une brique.
Je ne blâme pas ddrescue d'avoir fait du disque une brique. Le lecteur échouait et allait devenir une brique. Je trouve juste que ddrescue dérangeant ne donne même pas le nombre d'erreurs d'écriture qu'il ignore. Dans cette utilisation, ddrescue vous laisse penser qu'il a complètement réussi, indépendamment de tous les échecs d'écriture. Le fait est qu'il n'aurait pas dû pouvoir continuer à pleine vitesse dans la section au ralenti. La raison pour laquelle la section était lente est que de nombreux blocs avaient été déplacés par le lecteur, ce qui provoquait de nombreuses recherches lors de l'accès à cette section. C'est donc probablement le moment où la sortie de ddrescue est devenue fictive.
dd conv=noerror
pourrait être une extension GNU, je ne suis pas sûr. En tout cas, ça devrait faire l'affaire. Cependant, la réponse SATA dit au lecteur de s'effacer lui-même vaut la peine d'être effacée pour effacer des disques entiers.