DDRESCUE pour tentative de copie dique à disque

SIEG · Le 14/02/2020, à 19:25

Salut rmy

Je me suis mal exprimé; il était tard. Je voulais dire utiliser testdisk pour tenter d'accéder aux données. Me le conseilles-tu ?

geole · Le 15/02/2020, à 13:47

Bonjour
Tu peux lancer tesdisk en mettant en entrée la partie récupérée. Testdisk a deux fonctionnalités
1) Il peux rectifier la structure des partitions, Tu as intérêt à ne pas utiliser cette fonctionnalité tant que la copie n'a pas été sauvegardée.
2) Il peut parcourir des structures de fichiers si elles sont cohérentes. Tu peux utiliser cette fonctionnalité sans risque. Il propose alors une possibilité de duplication du contenu ailleurs (Dans une autre partition d'un autre disque). Tu peux utiliser cela sans restriction. C'est une façon de récupérer un maxima de fichiers.

L'idéal serait de lancer les commandes FSCK qui remettraient les partitions accessibles normalement.
NOTA: Si cette action est faite sans avoir préalablement sauvegardé, il faut considérer que ddrescue ne sera plus utilisé.

La récupération des répertoires deviendrait alors classique. Cela permettrait de remettre à ZERO les répertoires récupérés puis de passer à la récupération des zones "hors répertoire" avec le logiciel "photorec.
Cela me semble la façon normale de terminer lorsque la récupération avec ddrescue n'est plus suffisamment productive.

SIEG · Le 15/02/2020, à 21:16

Salut geole

Je ne suis pas un expert de testdisk non plus, j'ai consulté les tuto en ligne. Je suis la procédure : Create/analyse/la partition où j'ai sauvegardé l'image est reconnue. Je sélectionne la commande "p" pour lister les fichiers mais à ce moment dans la liste il n'y a que le fichier "image 3TO" qui est listé une dizaine de fois. rien d'autre n'est accessible.

La commande dont tu me parles "FSCK" est une commande à utiliser sur tesdisk ou sur le terminal ?

rmy · Le 15/02/2020, à 22:59

Une bonne fois pour toutes : FSCK est POTENTIELLEMENT DESTRUCTEUR ! Il PEUT apporter une solution, mais il peut ausi gravement foutre le bordel. J'aimerais que ça soit entendu et qu'on arrête de conseiller ça, sans prendre un maximum de precaution. C'est insuffisant de dire "le drrescue ne sera plus utilisé".

Il FAUT à ce stade faire un clone de sécurité de ton ddrescue, et ensuite seulement envisager un fsck si tu veux, qui n'a RIEN d'ANODIN.
FSCK, CHKDSK même combat.

SIEG · Le 22/02/2020, à 17:14

Salut à tous. J'ai fait un clone de sécurité. Quelle est la commande exacte que je dois taper ? Est-ce juste FSCK ?

rmy · Le 23/02/2020, à 18:51

fsck s'applique sur la partition, non montée (précision pour d'autres cas) et tu peux utiliser -y si tu veux réparer automatiquement sans sollicitation de l'utilisateur.

https://doc.ubuntu-fr.org/fsck

SIEG · Le 23/02/2020, à 19:21

Merci rmy, je vais tester ça. Le -y se place t'il à la fin de la ligne de commande comme par exemple : "sudo fsck /dev/sdc2-y" ?

rmy · Le 24/02/2020, à 09:34

avec une espace entre /dev/sdc2 et -y

SIEG · Le 26/02/2020, à 02:25

Salut rmy

J'ai suivi le tuto sur la page que tu m'as indiquée.

Je démonte la partition avec la commande :

sudo umount /dev/sdc2

Je fait un lsblk pour vérifier et la partition n'apparaît plus donc ça paraît bon.

Puis je tape la commande

sudo fsck /dev/sdc2 -y

et le terminal me dit

fsck de util-linux 2.31.1

Qu'ai-je manqué ?

rmy · Le 26/02/2020, à 10:00

le terminal te dit quoi d'autre ?
Il redonne juste le prompt tel quel ?

moko138 · Le 26/02/2020, à 10:31

