J'ai récupéré un disque dur extrait d'un "boîtier multimédia" (je ne
sais plus le nom : un truc sur lequel on stocke des films de vacances et
qu'on branche sur une télé pour les regarder dessus). La personne qui
me l'a confié aimerait récupérer les données qui étaient dessus, si
possible.
Le disque extrait du boîtier est un disque SATA tout ce qu'il a de plus
classique, j'ai branché les deux connecteurs sur une autre
machine, /dev/sdb apparaît mais pas de partitions /dev/sdbx.
J'ai essayé différents logiciels pour essayer de lire son contenu :
- gparted a dit erreur d'entrée/sortie
- fdisk (sur /dev/sdb) : le fichier n'existe pas
- cp (copie de /dev/sdb dans un fichier de /tmp) : la commande se
termine immédiatement, le fichier créé fait 0 octet
(contrairement à la même opération avec /dev/sda).
Ça a l'air foutu ? Je ne sais pas quel est le système de fichiers
dessus, mais je suppose que ne voir aucune partition et ne pas lire le
fichier brut représentant le disque c'est mauvais signe... Ou est-ce
que ça pourrait être tellement exotique que j'ai manqué quelque chose ?
En tous cas, s'obstiner à utiliser un disque déclaré mort par SMART, c'est ainer se créer des ennuis...
à l'époque je n'en avais pas d'autres, il a tenu 10 ans sans que les erreurs smart changent
tu fais comment avec un disque de 4To? même avec 1To c'est pas simple
J'utilise du RAID. Utiliser un disque magnéto-mécanique de plus de 1To sans redondance, c'est l'assurance de subir une perte de données tôt ou tard. Donc soit on redonde, soit on externalise les données sensibles.
la question n'est pas là. J'ai trois copies des mêmes données sur 3 disques de 4,5 et 5 To, mais il y a un décalage (volontaire) dans la recopie - je ne veux pas propager trop vite une erreur éventuelle de manip. donc si un des disques lache, il peut y avoir dessus une (petite) partie des données non recopiée. Je suis prêt à accepter de les perdre, mais pas sans efforts :-) jdd -- http://dodin.org
Le 12/02/2018 à 18:05, Eric Belhomme a écrit :
En tous cas, s'obstiner à utiliser un disque déclaré mort par SMART,
c'est ainer se créer des ennuis...
à l'époque je n'en avais pas d'autres, il a tenu 10 ans sans que les
erreurs smart changent
tu fais comment avec un disque de 4To? même avec 1To c'est pas simple
J'utilise du RAID. Utiliser un disque magnéto-mécanique de plus de 1To
sans redondance, c'est l'assurance de subir une perte de données tôt ou
tard. Donc soit on redonde, soit on externalise les données sensibles.
la question n'est pas là. J'ai trois copies des mêmes données sur 3
disques de 4,5 et 5 To, mais il y a un décalage (volontaire) dans la
recopie - je ne veux pas propager trop vite une erreur éventuelle de manip.
donc si un des disques lache, il peut y avoir dessus une (petite) partie
des données non recopiée. Je suis prêt à accepter de les perdre, mais
pas sans efforts :-)
En tous cas, s'obstiner à utiliser un disque déclaré mort par SMART, c'est ainer se créer des ennuis...
à l'époque je n'en avais pas d'autres, il a tenu 10 ans sans que les erreurs smart changent
tu fais comment avec un disque de 4To? même avec 1To c'est pas simple
J'utilise du RAID. Utiliser un disque magnéto-mécanique de plus de 1To sans redondance, c'est l'assurance de subir une perte de données tôt ou tard. Donc soit on redonde, soit on externalise les données sensibles.
la question n'est pas là. J'ai trois copies des mêmes données sur 3 disques de 4,5 et 5 To, mais il y a un décalage (volontaire) dans la recopie - je ne veux pas propager trop vite une erreur éventuelle de manip. donc si un des disques lache, il peut y avoir dessus une (petite) partie des données non recopiée. Je suis prêt à accepter de les perdre, mais pas sans efforts :-) jdd -- http://dodin.org
Eric Masson
jdd writes: 'Lut
donc si un des disques lache, il peut y avoir dessus une (petite) partie des données non recopiée. Je suis prêt à accepter de les perdre, mais pas sans efforts :-)
En environnement de production, une indisponibilité ou encore une perte de données a un coût immédiat non nul. En bref, il faut définir le besoin, et celui d'un particulier qui bidouille dans son coin n'est qu'un de ceux possibles, et en aucun cas la règle absolue. -- NC> Ben quoi ? C'est déshonorant le GCU ? (Si oui, là, je prendrais des risques inconsidérés...) Pas ce que j'ai dit Mais passer du GCU au GNU.... -+- HP in: <http://www.le-gnu.net> - Grandeur et décadence -+-
jdd <jdd@dodin.org> writes:
'Lut
donc si un des disques lache, il peut y avoir dessus une (petite) partie
des données non recopiée. Je suis prêt à accepter de les perdre, mais
pas sans efforts :-)
En environnement de production, une indisponibilité ou encore une perte
de données a un coût immédiat non nul.
En bref, il faut définir le besoin, et celui d'un particulier qui
bidouille dans son coin n'est qu'un de ceux possibles, et en aucun cas
la règle absolue.
--
NC> Ben quoi ? C'est déshonorant le GCU ? (Si oui, là, je prendrais
des risques inconsidérés...)
Pas ce que j'ai dit Mais passer du GCU au GNU....
-+- HP in: <http://www.le-gnu.net> - Grandeur et décadence -+-
donc si un des disques lache, il peut y avoir dessus une (petite) partie des données non recopiée. Je suis prêt à accepter de les perdre, mais pas sans efforts :-)
En environnement de production, une indisponibilité ou encore une perte de données a un coût immédiat non nul. En bref, il faut définir le besoin, et celui d'un particulier qui bidouille dans son coin n'est qu'un de ceux possibles, et en aucun cas la règle absolue. -- NC> Ben quoi ? C'est déshonorant le GCU ? (Si oui, là, je prendrais des risques inconsidérés...) Pas ce que j'ai dit Mais passer du GCU au GNU.... -+- HP in: <http://www.le-gnu.net> - Grandeur et décadence -+-
jdd
Le 12/02/2018 à 20:02, Eric Masson a écrit :
jdd writes: 'Lut
donc si un des disques lache, il peut y avoir dessus une (petite) partie des données non recopiée. Je suis prêt à accepter de les perdre, mais pas sans efforts :-)
En environnement de production, une indisponibilité ou encore une perte de données a un coût immédiat non nul. En bref, il faut définir le besoin, et celui d'un particulier qui bidouille dans son coin n'est qu'un de ceux possibles, et en aucun cas la règle absolue.
tout à fait d'accord. reste que la perte de données est d'une façon ou d'une autre inévitable et qu'il faut s'y préparer. Le but est de minimiser les conséquences et d'optimiser le rapport cout/résultat le système que j'utilise essaie de moyenner deux risques: celui d'une erreur ou d'une faille qui n'est constatée que tardivement (d'où le délai de copie d'un disque à l'autre) et celui de la perte d'un matériel j'ai aussi une copie du "matériel" le plus important sur mon site web hébergé quelque part sur le net jdd -- http://dodin.org
Le 12/02/2018 à 20:02, Eric Masson a écrit :
jdd <jdd@dodin.org> writes:
'Lut
donc si un des disques lache, il peut y avoir dessus une (petite) partie
des données non recopiée. Je suis prêt à accepter de les perdre, mais
pas sans efforts :-)
En environnement de production, une indisponibilité ou encore une perte
de données a un coût immédiat non nul.
En bref, il faut définir le besoin, et celui d'un particulier qui
bidouille dans son coin n'est qu'un de ceux possibles, et en aucun cas
la règle absolue.
tout à fait d'accord. reste que la perte de données est d'une façon ou
d'une autre inévitable et qu'il faut s'y préparer. Le but est de
minimiser les conséquences et d'optimiser le rapport cout/résultat
le système que j'utilise essaie de moyenner deux risques: celui d'une
erreur ou d'une faille qui n'est constatée que tardivement (d'où le
délai de copie d'un disque à l'autre) et celui de la perte d'un matériel
j'ai aussi une copie du "matériel" le plus important sur mon site web
hébergé quelque part sur le net
donc si un des disques lache, il peut y avoir dessus une (petite) partie des données non recopiée. Je suis prêt à accepter de les perdre, mais pas sans efforts :-)
En environnement de production, une indisponibilité ou encore une perte de données a un coût immédiat non nul. En bref, il faut définir le besoin, et celui d'un particulier qui bidouille dans son coin n'est qu'un de ceux possibles, et en aucun cas la règle absolue.
tout à fait d'accord. reste que la perte de données est d'une façon ou d'une autre inévitable et qu'il faut s'y préparer. Le but est de minimiser les conséquences et d'optimiser le rapport cout/résultat le système que j'utilise essaie de moyenner deux risques: celui d'une erreur ou d'une faille qui n'est constatée que tardivement (d'où le délai de copie d'un disque à l'autre) et celui de la perte d'un matériel j'ai aussi une copie du "matériel" le plus important sur mon site web hébergé quelque part sur le net jdd -- http://dodin.org
Pascal Hambourg
Le 12/02/2018 à 14:02, Yliur a écrit :
Le disque extrait du boîtier est un disque SATA tout ce qu'il a de plus classique, j'ai branché les deux connecteurs sur une autre machine, /dev/sdb apparaît mais pas de partitions /dev/sdbx. J'ai essayé différents logiciels pour essayer de lire son contenu : - gparted a dit erreur d'entrée/sortie - fdisk (sur /dev/sdb) : le fichier n'existe pas - cp (copie de /dev/sdb dans un fichier de /tmp) : la commande se termine immédiatement, le fichier créé fait 0 octet (contrairement à la même opération avec /dev/sda).
On peut voir les messages du noyau relatifs à sdb ?
Le 12/02/2018 à 14:02, Yliur a écrit :
Le disque extrait du boîtier est un disque SATA tout ce qu'il a de plus
classique, j'ai branché les deux connecteurs sur une autre
machine, /dev/sdb apparaît mais pas de partitions /dev/sdbx.
J'ai essayé différents logiciels pour essayer de lire son contenu :
- gparted a dit erreur d'entrée/sortie
- fdisk (sur /dev/sdb) : le fichier n'existe pas
- cp (copie de /dev/sdb dans un fichier de /tmp) : la commande se
termine immédiatement, le fichier créé fait 0 octet
(contrairement à la même opération avec /dev/sda).
On peut voir les messages du noyau relatifs à sdb ?
Le disque extrait du boîtier est un disque SATA tout ce qu'il a de plus classique, j'ai branché les deux connecteurs sur une autre machine, /dev/sdb apparaît mais pas de partitions /dev/sdbx. J'ai essayé différents logiciels pour essayer de lire son contenu : - gparted a dit erreur d'entrée/sortie - fdisk (sur /dev/sdb) : le fichier n'existe pas - cp (copie de /dev/sdb dans un fichier de /tmp) : la commande se termine immédiatement, le fichier créé fait 0 octet (contrairement à la même opération avec /dev/sda).
On peut voir les messages du noyau relatifs à sdb ?
Eric Belhomme
Le Mon, 12 Feb 2018 20:02:34 +0100, Eric Masson a écrit :
En bref, il faut définir le besoin, et celui d'un particulier qui bidouille dans son coin n'est qu'un de ceux possibles, et en aucun cas la règle absolue.
Reste que la restoration des données contenues sur un disque défectueux de grande capacité est très compliquée, et en tout état de cause, nécessite *beaucoup* de ressources, ne serait-ce que pour cloner le disque à /tenter/ de récupérer. On peut retourner le problème comme on veut, si l'on a pas à disposition plusieurs To de stockage, inutile de se lancer dans ce genre d'opération. -- Rico
Le Mon, 12 Feb 2018 20:02:34 +0100, Eric Masson a écrit :
En bref, il faut définir le besoin, et celui d'un particulier qui
bidouille dans son coin n'est qu'un de ceux possibles, et en aucun cas
la règle absolue.
Reste que la restoration des données contenues sur un disque défectueux
de grande capacité est très compliquée, et en tout état de cause,
nécessite *beaucoup* de ressources, ne serait-ce que pour cloner le
disque à /tenter/ de récupérer.
On peut retourner le problème comme on veut, si l'on a pas à disposition
plusieurs To de stockage, inutile de se lancer dans ce genre d'opération.
Le Mon, 12 Feb 2018 20:02:34 +0100, Eric Masson a écrit :
En bref, il faut définir le besoin, et celui d'un particulier qui bidouille dans son coin n'est qu'un de ceux possibles, et en aucun cas la règle absolue.
Reste que la restoration des données contenues sur un disque défectueux de grande capacité est très compliquée, et en tout état de cause, nécessite *beaucoup* de ressources, ne serait-ce que pour cloner le disque à /tenter/ de récupérer. On peut retourner le problème comme on veut, si l'on a pas à disposition plusieurs To de stockage, inutile de se lancer dans ce genre d'opération. -- Rico
Eric Belhomme
Le Mon, 12 Feb 2018 20:22:47 +0100, jdd a écrit :
le système que j'utilise essaie de moyenner deux risques: celui d'une erreur ou d'une faille qui n'est constatée que tardivement (d'où le délai de copie d'un disque à l'autre) et celui de la perte d'un matériel
C'est typyquement pour ce genre de cas que des mecs se sont fait suer à pondre des systèmes comme LVM, ZFS, ou btrfs ! Putôt que tenter vouloir gérer ça avec de bêtes copies par rsync ou archives tar, tu devrais plutôt te tourner du coté du snapshooting et du CoW avec ZFS ou btrfs... A titre personnel, j'ai un NAS à la maison formaté en ZFS6 et mes pools sensibles sont snapshootés et /exportés/ vers un volume de sauvegarde. -- Rico mes 2 cents.
Le Mon, 12 Feb 2018 20:22:47 +0100, jdd a écrit :
le système que j'utilise essaie de moyenner deux risques: celui d'une
erreur ou d'une faille qui n'est constatée que tardivement (d'où le
délai de copie d'un disque à l'autre) et celui de la perte d'un matériel
C'est typyquement pour ce genre de cas que des mecs se sont fait suer à
pondre des systèmes comme LVM, ZFS, ou btrfs !
Putôt que tenter vouloir gérer ça avec de bêtes copies par rsync ou
archives tar, tu devrais plutôt te tourner du coté du snapshooting et du
CoW avec ZFS ou btrfs...
A titre personnel, j'ai un NAS à la maison formaté en ZFS6 et mes pools
sensibles sont snapshootés et /exportés/ vers un volume de sauvegarde.
le système que j'utilise essaie de moyenner deux risques: celui d'une erreur ou d'une faille qui n'est constatée que tardivement (d'où le délai de copie d'un disque à l'autre) et celui de la perte d'un matériel
C'est typyquement pour ce genre de cas que des mecs se sont fait suer à pondre des systèmes comme LVM, ZFS, ou btrfs ! Putôt que tenter vouloir gérer ça avec de bêtes copies par rsync ou archives tar, tu devrais plutôt te tourner du coté du snapshooting et du CoW avec ZFS ou btrfs... A titre personnel, j'ai un NAS à la maison formaté en ZFS6 et mes pools sensibles sont snapshootés et /exportés/ vers un volume de sauvegarde. -- Rico mes 2 cents.
jdd
Le 13/02/2018 à 08:47, Eric Belhomme a écrit :
Putôt que tenter vouloir gérer ça avec de bêtes copies par rsync ou archives tar, tu devrais plutôt te tourner du coté du snapshooting et du CoW avec ZFS ou btrfs...
ajouter une couche de complexité n'est utile que si on la maîtrise bien. Me disques USB, non seulement tournent au point de vue du contenu, mais aussi dans leur position géographique (l'un d'eux est stocké à l'opposé de mon bureau dans la maison dans un coffre anti-feu) les deux autres sont près de moi, mais un des deux est toujours hors ligne (éteint) en pratique j'ai perdu beaucoup plus de données par ma faute que par celle du matériel. Un jour j'ai formaté un des disques de 5To... au lieu d'une carte SD. un coup de fatigue... rien que recopier les data m'a pris presque 24h :-) la dernière fois que j'ai réellement perdu des données, c'était sur un disque de 1To neuf (moins d'un mois) qui a lâché brusquement. Je crois, d'ailleurs, que c'est le seul disque que j'ai perdu sans avertissement :-( jdd -- http://dodin.org
Le 13/02/2018 à 08:47, Eric Belhomme a écrit :
Putôt que tenter vouloir gérer ça avec de bêtes copies par rsync ou
archives tar, tu devrais plutôt te tourner du coté du snapshooting et du
CoW avec ZFS ou btrfs...
ajouter une couche de complexité n'est utile que si on la maîtrise bien.
Me disques USB, non seulement tournent au point de vue du contenu, mais
aussi dans leur position géographique (l'un d'eux est stocké à l'opposé
de mon bureau dans la maison dans un coffre anti-feu)
les deux autres sont près de moi, mais un des deux est toujours hors
ligne (éteint)
en pratique j'ai perdu beaucoup plus de données par ma faute que par
celle du matériel.
Un jour j'ai formaté un des disques de 5To... au lieu d'une carte SD.
un coup de fatigue... rien que recopier les data m'a pris presque 24h :-)
la dernière fois que j'ai réellement perdu des données, c'était sur un
disque de 1To neuf (moins d'un mois) qui a lâché brusquement. Je crois,
d'ailleurs, que c'est le seul disque que j'ai perdu sans avertissement :-(
Putôt que tenter vouloir gérer ça avec de bêtes copies par rsync ou archives tar, tu devrais plutôt te tourner du coté du snapshooting et du CoW avec ZFS ou btrfs...
ajouter une couche de complexité n'est utile que si on la maîtrise bien. Me disques USB, non seulement tournent au point de vue du contenu, mais aussi dans leur position géographique (l'un d'eux est stocké à l'opposé de mon bureau dans la maison dans un coffre anti-feu) les deux autres sont près de moi, mais un des deux est toujours hors ligne (éteint) en pratique j'ai perdu beaucoup plus de données par ma faute que par celle du matériel. Un jour j'ai formaté un des disques de 5To... au lieu d'une carte SD. un coup de fatigue... rien que recopier les data m'a pris presque 24h :-) la dernière fois que j'ai réellement perdu des données, c'était sur un disque de 1To neuf (moins d'un mois) qui a lâché brusquement. Je crois, d'ailleurs, que c'est le seul disque que j'ai perdu sans avertissement :-( jdd -- http://dodin.org
Yliur
Merci pour les remarques/questions, j'essaierai vos suggestions quand j'aurai le disque sous la main et je reviendrai s'il y a du nouveau.
Merci pour les remarques/questions, j'essaierai vos suggestions
quand j'aurai le disque sous la main et je reviendrai s'il y a du
nouveau.
Merci pour les remarques/questions, j'essaierai vos suggestions quand j'aurai le disque sous la main et je reviendrai s'il y a du nouveau.
Yliur
J'ai eu le temps de remettre la main sur ce disque... Les messages du noyau : dmesg | grep sdb [ 3.435325] sd 6:0:0:0: [sdb] Attached SCSI removable disk Et d'autres : smartctl -a /dev/sdb /dev/sdb: Unknown USB bridge [0x0bda:0x0153 (0x5713)] Please specify device type with the -d option. sudo dd if=/dev/sdb of=/tmp/disque-casse dd: impossible d'ouvrir '/dev/sdb': Aucun support trouvé Je précise que sdb apparaît bien adns /dev. Le disque n'est pas reconnu non plus sous Windows. Je suppose qu'il n'y a plus grand chose à en tirer, tant pis, la propriétaire en a fait son deuil. Merci pour votre aide.
J'ai eu le temps de remettre la main sur ce disque...
J'ai eu le temps de remettre la main sur ce disque... Les messages du noyau : dmesg | grep sdb [ 3.435325] sd 6:0:0:0: [sdb] Attached SCSI removable disk Et d'autres : smartctl -a /dev/sdb /dev/sdb: Unknown USB bridge [0x0bda:0x0153 (0x5713)] Please specify device type with the -d option. sudo dd if=/dev/sdb of=/tmp/disque-casse dd: impossible d'ouvrir '/dev/sdb': Aucun support trouvé Je précise que sdb apparaît bien adns /dev. Le disque n'est pas reconnu non plus sous Windows. Je suppose qu'il n'y a plus grand chose à en tirer, tant pis, la propriétaire en a fait son deuil. Merci pour votre aide.
