Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

perte de LVM sur un volume raid

15 réponses
Avatar
Goldy
Bonjour,

J'ouvre un nouveau thread suite au problème dont j'ai fait part dans le
thread nommé "Problème grub suite à maj du noyaux". En voulant chrooter
mon système sur un live cd, j'ai accidentellement abimé mon raid 5. Un
disque s'est retrouvé en dehors de la grappe, disque que j'ai réussi à
réintrégrer et qui a été recontruit par mdadm en quelques heures.

Sur ce raid est configurer un volume LVM, seulement, une fois le disque
reconstruit et réintégré dans le raid5, les utilitaires LVM ont été
incapables d'identifier ce raid comme étant un volume LVM.

Je crains avoir perdu 1,5To de donnés. J'ai lancé l'installateur debian
pour voir ce qu'il en était. Celui-ci me détectait encore il y a peu la
totalité des volumes automatiquement (j'avais essayé d'utiliser la
console de l'installateur pour chrooter le système, mais même si j'avais
correctement accès au système, j'étais limité par les commandes de
l'installeur et je n'arrivais à rien). Hors maintenant, il reconnait
bien le volume raid mais plus le volume LMV.

Je ne sais pas quoi faire pour tenter de récupérer ces volumes, il est
fort probable qu'ils n'aient pas été effacés (je ne pense pas qu'un
volume raid soit si fragile à une simple erreur de destination) mais je
sais pas quoi faire pour me sortir de cette situation, plus je cherche
moins je trouve, et je suis véritablement angoissé à l'idée que la
totalité des données présentes sur ce disque aient pu être effacées à la
suite d'une simple erreur de grub que je n'ai pas pu résoudre de part
mon incompétence, et surtout l'idée que je puisse faire une connerie
mettant définitivement un terme à la sauvegarde de données qui me sont
véritablement chères. Il n'y a pas vraiment de données importantes dans
ce serveur, seulement de l'affectif (musique que j'ai enregistré, rush
et montage des films que j'ai tournés, photos que j'ai prises),
seulement l'idée que ces données puissent disparaitre est
particulièrement douloureux pour moi.


Juste pour information, l'erreur que j'ai fait et qui a posé problème à
mon volume raid, c'est que j'ai fait par erreur "mdadm --assemble
/dev/sda1", alors qu'il faut donner comme destination /dev/md0 ou autre.
Quand je l'ai monté le raid n'était assemblé qu'avec 4 disques sur 5.
Même après un reboot, le disque sda1 était toujours en dehors de la
grappe, j'ai donc réintégré le volume avec "mdadm --manage /dev/md0
--add /dev/sda1", ce qui a eu pour effet d'ajouter le disque en spare et
de reconstruire le raid, donc je ne pense décemment pas que le volume
raid ait été corrompu par cette manipulation, du moins je l'espère.

Voilà, j'espère que quelqu'un pourra me donner un conseil utile pour
faire face à cette difficulté.

Sinon je pense que je suis bon m'exiler dans un monastère pour les vingt
prochaines années (le temps de faire mon deuil).

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org

10 réponses

1 2
Avatar
Jean-Yves F. Barbier
Goldy a écrit :
...
l'installeur et je n'arrivais à rien). Hors maintenant, il reconnait
bien le volume raid mais plus le volume LMV.



C'est pourquoi RAID-5 est fortement déconseillé, au profit de RAID-1 ou 10
(V. baarf.com)

Je ne sais pas quoi faire pour tenter de récupérer ces volumes, il est
fort probable qu'ils n'aient pas été effacés (je ne pense pas qu'un
volume raid soit si fragile à une simple erreur de destination) mais je



ça n'est pas RAID qui est sensible, c'est LVM

sais pas quoi faire pour me sortir de cette situation, plus je cherche
moins je trouve, et je suis véritablement angoissé à l'idée que la
totalité des données présentes sur ce disque aient pu être effacées à la
suite d'une simple erreur de grub que je n'ai pas pu résoudre de part
mon incompétence, et surtout l'idée que je puisse faire une connerie
mettant définitivement un terme à la sauvegarde de données qui me sont
véritablement chères. Il n'y a pas vraiment de données importantes dans
ce serveur, seulement de l'affectif (musique que j'ai enregistré, rush
et montage des films que j'ai tournés, photos que j'ai prises),
seulement l'idée que ces données puissent disparaitre est
particulièrement douloureux pour moi.



