Effacement du disque dur portable avec DD sous Linux [dupliquer]

J'ai 3 disques durs portables, l'un est de 160 Go, les deux autres sont de 500 Go. Je veux leur écrire des zéros en utilisant Linux et dd. J'ai trouvé cette commande:

dd if=/dev/zero of=/dev/sda bs=?

Comment pour la taille de bloc, quelle est la taille de bloc idéale pour mes 3 disques durs portables? (Remarque: j'ai placé le ?à la fin de la commande.)

Pour la bs=valeur, je recommanderais un réglage 1024comme ceci:

dd if=/dev/zero of=/dev/sda bs=1024

Mais si vous êtes paranoïaque à propos de la récupération de données et que vous voulez faire quelque chose de «plus fort» que d'écrire des zéros, vous pouvez utiliser /dev/urandomce qui suit:

dd if=/dev/urandom of=/dev/sda bs=1024

Une autre façon d’effacer un lecteur.

Mais personnellement, je n'aime pas utiliser ddce genre de tâche. Au lieu de cela, j'utilise une variante légère dans laquelle je formate le lecteur (et le repartitionnement s'il doit être repartitionné), puis j'exécute la commande suivante. Notez que même si certains pourraient considérer cette méthode comme étant supposément «inefficace», vous devez être extrêmement méfiant vis-à-vis du fonctionnement des partitions et des systèmes de fichiers pour croire que cette méthode n'est pas une méthode alternative viable:

cat /dev/zero >> /path/to/mounted/drive/junk_file &

Ou cette variante utilisant le /dev/urandompériphérique comme expliqué ci-dessus ddexemple:

cat /dev/urandom >> /path/to/mounted/drive/junk_file &

Il suffit de changer /path/to/mounted/drive/le chemin réel du lecteur monté. Cela crée un fichier appelé junk_filesur le système de fichiers et le fait en tâche de fond avec l' &ajout à la fin.

La bonne chose à propos d’une opération comme celle-ci est que vous pouvez l’arrêter et la reprendre plus tard. Ce qui signifie que c'est juste un fichier rempli de zéros ou d'urandom indésirable. Supposons donc que vous deviez éteindre la machine ou déconnecter le lecteur. Faites juste ça. Et puis exécutez à nouveau cette même commande et laissez-la continuer là où elle a commencé. Ceci est utile lorsque vous effacez des données sur des disques très volumineux pouvant prendre des heures.

Pour plus de détails sur ces méthodes de suppression de périphérique / fichier, et sur d’autres -, consultez cette page sur ArchWiki . Les astuces sont utiles pour pratiquement tous les systèmes Linux / Unix, même Mac OS X, et pas seulement ArchLinux.

Vitesse de l’opération d’effacement des données.

Pour ce qui est de la vitesse, la vitesse globale de ce type d'opération peut être estimée en fonction du temps qu'il faudrait à votre système pour copier un fichier de 160 Go ou de 500 Go sur le même lecteur. Depuis, écrire un fichier comme celui-ci est en réalité l'équivalent en données de «copier» un fichier; dans ce cas, un fichier est en cours de création.

FWIW /dev/urandomprendra plus de temps que /dev/zeroprévu - car il /dev/urandomgénère en fait des données aléatoires -, gardez cela à l’esprit si le temps joue un rôle important.

J'ai écrit ceci comme un commentaire , mais je vais le mettre comme une réponse aussi pour la visibilité.

Pour la ddtaille de bloc, vous voulez un tampon suffisamment grand pour que le programme ne se contente pas d'émettre constamment des appels système pour des quantités triviales d'E / S. Ayant copié beaucoup de disques en utilisant dd, je recommande au moins bs=1M, ou même quelque chose comme16M . Si la taille de votre disque n'est pas un multiple exact de la taille de votre bloc, vous laisserez un petit peu de données non écrasées à la fin. c'est une valeur sûre, il n'y a rien du tout, mais si vous voulez être paranoïaque, vous pouvez obtenir manuellement ce dernier bit.

L'utilisation d'une petite taille de bloc (avec /dev/zeroou d'une autre source) vous ralentira, mais ce n'est rien comparé au ralentissement résultant de l'utilisation d'une source de données bloquante /dev/random, comme le suggère la réponse acceptée au moment de la rédaction. Le but de /dev/randomest de générer des données d' entropie maximale , et non de générer beaucoup de données. Ce n'est pas simplement que c'est lent, mais ça tire d'un pool d'entropie de taille limitée, et le pool ne se remplit pas très rapidement (surtout si vous ne faites rien d'autre avec le système).

Lorsque le pool est épuisé, la lecture de /dev/randombloquera, refusant de fournir d'autres données jusqu'à ce que le pool se remplisse. Vous utilisez /dev/randompour des choses comme les clés cryptographiques à long terme, pas pour les données en vrac. Essayer de tirer un demi-téraoctet /dev/randomest une idée absolument terrible. Si vous voulez beaucoup de données à entropie élevée, vous devez les utiliser à la /dev/urandomplace . Il utilise des générateurs pseudo-aléatoires pour étendre le pool d'entropie à une taille arbitraire, abandonnant un peu d'entropie en échange de la garantie qu'une lecture continue aboutira dans un délai raisonnable.