Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

effacer disque externe

bbenn

Salut,

je souhaite effacer un disque externe afin qu'il soit impossible de pouvoir y récupérer les fichiers qui s'y trouvent (rien de spectaculaire à cacher, juste ma vie privée)
j'ai utilisé pour ça l'outil dcfldd. Si j'ai bien compris, ça efface le disque en y écrivant des 0 partout.
Si on en croit les avis sur net ça semble une bonne solution.
Cela dis j'ai une petite appréhension.
Il m'est déjà arrivé de formater par erreur un disque dur dans lequel j'avais des photos. J'avais alors téléchargé le premier outil venu pour les récupérer et ça m'avait récupéré plus de volume de photos que la taille du disque.
D'avoir enregistrer des nouvelles photos par dessus les anciennes n'avait pas empêché que je récupère les anciennes. C'était il y a 10 ans et c'était sur XP.

Voila pourquoi je me demande si finallement le simple fait d'écrire des 0 partout est suffisant. Avis aux spécialistes 🙂

Shamayo

Effectivement, c'est possible de récupérer des fichiers écrasés plusieurs fois par d'autres.

Ce qui est possible de faire, c'est d'écraser le contenu du disque dur par des suites de 0 et 1 et le faire plusieurs fois. Il y a un outil pour ça mais je ne me souviens plus du nom.

tiramiseb

Tu peux faire ça simplement avec dd, en utilisant comme source le générateur pseudo-aléatoire.

Ça donnerait quelque chose comme :

sudo dd if=/dev/urandom of=/dev/sdh bs=1M

"/dev/sdh" est à remplacer par le périphérique qui correspond au disque.
Et pour en être sûr et certain, tu lance ça plusieurs fois.
Bien sûr, ça prend beaucoup de temps...

bbenn

oh oui c'est déjà mieux de mettre quelque chose d'aléatoire plutôt que des 0
à quoi correspond l'argument bs?

le man ne m’éclaircit pas trop

bs=BYTES
read and write up to BYTES bytes at a time

tiramiseb

read and write up to BYTES bytes at a time

C'est clair, non ? Ça lit et écrit ce nombre d'octets en une fois.

Sinon ça fait octet par octet => performance très faibles, car les matériels de type disque durs ne sont pas fait pour traiter les écritures octet par octet.
Donc là, tu lui dis de faire ça méga-octet par méga-octet.

pingouinux

Bonsoir tiramiseb,
Pour info, si on ne le précise pas, la taille des blocs avec dd est de 512 octets. Ta conclusion reste juste : performance très faible…

PPdM

Salut
Sinon un bon coup de masse dessus c'est aussi efficace et plus rapide.
Plus sérieusement tu veux en faire quoi de ce disque, t'en resservir ou le donner a quelqu'un ?

tiramiseb

Sinon un bon coup de masse dessus c'est aussi efficace et plus rapide.

Ça c'est pas faux. Mais une bonne grosse masse hein, pas une petite massette... 😛

PPdM

bbenn a écritSalut,
J'avais alors téléchargé le premier outil venu pour les récupérer et ça m'avait récupéré plus de volume de photos que la taille du disque.
D'avoir enregistrer des nouvelles photos par dessus les anciennes n'avait pas empêché que je récupère les anciennes. C'était il y a 10 ans et c'était sur XP.

Voila pourquoi je me demande si finallement le simple fait d'écrire des 0 partout est suffisant. Avis aux spécialistes 🙂

Les photos ou les vidéos c'est un peut particulier, étant donné que ce sont de gros fichiers, c'est plus facile a reconstituer qu'une multitude de petit fichiers textes .

bbenn

tiramiseb a écrit
read and write up to BYTES bytes at a time
C'est clair, non ? Ça lit et écrit ce nombre d'octets en une fois.

Sinon ça fait octet par octet => performance très faibles, car les matériels de type disque durs ne sont pas fait pour traiter les écritures octet par octet.
Donc là, tu lui dis de faire ça méga-octet par méga-octet.

non ça n'était pas très clair
ce qu'on gagne en perf on le perd en qualité ou pas du tout?
je m’imagine qu'une tête de disque dur ne peux écrire qu'une seule info à la fois (1 bit quoi) donc je ne conçois pas que l'on puisse écrie 1 Mo d'un coup (sinon que par une succession d'écriture d'une multitude de bit)