SIEG,
Tu appelles "/dev/sdc2" la partition réceptrice sur disque externe sain.
Cette partition est étiquetée "SPIKE"
Et elle contient en principe un fichier nommé "3To.img" qui est une image de disque entier.

Quand tu dis

J'ai fait un clone de sécurité.

1) est-ce que tu veux bien dire que tu as cloné "sdc2" sur un troisième disque (sain), sommes-nous d'accord ?
L'idée étant que si le fsck "POTENTIELLEMENT DESTRUCTEUR" (rmy) a détruit le système de fichiers (FS) sur sdc2, on pourra le remplacer (le FS) par son clone.

- -

En #4, bibi a écrit :

comme la lettre attribuée à chaque disque ("c" dans "sdc2", "e" dans "sde") est sujette à fluctuations, et qu'une erreur peut être catastrophique,

2.a) Par conséquent, il faut
- renoncer à ces appellations ;
- lire :

sudo lsblk -o name,fstype,size,label,mountpoint | grep -v loop ; echo -e "\n\t\t\t= = =\nDésignations...\n\t\t...stables\t\t\t                ...instables :"; ls -l /dev/disk/by-id | grep -Evi "\-part[3-9]|Reader|\-part[1-9][0-9]" | awk '{print $9,$11}' | sort -k2 | column -s' ' -t

- en extraire les lignes ressemblant chez soi à :

NAME    FSTYPE    SIZE LABEL             MOUNTPOINT
├─sdc2  ntfs      3,3T SPIKE             /media/login/SPIKE1

			= = =
Désignations...
		...stables			                ...instables :
wwn-0x5000abcde1234567-part2                                          ../../sdc2

et remplacer définitivement dans les commandes à exécution longue ou différée
l'appellation changeante /dev/sdc2
par
l'appellation stable /dev/disk/by-id/wwn-0x5000abcde1234567-part2
Et de même pour /dev/sde (*).

Donc ta commande fsck -y /dev/sdc2 devient

sudo fsck -yfv /dev/disk/by-id/blablabla-part2

