Oups le B (comme Balayage) était probablement en trop, c’est sorti tout seul. Je pensais à ça. 
Cela dit le Mec En Bleu est une excellente interprétation aussi ! 
J’avais bien compris ça ! Je pense que j’ai eu assez de “jugeote” pour le faire en root … En fait je n’ai jamais vraiment cherché à être absolument sûr que toutes ces données étaient bien effacées (au fond je m’en fiche, je jouais à 24h chrono dans mon coin !) je le pensais pourtant. On en apprend tous les jours … c’est ça qui est bien
Bah ! je suis sûr ( 
) qu’il y a un autre moyen que celui évoqué par Syam … mais j’ai pas le temps de chercher ! hummm , voyons ? quand je serais moine j’aurais le temps !
Oups le B (comme Balayage) était probablement en trop, c’est sorti tout seul. Je pensais à ça.
Cela dit le Mec En Bleu est une excellente interprétation aussi ! [/quote]
J’adore ! la science, c’est beau et con à la fois !
Sur ce je vous laisse sur ce topic, les pompiers m’appellent !
Euh… Sauf erreur grossière de ma part l’instrument sur la photo ne ressemble pas à un microscope électronique mais à un banal microscope optique binoculaire. Il y a d’autres informations dans ce “reportage” qui me laissent dubitatif. La plus “grosse” :
De quoi surprendre quiconque a déjà vu un plateau (c’est épais) et une tête (c’est tout fin) de disque dur !
Je n’ai donné ce lien que parce que c’était le premier en réponse à la requête “<nom de société> microscope”, pour tout t’avouer j’y ai à peine jeté un coup d’œil. Mea maxima culpa. 
Mais je connais la société en question et je sais qu’ils utilisent des microscopes électroniques pour la récupération de données (on était voisins à une époque).
Salut,
Je le savais 
j’ai retrouvé …
Grosso modo oui. En vrai pour comprendre ce qu’il se passe il faut savoir ce qu’est un fichier.
Un fichier c’est un volume de données quelconque et un ensemble de méta-données (droits, date, etc). Le système gère différemment les deux parties.
La première partie est stockée d’une manière différentes en fonction du système de fichier, on s’en fout un peu. Ce qui est intéressant c’est les métadonnées. Elles sont stockée différemment car elles sont utilisées par le système. Elles sont regroupée dans une inode.
Quand on prend un fichier, /etc/passwd par exemple, le système d’exploitation l’associe à une inode. Celle-ci est accessible permet ensuite de retrouver l’ensemble du fichier. La commande ln, quand elle n’est pas utilisée avec l’option -s, permet de créer un nouveau chemin associer à ce même inode. Ainsi Quand on modifie l’un des deux fichiers, les deux sont modifiés.
$ cat > /tmp/coucou
salut c'est moi
$ ln /tmp/coucou /tmp/hello
$ less -FSRX /tmp/hello
salut c'est moi
$ ls -l /tmp
-rw-r--r-- 2 michel michel 16 27 oct. 23:02 coucou
-rw-r--r-- 2 michel michel 16 27 oct. 23:02 hello
$ cat >> /tmp/hello
non je rigole
$ cat /tmp/coucou
salut c'est moi
non je rigole
La seconde colonne de ls -l donne le nombre de liens qui pointe vers cet inode.
L’opération de suppression d’un fichier se fait par l’appel système unlink() qui se content de supprimer un lien. Ainsi pour mon fichier /tmp/hello :
$ rm /tmp/hello
$ ls /tmp
coucou
$ cat /tmp/coucou
salut c'est moi
non je rigole
Quand le nombre de liens arrive à 0, le système va supprimer l’inode (et encore je suis pas sûr), mais il ne touchera pas au reste du fichier. C’est mieux pour les performances.
C’est ce qui a posé des problèmes avec les SSD. Comme ils ont une couche logicielle à eux et que le système d’exploitation en luis disait jamais quel blocs était libéré, le disque se remplissait. La fonction trim a permis de corriger le tire et la fonction bigtrim de l’améliorer encore.
Au passage quand tu fais un mv et que tu reste dans la même partition la commande se contente de créer un nouveau lien et de supprimer l’ancien (tu a l’impression de déplacer 200Gio en une fraction de seconde).
Si tu veux vraiment supprimer un fichier je te conseil d’aller voir du coté de shred (le man est très clair).[/quote]
recuperation-fichier-supprime-par-erreur-t35928.html#p362619
En fait j’ai fait quelques recherches depuis l’autre jour sur ce sujet, et on peut sans problème monter un EXT3 en EXT2, il n’y a donc plus de
problèmes liés à la journalisation, reste tout de même les pb des SSD évoqués par Syam et la nécessité d’être root évoqué par
PascalHambourg pour la manip “Gros_fichier” que je suggérais ( avant d’entrer dans les ordres … )
Merci Loreleil pour le wipe que je ne connaissais pas
L’ultime solution étant le chiffrage des données avant leur écriture sur un disque ( surtout SSD si j’ai bien compris ) parce que
dans ce cas qu’est-ce que ça peut bien faire que les fichiers soient récupérables ? )
voici la manip que j’ai testé aujourd’hui pour monter mon home en EXT2 et accéder à mom rep perso chiffré avec eCryptfs, ça marche,
mais si les données sont chiffrées ce n’est qu’une perte de temps de faire tout ça, mais ça m’intéressait d’essayer ça, je vous donne cette
manip si ça vous intéresse :
Bonne journée
[code]### (re)-démarrer l’ordi
Attendre la bannière de login mais ne pas se logger
au lieu de ça ouvrir un terminal administrateur :
1-> CTRL-ALT-F1
login: root
Password: *****************
2-> puis
mount|grep home
/dev/sda7 on /home type ext3 (noatime,rw)
umount /home
on verifie que la partition est bien demontee
mount|grep home
on monte le home en EXT2 :
mount -t ext2 /dev/sda7 /home
EXT2-fs warning (device sda7): ext2_fill_super: mounting ext3 filesystem as ext2
on vérifie:
mount|grep home
/dev/sda7 on /home type ext2 (rw)
Il n’y a actuellement plus de journalisation sur cette partition
3-> si ton repertoire personnel n’est pas crypté tu peux directement
y acceder en root pour executer “shred” ou wipe ou dd + rm sur les fichiers
que tu veux eradiquer
shred , wipe , dd + /bin/rm
4-> si ton repertoire perso est crypté avec eCryptfs ( comme le mien )
alors ALT-F2
login: username
Passwd: ****************
ce qui aura pour effet de permettre le montage de tes données chiffrées
mount | grep home
/dev/sda7 on /home type ext2 (rw)
/home/.ecryptfs/toto/.Private on /home/toto type ecryptfs (rw,nosuid,nodev,noatime,ecryptfs_sig=,ecryptfs_cipher=,ecryptfs_key_bytes=**,ecryptfs_fnek_sig=***,ecryptfs_unlink_sigs,user=toto-deb)
5-> idem 3, tu peux maintenant accéder à tes données perso chiffrées
6-> une fois que tu as fini, sors proprement de ta session utilisateur, puis dans ta console
root
sync (pas obligatoire)
reboot
7-> si tu utilises d’autres méthodes de chiffrage de tes données, je ne peux pas t’aider
d’avantage, je ne connais pas 
[/code]
Et si on utilisait une telle méthode:
disque dur 1: système principale debian
disque dur 2: vide non utiliser
1 étape: utilisation du système sur le disque dur 1, utilisation normal, donc faire des suppressions normal avec rm ect.
2 étape: après X temps ou X raison, installation du système sur le disque 2, démarrer avec, monter le disque dur 1, copie nos données du disque dur 1 au système du disque dur 2.
3 étape: utiliser des méthodes comme dd sur le disque dur 1.
4 étape: après X temps ou X raison, installation du système sur le disque 1, démarrer avec, monter le disque dur 2, copie nos données du disque dur 2 au système du disque dur 1.
5 étape: utiliser des méthodes comme dd sur le disque dur 2.
…
…
.
Cet méthode peut-être efficace, mais juste une question qui me pertube qui change le résultat:
Lors de la copie des données du disque dur 1 au disque dur 2, est-ce qu’on copie juste les données normal non éffacé ou on copie les données normal non éffacé + les données dite éffacé mais pas réel ?
Normalement oui si on fait une copie des fichiers existants, seul leur contenu sera copié.
En revanche si on copie le contenu brut de la partition, on copie tout, y compris les restes des fichiers supprimés.
Donc monter la partition avec son système de fichier puis copier/coller les données normal, et on est tranquille 