RAID n'est pas un remplacement de backups standards et réguliers,
pas plus qu'un HD ne peut servir de support de backup fiable.

...
Voilà, j'espère que quelqu'un pourra me donner un conseil utile pour
faire face à cette difficulté.

Sinon je pense que je suis bon m'exiler dans un monastère pour les vingt
prochaines années (le temps de faire mon deuil).



AMA, tu peux préparer la robe de bure, les actes de contrition et le cilice.

--
I never forget a face, but in your case I'll make an exception.
-- Groucho Marx

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Avatar
Goldy
Merci pour le message. Je préfère entendre ça que rien du tout au final.

Mais j'aurais quand même quelques petites questions.

On 15/12/2009 09:49, Jean-Yves F. Barbier wrote:

C'est pourquoi RAID-5 est fortement déconseillé, au profit de RAID-1 ou 10
(V. baarf.com)



J'aimerais comprendre ce qu'il s'est passé. Le volume a été réparé par
raid sans qu'il y ait d'erreur, le problème aurait été le même en cas de
remplacement d'un disque défaillant ?

J'ai parcouru le lien (mon anglais ne me permet pas de saisir
l'intégralité du document sur le raid-5), mais j'ai bien compris le
problème de risque au moment de la reconstruction. Or je pense que s'il
y avait eu un problème de cet ordre, j'aurais eu une erreur au moment de
la reconstruction, mdadm me disait que tout était en ordre.


ça n'est pas RAID qui est sensible, c'est LVM



J'aimerais bien avoir quelques informations supplémentaires également.


RAID n'est pas un remplacement de backups standards et réguliers,
pas plus qu'un HD ne peut servir de support de backup fiable.



On entends ceci et cela, mais j'aimerais bien savoir ce qu'est un
support de backup fiable. Les supports optiques de dégradent, les DAT
n'existent plus et se dégradent également, ma logique voudrait que le
meilleurs moyen de conserver des données soit la redondance, raid5 me
parraissait un moyen assez commode d'y parvenir, tout en permettant à
ces données d'être accessible.



AMA, tu peux préparer la robe de bure, les actes de contrition et le cilice.




C'est d'ailleurs ce que je vais faire aujourd'hui même. Je pars
m'exhiller dans le Berry (ha le Berry...) jusqu'à l'année prochaine. Les
éventuels messages laissé sur ce thread seront consulté à mon tout
autant éventuel retour à la civilisation.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Avatar
Jean-Yves F. Barbier
Goldy a écrit :
Merci pour le message. Je préfère entendre ça que rien du tout au final.

Mais j'aurais quand même quelques petites questions.

On 15/12/2009 09:49, Jean-Yves F. Barbier wrote:

C'est pourquoi RAID-5 est fortement déconseillé, au profit de RAID-1 ou 10
(V. baarf.com)



J'aimerais comprendre ce qu'il s'est passé. Le volume a été réparé par
raid sans qu'il y ait d'erreur, le problème aurait été le même en cas de
remplacement d'un disque défaillant ?



Oui, à condition toutefois que le disque de spare ait été correctement
testé pour les secteurs défectueux (la structure de RAID dans Linux
fait qu'un secteur défectueux et non-remplaçable par la logique du HD
entraîne un kick-out du HD.)

J'ai parcouru le lien (mon anglais ne me permet pas de saisir
l'intégralité du document sur le raid-5), mais j'ai bien compris le
problème de risque au moment de la reconstruction. Or je pense que s'il
y avait eu un problème de cet ordre, j'aurais eu une erreur au moment de
la reconstruction, mdadm me disait que tout était en ordre.



pas que ça: vitesse, reconstruction; en bref c'est tout le RAID-5 qui est
mis en cause sur ce site.

ça n'est pas RAID qui est sensible, c'est LVM



J'aimerais bien avoir quelques informations supplémentaires également.



Ben j'en ai pas, je suis juste un des multiples ex-utilisateurs de LVM
ayant aussi subit une perte de donnée et qui jura, mais un peu tard,
que l'on ne l'y prendrais plus.

RAID n'est pas un remplacement de backups standards et réguliers,
pas plus qu'un HD ne peut servir de support de backup fiable.



On entends ceci et cela, mais j'aimerais bien savoir ce qu'est un
support de backup fiable. Les supports optiques de dégradent, les DAT
n'existent plus et se dégradent également, ma logique voudrait que le
meilleurs moyen de conserver des données soit la redondance, raid5 me
parraissait un moyen assez commode d'y parvenir, tout en permettant à
ces données d'être accessible.