2.b) Mais attention !
Cette commande va (entre autres) vérifier que le fichier (3To.img) est aux bonnes adresses (inoeuds), et, si besoin, corriger ces inoeuds.
Cette commande ne va pas - sauf erreur de ma part - vérifier le contenu du fichier (image de l'ex-disque sde).
Or c'est une partie de ce contenu (le système de fichiers de la partition sdeN) qui t'intéresse...
Pour le vérifier, il faudra donc des commandes intermédiaires.
Et là je laisse la place à rmy.

______
(*) /!\ On notera que

ls -l /dev/disk/by-uuid

est inadéquat à la récupération de données car :
- un disque n'a pas d'uuid ;
et pour un système de fichiers, l'uuid peut être illisible puisque contenu dans un FS illisible, comme on le voit en #10-11.

rmy · Le 26/02/2020, à 10:48

me culpa, le dossier date tellement que je ne me souvenais plus que la destination de ddrescue était un fichier image et non un disque physique.

Dans ce cas, le plus simple est de créer un loopdevice avec le bon offset et la bonne taille sur la position du FS dans l'image, puis de faire un fsck sur ce loopdevice, il me semble.
Je manque cruellement de temps ces jours ci pour suivre la démarche. @Moko, saurais-tu l'aider dans cette démarche ?

sudo losetup /dev/loop[b]X[/b] /dev/pointdemontage/image/nomdufichierimage.img -o offset_en_octets --sizelimit taille_du_FS_en_octets

puis

sudo fsck /dev/loop[b]X[/b] -y

et enfin un mount en readonly sur /dev/loopX.

X est à remplacer par une valeur entre 0 et 7 en fonction des loopdevice déjà utilisés.
Vérifications possible avec

sudo losetup -f

moko138 · Le 26/02/2020, à 11:40

Merci mais tu me surestimes !
Je n'ai jamais compris la notion d'offset.
Je ne comprends pas "la position du FS dans l'image".

Je ne demande pas mieux que d'apprendre, mais de là à, sans expérience, conseiller autrui... !

geole · Le 26/02/2020, à 12:07

Bonjour
Il faudrait tout relire, cependant il est probable que c'est une partition qui a été copiée. Dans ce cas, l'offset est 0.
Si c'est tout le disque, il faut trouver quel était le LBA du début de la partition et multiplier par 512

Je viens de retrouver cet échange - ( https://forum.ubuntu-fr.org/viewtopic.p … #p22163179 )
"Je comprends que le disque SDE qui a une taille de 2,7To n'a plus de descriptions de partitions et qu'il faut le dupliquer dans un fichier de la partition SDC2 qui a une taille de 3,3To montée dans le répertoire /media/dudu/SPIKE"

On peut toujours penser que le disque était probablement standard en GPT avec une seule partition commençant au lba 2048.

Sinon cela va être amusant, il y a jamesbad000 qui dispose certainement d'un script capable de faite un audit
Mais on devrait aussi pouvoir utiliser le loop device en entrée de testdisk (à lancer sans le préfixe SUDO!!!!!) pour avoir une idée des partitions probables.

Dernière modification par geole (Le 26/02/2020, à 12:19)

rmy · Le 26/02/2020, à 15:04

Vu les messages précédents c'est bien un disque complet (/dev/sde, anciennement comportant une partion nommée "Spike") qui a été copié vers un fichier image sur un disque de plus grande capacité (lui aussi nommé "SPIKE").
un

sudo sfdisk -luS fichierimage.img

devrait fournir l'état des partitions présentes et leur position/taille en secteurs.

Si il n'y a pas de partition détectée, l'usage de testdisk sur l'image directement est possible pour la rechercher.
Attention, testdisk donne les positions des partitions en C/H/S qu'il faudra convertir en LBA.

geole · Le 26/02/2020, à 16:13

Bonjour rmy
Merci pour la commande sfdisk a lancer avec un fichier comme entrée.

SIEG · Le 06/03/2020, à 02:38

Salut tout le monde.

Désolé pour la réponse tardive mais je n'ai pas eu le temps de m'y remettre avant. Je vois que j'ai déclenché la dissertation des experts

rmy j'ai tenté ta commande

sudo sfdisk -luS fichierimage.img

et la réponse est :

sfdisk: impossible d'ouvrir fichierimage.img: Aucun fichier ou dossier de ce type

Je redonne la liste qui apparaît avec la commande lsblsk

sda      8:0    0  74,5G  0 disk 
└─sda1   8:1    0  74,5G  0 part 
sdb      8:16   0 298,1G  0 disk 
├─sdb1   8:17   0 249,3G  0 part 
└─sdb2   8:18   0  48,9G  0 part /
sdc      8:32   0   7,3T  0 disk 
├─sdc1   8:33   0     4T  0 part /media/dudu/JACK
└─sdc2   8:34   0   3,3T  0 part /media/dudu/SPIKE1
sdd      8:48   1  14,5G  0 disk 
└─sdd1   8:49   1  14,5G  0 part /media/dudu/UBUNTU 18_0
sr0     11:0    1  1024M  0 rom

Je rappelle que le fichier image copié (image DDrescue à 75%) se trouve sur sdc2 soit /media/dudu/SPIKE1

Je rappelle également que conformément aux préconisations de rmy, j'ai copié cette image au cas où la tentative de récupération occasionnerait des imprévus.

Que dois-je faire pour tenter de pouvoir accéder aux données ?

Merci à tous de m'avoir aider jusque là et depuis si longtemps

geole · Le 06/03/2020, à 11:03

Bonjour
1) Se positionner dans le répertoire contenant le fichier

cd  /media/dudu/SPIKE1

2) Vérifier que le fichier y est bien présent

ls  -ls

3) Vérifier sa structure

sudo sfdisk -luS fichierimage.img

J'ai noté image DDrescue à 75% Il me semble qu'il faut s'orienter vers l'utilisation de photorec
a) Trouver la première entrée disponible

 losetup -f

2) Y monter le fichier. J'espère que cette commande sera bonne (Il faut remplacer NN par le numéro trouvé )

sudo losetup /dev/loopNN     /media/dudu/SPIKE1/fichierimage.img

3)

photorec