bbenn

PPdM a écritSalut
Plus sérieusement tu veux en faire quoi de ce disque, t'en resservir ou le donner a quelqu'un ?

tu te doutes bien que si c'était pour ne pas le confier à qqun je ne m'embêterais pas avec ça 😉

bbenn

PPdM a écrit Les photos ou les vidéos c'est un peut particulier, étant donné que ce sont de gros fichiers, c'est plus facile a reconstituer qu'une multitude de petit fichiers textes .

pourquoi ça?

PPdM

Parceque les logiciels de récupération peuvent plus ou moins recréer les parties manquantes d'un code de plusieurs mégaoctet, mais si il n'y en a que dix et qu'il en manque trois, ben t'as un truc illisible.

melixgaro

salut,

je ne suis pas sûr de proposer une explication très précise mais voilà comment je vois la chose :

Ton disque dur a une mémoire cache. Lorsque l'on écrit des informations sur le disque, l'action d'écriture n'est pas déclenchée dès le premier octet reçu. La mémoire cache se remplit plus ou moins, puis l'écriture démarre et la mémoire cache se vide. Puis un nouveau bloc d'octets est transmis etc etc.

Ici, la commande dd lit 1MB sur /dev/urandom, les transmet au disque et lorsque les 1MB sont reçus, l'écriture démarre.

bbenn

PPdM a écritParceque les logiciels de récupération peuvent plus ou moins recréer les parties manquantes d'un code de plusieurs mégaoctet, mais si il n'y en a que dix et qu'il en manque trois, ben t'as un truc illisible.

c'est difficile à concevoir: si tu as un fichier contenant tout le dictionnaire dans lequel tu supprimes à la main le mot 'houblon' il va le recréer?

bbenn

melixgaro a écritsalut,

je ne suis pas sûr de proposer une explication très précise mais voilà comment je vois la chose :

Ton disque dur a une mémoire cache. Lorsque l'on écrit des informations sur le disque, l'action d'écriture n'est pas déclenchée dès le premier octet reçu. La mémoire cache se remplit plus ou moins, puis l'écriture démarre et la mémoire cache se vide. Puis un nouveau bloc d'octets est transmis etc etc.

Ici, la commande dd lit 1MB sur /dev/urandom, les transmet au disque et lorsque les 1MB sont reçus, l'écriture démarre.

En effet ça tient la route comme explication.

PPdM

Non justement; mais si tu a un fichier qui décrit une photo et que tu enlevés quelques octets, ton image sera toujours lisible,dans le pire des cas il ne manquera que quelque pixels, et certain logiciels savent calculer les pixels manquant comme, Photoshop ou Gimp, par exemple sans parler des logiciels de compressions / décompressions.

melixgaro

Si tu transmets des blocs de 1kB=1024 octets, il faudra 1024 cycles de lecture-écriture pour écrire 1MB=1024kB, d'où les différences de performance selon le choix de la valeur pour bs.

bbenn

PPdM a écritNon justement; mais si tu a un fichier qui décrit une photo et que tu enlevés quelques octets, ton image sera toujours lisible,dans le pire des cas il ne manquera que quelque pixels, et certain logiciels savent calculer les pixels manquant comme, Photoshop ou Gimp, par exemple sans parler des logiciels de compressions / décompressions.

je ne vois pas trop la différence en fait. si tu photographie une fourmilière et que tu perd un bout ou il y a une fourmi, photoshop ou gimp te recréent la fourmi?

melixgaro

évidemment, le logiciel ne va pas fabriquer de l'information à partir de rien. Dans le cadre d'un logiciel de retouche d'image, l'idée est d'utiliser les pixels adjacents pour remplir le vide (voir interpolation... et aussi théorème de Shannon-Nyquist, etc). Pour reprendre l'exemple du dictionnaire, c'est un peu comme si à partir du mot qui précède et suit houblon, je disais que le mot manquant commence par hou. Pour ta fourmi, le logiciel va sans doute fabriquer un patatoïde sombre... L'idée est de retrouver une information semblable, pas strictement identique. Ne me dis pas que c'est la fourmi qui donne le sens à la photo !

Page suivante »