Actuellement (et depuis des lustres), seule la bande est un support
fiable; c'est d'ailleurs la pub des vendeurs qui te présentent une
cartouche à moitié crâmée, la démonte, remettent la bobine dans un
cadre neuf et relisent les données.

Evidemment, ça a un coût (SCSI + faible diffusion), mais les prix
ont beaucoup chûtés ces dernières années (on trouve un ULTRIUM pour
~€1500HT en double hauteur, et des cartouches de 800/1600 GB
pour ~€35HT)

Les cartouches sont en général garanties à vie; le système ULTRIUM
(ou AIT, mais je n'ai pas confiance dans SONY, yaka voir ce qui se
passait avec les DAT) enregistre les données un peu comme un scope
(têtes rotatives) et décide de lui-même s'il faut compresser ou non
les données (par test auto interne.)

Retrouver un fichier sur une cartouche prend moins de 70 sec. après
insertion.

AMA, tu peux préparer la robe de bure, les actes de contrition et le cilice.




C'est d'ailleurs ce que je vais faire aujourd'hui même. Je pars
m'exhiller dans le Berry (ha le Berry...) jusqu'à l'année prochaine. Les



Y'a déjà l'Internet là bas?? (j'ai un pote qui a eu son premier job
d'ingé à bourges, j'ai bien cru qu'il allait se flinguer: tout son fric
est passé en retour vers la bretagne dès qu'il le pouvait)

éventuels messages laissé sur ce thread seront consulté à mon tout
autant éventuel retour à la civilisation.



T'inquiètes pas, il sera au chaud, sur RAID...

--
When God created man, She was only testing.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Avatar
Goldy
On 15/12/2009 12:04, Jean-Yves F. Barbier wrote:

Ben j'en ai pas, je suis juste un des multiples ex-utilisateurs de LVM
ayant aussi subit une perte de donnée et qui jura, mais un peu tard,
que l'on ne l'y prendrais plus.



J'essaierai quand même en rentrant de voir si il n'existe pas malgré
tout un moyen quelconque de récupérer quelque chose sur ce raid.

Autant je peux comprendre que la structure de LVM puisse être cassée,
mais que la totalité des données aient totalement disparues et soient
impossible à récupérer me parait assez improbable en l'absence d'erreur
manifeste sur ce raid.

Enfin si jamais y'a vraiment rien à faire, je pense que je n'aurais même
pas besoin de bande avant un moment. Ces données représentait 7 ans de
ma vie, j'avais accumulé 1,5To de donnés sur cette période, des
conneries post-adoléscente sur mes premiers PC (de la musique, un voyage
à tokyo, une collection giganteste de manga hentai) au développement
plus récemment que je faisais modestement en bash et en php, mais que
j'étais très fière d'exécuter. Des données que j'avais copié de disque
dur en disque dur au fur et à mesure que ces derniers tombaient en
panne, avec toujours la chance de pouvoir y parvenir. J'avais acheté ce
serveur pour enfin tout stocker dans un endroit un peu plus sécurisé.
Plus que les données, c'est tout le travail que ça a représenté qui
s'envole autant que les souvenirs qui y étaient associés.

J'ai la chance d'avoir encore quelques bribe sur mon laptop, je pourrais
au moins continuer à faire un peu de développement.


Y'a déjà l'Internet là bas??



Non justement, d'où mon isolement le plus complet de la civilisation
neerdiste et geekéenne.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Avatar
Vincent Danjean
Goldy wrote:
On 15/12/2009 12:04, Jean-Yves F. Barbier wrote:

Ben j'en ai pas, je suis juste un des multiples ex-utilisateurs de LVM
ayant aussi subit une perte de donnée et qui jura, mais un peu tard,
que l'on ne l'y prendrais plus.



J'essaierai quand même en rentrant de voir si il n'existe pas malgré
tout un moyen quelconque de récupérer quelque chose sur ce raid.



La première chose à faire, c'est une copie de l'intégralité du contenu
de ton volume RAID (avant de faire une autre bêtise).

Après, tu peux t'amuser.

Si ton LVM avait des LV créés initialement et pas retouchés depuis, les
"secteurs" (de 4 Mo ?) du LVM ont dû être assignés dans l'ordre. Tu dois
donc pouvoir recréer des LV identiques et/ou jouer avec dd pour extraire
tes LV dans un fichier et utiliser "mount -o loop ..." pour regarder tes
données.
Suivant la difficulté et ta persévérance, il doit aussi être possible de
regarder les données au début des LV pour voir la taille du FS.
Il existe des outils de reconstruction de table de partition (probablement
par recherche de marqueurs initiaux de FS). Ça peut éventuellement être
utile dans ton cas (aucune idée : je n'en ai jamais utilisé, je ne sais
pas ce qu'ils peuvent faire/identifier exactement)

Cordialement,
Vincent

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Avatar
Frédéric Massot
Jean-Yves F. Barbier a écrit :
[...]

Oui, à condition toutefois que le disque de spare ait été correctement
testé pour les secteurs défectueux (la structure de RAID dans Linux
fait qu'un secteur défectueux et non-remplaçable par la logique du HD
entraîne un kick-out du HD.)



Bonjour,

Je rebondis sur ce fil concernant la question du test des secteurs
défectueux.

Pour ma part, je crée une unique partition sur le disque, puis je fais
un "mke2fs -ccv /dev/la_partition_du_nouveau_disque".

Ensuite, lors de l'utilisation du disque je le partionne et format selon
les besoins du serveur, que se soit pour du RAID logiciel Linux ou une
carte 3Ware.

Est-ce que c'est suffisant comme test pour les secteurs défectueux ?


Question subsidiaire, les dev du RAID Linux prévoient-ils quelque chose
pour éviter la sortie d'un disque de la grappe au moindre secteur
défectueux non-remplaçable ?

Merci.
--
============================================= | FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto: |
==========================Þbian=GNU/Linux==
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Avatar
Jean-Yves F. Barbier
Frédéric Massot a écrit :
...
Pour ma part, je crée une unique partition sur le disque, puis je fais
un "mke2fs -ccv /dev/la_partition_du_nouveau_disque".



en fait ça dépend du temps que j'ai devant moi, mais si je peux je teste
pendant au moins 4J en continu.
Par ailleurs, pour un montage fait dans un boîtier standard (install "perso"),
je monte les HDz dans des berceaux réducteurs dans les emplacements 5"1/4
et je bricole un tronc de pyramide, avec des chemises cartonnées, collé au
scotch d'emballage sur le BT et soufflé par un ventilo 80x80.
Ça n'est pas beau mais c'est diablement efficace (-15°C en moyenne,
soit ~35°C en haute sollicitation au lieu de 50°C - qui est dangereusement
proche de la limite acceptable par des HDz standards)

Ensuite, lors de l'utilisation du disque je le partionne et format selon
les besoins du serveur, que se soit pour du RAID logiciel Linux ou une
carte 3Ware.



Normalement avec une carte on utilise l'utilitaire de son BIOS.


Question subsidiaire, les dev du RAID Linux prévoient-ils quelque chose
pour éviter la sortie d'un disque de la grappe au moindre secteur
défectueux non-remplaçable ?



à poser aux devs; mais il-y-a peu de chances: le fait d'aller chercher un
secteur à dash ralentirait trop l'array, sans compter la complexité induite
dans le code.
RAID assure la redondance des données, PAS leur intégrité, d'où l'intérêt
de bien tester avant mise en Sce.
(pour ça, il existe un truc-bidule-chose appelé backup, qui ne se fait
*jamais* sur un HD (ou alors sur un serveur)...)

--
You will be dead within a year.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Avatar
Frédéric Massot
Jean-Yves F. Barbier a écrit :
Frédéric Massot a écrit :
...
Pour ma part, je crée une unique partition sur le disque, puis je fais
un "mke2fs -ccv /dev/la_partition_du_nouveau_disque".



en fait ça dépend du temps que j'ai devant moi, mais si je peux je teste
pendant au moins 4J en continu.



Et tu testes avec quel commande ?


à poser aux devs; mais il-y-a peu de chances: le fait d'aller chercher un
secteur à dash ralentirait trop l'array, sans compter la complexité induite
dans le code.
RAID assure la redondance des données, PAS leur intégrité, d'où l'intérêt
de bien tester avant mise en Sce.
(pour ça, il existe un truc-bidule-chose appelé backup, qui ne se fait
*jamais* sur un HD (ou alors sur un serveur)...)



Et oui, j'utilise un serveur de backup avec BackupPC. :o)

C'est con, mais sur ce serveur de backup, j'ai déjà eu le souci d'un
(voir deux en une nuit) disque qui se fait éjecté de la grappe. Un
"madadm --add" et ça repart, mais c'est assez gênant pour juste un
secteur qui déconne.



--
============================================= | FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto: |
==========================Þbian=GNU/Linux==
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Avatar
Jean-Yves F. Barbier
Frédéric Massot a écrit :
Jean-Yves F. Barbier a écrit :
Frédéric Massot a écrit :
...
Pour ma part, je crée une unique partition sur le disque, puis je fais
un "mke2fs -ccv /dev/la_partition_du_nouveau_disque".


en fait ça dépend du temps que j'ai devant moi, mais si je peux je teste
pendant au moins 4J en continu.



Et tu testes avec quelLE commande ?



la même, relancée dès qu'elle est terminée.

...
C'est con, mais sur ce serveur de backup, j'ai déjà eu le souci d'un
(voir deux en une nuit) disque qui se fait éjectER de la grappe. Un
"madadm --add" et ça repart, mais c'est assez gênant pour juste un
secteur qui déconne.



c'est le prix à payer, et dit-toi que c'est pareil dans un datacenter
(bon, le budget disques est sensiblement différent cependant)

--
Matrimony is the root of all evil.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Avatar
Goldy
Je suis de retour à la civilisation depuis quelques jours, je ne sais
pas si reposter dans ce thread après autants de jours aura écho auprès
de ses lecteurs, mais je vais quand même donner suite car ce qui
m'arrive me semble être important à diffuser pour les utilisateurs
d'installations semblables à la mienne.

On 16/12/2009 03:31, Vincent Danjean wrote:
La première chose à faire, c'est une copie de l'intégralité du contenu
de ton volume RAID (avant de faire une autre bêtise).



Malheuresement, trouver un volume de 2to permettant de faire une
sauvegarde n'est pas des plus aisée, donc je vais malheuresement devoir
m'en passer.


Après, tu peux t'amuser.

Si ton LVM avait des LV créés initialement et pas retouchés depuis, les
"secteurs" (de 4 Mo ?) du LVM ont dû être assignés dans l'ordre. Tu dois
donc pouvoir recréer des LV identiques et/ou jouer avec dd pour extraire
tes LV dans un fichier et utiliser "mount -o loop ..." pour regarder tes
données.
Suivant la difficulté et ta persévérance, il doit aussi être possible de
regarder les données au début des LV pour voir la taille du FS.
Il existe des outils de reconstruction de table de partition (probablement
par recherche de marqueurs initiaux de FS). Ça peut éventuellement être
utile dans ton cas (aucune idée : je n'en ai jamais utilisé, je ne sais
pas ce qu'ils peuvent faire/identifier exactement)



Je suis en train de faire tourner testdick sur le volume raid. Il a
identifié quelques LV ainsi qu'une partition LUKS (LVM contenait 3
partitions, root de 16go était en reiserfs, une swap de 2go, et tout le
reste était une partition chiffrée luks contenant /home).

Il manque de la documentation pour l'utilisation de testdisk avec raid
et lvm, je ne sais pas alors si une partition détecté est valide ou pas
ni si je peux me permettre de la réparer avec l'outils. Et surtout le
fait de ne pas pouvoir stocker les données sur un autre volume m'oblige
à travailler directement sur le volume raid, au risque de détruire
définitivement les données présente dessus, LUKS n'aide pas non plus
pour la récupération, certaines données aléatoires étant identifiés par
testdisk comme étant de possibles partitions exotiques.

En tout cas, ce qui s'est passé avec ce volume raid est visiblement à
mettre sur le compte d'une faiblesse de LVM ou RAID (ou les deux), car
les données ont été corrompus sans que j'intervienne dessus avec un
outils qui aurait pu les corrompre. Ça me fait un peu penser à Linus qui
perdit une bonne partie du code de développement du noyaux linux à son
tout début car il avait redirigé un son vers son disque dur au lieux de
sa carte son, c'est le genre de faiblesse qu'on ne devrait plus avoir
aujourd'hui. C'est assez troublant en tout cas.

J'ai trouvé sur la liste une série de message concernant testdisk et
lvm, je ne les ai pas encore lu (car ils sont assez mal agencés) mais je
vais les parcourir, en espérant trouver une information qui m'aidera à
interpréter la sortie de testdisk (je suis en train de refaire une
éniemme recherche appronfondie avec l'outils, ce qui prend plusieurs
heures à chaque fois).


Cordialement,
Vincent




Merci Vincent pour ton message en tout cas.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
1 2