Dernière modification par geole (Le 06/03/2020, à 11:22)

SIEG · Le 07/03/2020, à 02:53

Salut geole

J'ai suivi ta procédure en 1-2 et 3. Les deux premières commandes ont fonctionné mais pas la troisième; voici ce que j'obtiens :

dudu@dudu-System-Product-Name:~$ cd  /media/dudu/SPIKE1
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ ls  -ls
total 2176912364
2176910140 -rwxrwxrwx 1 dudu dudu 3000592957440 janv. 27 04:10  3To.img
      2216 -rwxrwxrwx 1 dudu dudu       2268170 janv. 27 23:37  3to.log
         8 -rwxrwxrwx 1 dudu dudu          5381 janv. 27 23:37  events.log
         0 drwxrwxrwx 1 dudu dudu             0 janv. 28 22:36 '$RECYCLE.BIN'
         0 drwxrwxrwx 1 dudu dudu             0 sept. 29 20:07 'System Volume Information'
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ sudo sfdisk -luS fichierimage.img
[sudo] Mot de passe de dudu : 
sfdisk: impossible d'ouvrir fichierimage.img: Aucun fichier ou dossier de ce type

Y a t-il encore de l'espoir ?

moko138 · Le 07/03/2020, à 03:07

dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ ls  -ls
2176910140 -rwxrwxrwx 1 dudu dudu 3000592957440 janv. 27 04:10  3To.img

Tu vois bien que ton fichierimage.img s'appelle en fait "3To.img" (et qu'il fait bien 3000 milliards d'octets).

À remplacer partout.

Donc c'est

sudo sfdisk -luS 3To.img

que rmy puis geole t'ont demandé de montrer.

SIEG · Le 07/03/2020, à 03:47

Merci moko138, il est tard et en plus je ne suis pas un spécialiste.

Bon alors voici ce que j'obtiens en suivant la procédure de geole étape par étape

dudu@dudu-System-Product-Name:~$ cd  /media/dudu/SPIKE1
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ ls  -ls
total 2176912364
2176910140 -rwxrwxrwx 1 dudu dudu 3000592957440 janv. 27 04:10  3To.img
      2216 -rwxrwxrwx 1 dudu dudu       2268170 janv. 27 23:37  3to.log
         8 -rwxrwxrwx 1 dudu dudu          5381 janv. 27 23:37  events.log
         0 drwxrwxrwx 1 dudu dudu             0 janv. 28 22:36 '$RECYCLE.BIN'
         0 drwxrwxrwx 1 dudu dudu             0 sept. 29 20:07 'System Volume Information'
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ sudo sfdisk -luS 3To.img
[sudo] Mot de passe de dudu : 
Disque 3To.img : 2,7 TiB, 3000592957440 octets, 5860533120 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x9090d1ce

Périphérique Amorçage Début       Fin  Secteurs Taille Id Type
3To.img1               2048 732566641 732564594 349,3G  7 HPFS/NTFS/exFAT
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ losetup -f
/dev/loop19
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ sudo losetup /dev/loop19     /media/dudu/SPIKE1/3To.img
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$

La dernière commande ne semble pas avoir fait quelquechose pourtant je crois avoir respecté les consignes de geole en substituant les bonnes données dans la ligne de commande...

moko138 · Le 07/03/2020, à 07:32

La dernière commande ne semble pas avoir fait quelquechose

Je me serais bien gardé de te faire faire quoi que ce soit de sensible au coeur de la nuit, parce que c'est à ce moment que, par manque de lucidité, on fait les plus belles choseries !

Mais l'avant-dernière commande, descriptive, donne les infos souhaitées !
- la table de partitions : dos
- les secteurs de début et de fin de la partition unique
- et le système de fichiers (probablement NTFS).

L'aventure continue !...

La dernière commande : en principe, elle a monté la partition !
Faute de l'option --verbose derrière sudo losteup, nous ignorons encore si le montage a réussi ou non, mais vous le vérifierez aisément.

Et rappelle-toi : sauf urgence,
/!\ Ne rien tenter de délicat quand on n'est pas reposé, détendu et disponible !

Dernière modification par moko138 (Le 07/03/2020, à 07:36)

geole · Le 07/03/2020, à 14:29

Bonjour

SIEG a écrit :

Bon alors voici ce que j'obtiens.
 dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ sudo sfdisk -luS 3To.img
Disque 3To.img : 2,7 TiB, 3000592957440 octets, 5860533120 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x9090d1ce

Périphérique Amorçage Début       Fin  Secteurs Taille Id Type
3To.img1               2048 732566641 732564594 349,3G  7 HPFS/NTFS/exFAT
A priori, cette commande montre bien qu'il y a stockage d'une partition dans ce fichier avec son adresse début et son adresse fin ainsi que sa taille
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ losetup -f
/dev/loop19

dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ sudo losetup /dev/loop19     /media/dudu/SPIKE1/3To.img
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ 
La dernière commande ne semble pas avoir fait quelque chose pourtant je crois avoir respecté les consignes de geole en substituant les bonnes données dans la ligne de commande...

Le montage a réussi, autrement, il y aurait certainement eu une erreur de signalée

Je te propose donc de regarder ce qu'il y a dedans comme si c'était une partition réelle
Par exemple avec cette commande

ls -als /dev/loop19

puis tu peux te positionner dans le répertoire que tu préfères et continuer la descente...

Voir celle-ci qui va permettre de vérifier si la structure de fichier a été retrouvée en excellant état ou pas.

ls -Rals /dev/loop19

Avec un peu de chance, tu vas retrouver les répertoires , ce qui t'évitera d'utiliser photorec

NOTA, Je ne connais pas très bien ce type de montage que j'ai proposé sans mettre d'offset. Je ne sais pas s'il faut le mettre -o 1048576 soit 2048*512

SIEG · Le 07/03/2020, à 19:39

Salut geole

Voici ce que j'obtiens avec tes 2 commandes :

dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ ls -als /dev/loop19
0 brw-rw---- 1 root disk 7, 19 mars   7 18:37 /dev/loop19
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$ ls -als /dev/loop19
0 brw-rw---- 1 root disk 7, 19 mars   7 18:37 /dev/loop19
dudu@dudu-System-Product-Name:/media/dudu/SPIKE1$

Je ne sais pas si c'est positif ni comment je peux accéder aux données avec ça mais je suis sûr que ta sagacité va nous aider

Dernière modification par SIEG (Le 07/03/2020, à 19:40)

geole · Le 07/03/2020, à 20:56

Désolé, je me suis trompé. Il fallait à tous les coups faire aussi le montage

sudo mount  -v /dev/loop19    /mnt
 ls  -als /mnt

Comme je m'absente, je te prépare un autre essai si celui du dessus ne donne strictement rien.

sudo umount  /mnt
sudo losetup    -v   -o  1048576    /dev/loop20     /media/dudu/SPIKE1/3To.img
sudo mount  -v  /dev/loop20   /mnt
ls  -als /mnt

AJOUT: Voici un exemple concret (version 18.04) pouvant servir de référence.
1) La commande de sauvetage de la totalité d'un support composé de plusieurs partitions.

sudo ddrescue    -f  -p    /dev/sdb     SDB.img   SDB.log
GNU ddrescue 1.22
Press Ctrl-C to interrupt
Initial status (read from mapfile)
rescued: 65470 kB, tried: 0 B, bad-sector: 0 B, bad areas: 0

     ipos:    4009 MB, non-trimmed:        0 B,  current rate:   4390 kB/s
     opos:    4009 MB, non-scraped:        0 B,  average rate:  21205 kB/s
non-tried:        0 B,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    4009 MB,   bad areas:        0,        run time:      3m  5s
pct rescued:  100.00%, read errors:        0,  remaining time:         n/a
                              time since last successful read:         n/a
Finished

2) Le contrôle (facultatif) de la qualité du fichier.

sudo sfdisk -lV SDB.img
Disque SDB.img : 3,8 GiB, 4009754624 octets, 7831552 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 2B348798-4153-4D79-8916-0BFA6258517E

Périphérique   Début     Fin Secteurs Taille Type
SDB.img1     4943872 7829503  2885632   1,4G Données de base Microsoft
SDB.img2        2048    4095     2048     1M Amorçage BIOS
SDB.img3        4096  503807   499712   244M Système EFI
SDB.img4      503808 4358143  3854336   1,9G Système de fichiers Linux
SDB.img5     4358144 4943871   585728   286M Système de fichiers Linux

Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
Aucune erreur détectée.
Version d'en-tête : 1.0
Using 5 out of 128 partitions.

3) Le montage du fichier en technique loop sur le prochain périphérique disponible et récupération de l'affectation

sudo losetup -P  -v   -f      SDB.img

lsblk | grep loop
loop125              7:125  0   3,8G  0 loop 
├─loop125p1        259:18   0   1,4G  0 loop 
├─loop125p2        259:19   0     1M  0 loop 
├─loop125p3        259:20   0   244M  0 loop 
├─loop125p4        259:21   0   1,9G  0 loop 
└─loop125p5        259:22   0   286M  0 loop

4) Le montage d'une partition et lecture du contenu.

sudo mount /dev/loop124p4    /mnt    -v
mount: /mnt : WARNING: device write-protected, mounted read-only.
mount : /dev/loop124p4 monté sur /mnt.

ls /mnt
boot  casper  dists  EFI  install  isolinux  md5sum.txt  pics  pool  preseed  README.diskdefines  ubuntu

Dernière modification par geole (Le 09/03/2020, à 10:21)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 14/02/2020, à 19:25

Re : DDRESCUE pour tentative de copie dique à disque

#52 Le 15/02/2020, à 13:47

Re : DDRESCUE pour tentative de copie dique à disque

#53 Le 15/02/2020, à 21:16

Re : DDRESCUE pour tentative de copie dique à disque

#54 Le 15/02/2020, à 22:59

Re : DDRESCUE pour tentative de copie dique à disque

#55 Le 22/02/2020, à 17:14

Re : DDRESCUE pour tentative de copie dique à disque

#56 Le 23/02/2020, à 18:51

Re : DDRESCUE pour tentative de copie dique à disque

#57 Le 23/02/2020, à 19:21

Re : DDRESCUE pour tentative de copie dique à disque

#58 Le 24/02/2020, à 09:34

Re : DDRESCUE pour tentative de copie dique à disque

#59 Le 26/02/2020, à 02:25

Re : DDRESCUE pour tentative de copie dique à disque

#60 Le 26/02/2020, à 10:00

Re : DDRESCUE pour tentative de copie dique à disque

#61 Le 26/02/2020, à 10:31

Re : DDRESCUE pour tentative de copie dique à disque

#62 Le 26/02/2020, à 10:48

Re : DDRESCUE pour tentative de copie dique à disque

#63 Le 26/02/2020, à 11:40

Re : DDRESCUE pour tentative de copie dique à disque

#64 Le 26/02/2020, à 12:07

Re : DDRESCUE pour tentative de copie dique à disque

#65 Le 26/02/2020, à 15:04

Re : DDRESCUE pour tentative de copie dique à disque

#66 Le 26/02/2020, à 16:13

Re : DDRESCUE pour tentative de copie dique à disque

#67 Le 06/03/2020, à 02:38

Re : DDRESCUE pour tentative de copie dique à disque

#68 Le 06/03/2020, à 11:03

Re : DDRESCUE pour tentative de copie dique à disque

#69 Le 07/03/2020, à 02:53

Re : DDRESCUE pour tentative de copie dique à disque

#70 Le 07/03/2020, à 03:07

Re : DDRESCUE pour tentative de copie dique à disque

#71 Le 07/03/2020, à 03:47

Re : DDRESCUE pour tentative de copie dique à disque

#72 Le 07/03/2020, à 07:32

Re : DDRESCUE pour tentative de copie dique à disque

#73 Le 07/03/2020, à 14:29

Re : DDRESCUE pour tentative de copie dique à disque

#74 Le 07/03/2020, à 19:39

Re : DDRESCUE pour tentative de copie dique à disque

#75 Le 07/03/2020, à 20:56

Re : DDRESCUE pour tentative de copie dique à disque

Pied de page des forums