Recuperation des données d'un HDD de NAS

Finkelstein · Le 19/10/2020, à 20:52

Récupération des fichiers musicaux en cours - J'espere ne pas m'etre trompé ...

Finkelstein · Le 21/10/2020, à 17:02

j'ai du mal faire un truc avec le raid parce que mon montage raid n'est pas accessible

xxx@xxx-yyy:/media/raid$ ls
ls: lecture du répertoire '.': Erreur d'entrée/sortie

Je ne m'en suis pas apercu sur le coup ce qui fait que j'ai lancé photorec avec /media comme repertoire de recup et finalement j'ai ete averti que mon disque etait presque plein

geole · Le 21/10/2020, à 17:30

Bonjour.
Je suis surpris. Que donnent

ls  -ls  /media

journalctl -b | grep err

Finkelstein · Le 21/10/2020, à 18:21

le resultat de ls -ls /media

total 12
4 drwxr-x---+ 2 root root 4096 sept. 17 11:36 ma_femme
4 drwxr-xr-x  4 root root 4096 oct.  19 21:34 raid
4 drwxr-x---+ 2 root root 4096 oct.  21 00:27 moi

le resultat journalctl

oct. 21 17:44:12 steyph-desktop rsyslogd[906]: file '8' write error: No space left on device [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: action 'action 2' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: file '8' write error: No space left on device [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: action 'action 2' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: file '8' write error: No space left on device [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: action 'action 2' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: file '8' write error: No space left on device [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: action 'action 2' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: file '8' write error: No space left on device [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: action 'action 2' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: file '8' write error: No space left on device [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:12 steyph-desktop rsyslogd[906]: action 'action 2' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.32.0 try http://www.rsyslog.com/e/2027 ]
oct. 21 17:44:30 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm ls: error -5 reading directory block
oct. 21 17:45:26 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm scanner: error -5 reading directory block
oct. 21 17:45:59 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm pool: error -5 reading directory block
oct. 21 17:46:11 steyph-desktop systemd-resolved[744]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
oct. 21 17:46:12 steyph-desktop systemd-resolved[744]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
oct. 21 17:51:19 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm Thread Pool Wor: error -5 reading directory block
oct. 21 17:51:25 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm Thread Pool Wor: error -5 reading directory block
oct. 21 17:57:30 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm photorec: error -5 reading directory block
oct. 21 17:58:57 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm pool: error -5 reading directory block
oct. 21 17:59:35 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm ls: error -5 reading directory block
oct. 21 18:12:32 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm Thread Pool Wor: error -5 reading directory block
oct. 21 18:14:33 steyph-desktop gvfsd[1996]: PTP: reading event an error 0x05 occurred
oct. 21 18:17:20 steyph-desktop systemd-resolved[744]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
oct. 21 18:17:20 steyph-desktop systemd-resolved[744]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

J'ai pas tout recopié car je me suis aperçu que la repetition que l'on apercoit deja au debut de ce que j'ai copié, se repete plein de fois

geole · Le 21/10/2020, à 18:29

Je me demande vraiment où la récupération a été faite

oct. 21 17:44:12 steyph-desktop rsyslogd[906]: file '8' write error: No space left on device [v8.32.0 try http://www.rsyslog.com/e/2027 ]

oct. 21 17:51:19 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm Thread Pool Wor: error -5 reading directory block
oct. 21 17:51:25 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm Thread Pool Wor: error -5 reading directory block
oct. 21 17:57:30 steyph-desktop kernel: EXT4-fs warning (device md0): htree_dirblock_to_tree:997: inode #2: lblock 0: comm photorec: error -5 reading directory block

Avais-tu bien fait le montage et créé un répertoire?

Je cherche àcomprendre ce message error -5 reading directory block

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

Finkelstein · Le 21/10/2020, à 18:35

la recuperation a ete faite dans /media, j'ai juste tout viré pour récupérer l'espace disque (au point ou j'en suis, je peux bien recommencer l'opération)

J'ai fait le montage et je suis quasiment certains d'avoir créer le répertoire (du moins j'ai passé les commandes) mais après coup, impossible d'accéder au repertoire. Est ce qu'un disque raid s'accede differement par nautilus ? (d'ailleurs je ne vois pas mon montage dans l'explorateur)

geole · Le 21/10/2020, à 18:45

Un raids de deux partitions est normalement vu par nautilus comme une seule partition montée sur le point de montage /media/raids.
Je suis quand même surpris qu'il se soit suffisamment dégradé en quelques jours pour ne plus être lisible. Mais pourquoi pas.
Que donne

sudo mdadm --detail /dev/md0

Finkelstein · Le 21/10/2020, à 19:26

/dev/md0:
           Version : 1.2
     Creation Time : Mon Oct 19 21:23:13 2020
        Raid Level : raid1
        Array Size : 976431104 (931.20 GiB 999.87 GB)
     Used Dev Size : 976431104 (931.20 GiB 999.87 GB)
      Raid Devices : 2
     Total Devices : 1
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon Oct 19 21:36:22 2020
             State : clean, degraded 
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

    Number   Major   Minor   RaidDevice State
       0       8       49        0      active sync
       -       0        0        1      removed

Si ce n'est pas une mauvaise manip de ma part et qu'il est vraiment devenu illisible, moi aussi je suis etonné d'une si rapide degradation.
Je peux refaire la creation de raid pour etre sur ?

geole · Le 22/10/2020, à 11:12

Bonjour
Je ne pense pas que tu aies lancé une commande mdadm demandant de libérer la seconde partition.... et mettre le raids en mode dégradé.
C'est donc mdadm qui a trouvé que c'était en trop mauvais état. Il ne reste plus attendre d'avoir un autre support externe de qualité pour entreprendre la récupération, Au besoin, tu peux t'entraîner avec une clé USB afin de maîtriser le lieu de récupération

Finkelstein · Le 19/12/2020, à 18:33

Finalement, j'ai abandonné et pris l'option de faire le deuil des fichiers perdus.
J'ai donc utilisé mon nouveau disque dur en tant que NAS.

Merci pour l'aide qui m'a ete apporté : meme si je n'ai pas reussi a tout recuperer, j'ai decouvert de nouveaux outils, de nouvelles commandes : j'en suis donc ressorti grandi !

Une derniere question, cependant : la perte des fichiers m'a fait prendre conscience que je stockais peut etre trop de chose que je pourrais qualifier de "dispensable" mais aussi que si ca arrivais a d'autres fichiers ce serait autrement plus grave. Pour l'instant, je n'ai fait qu'une seule grosse partition sur mon nouveau disque dur mais pour eviter le genre de desagrement qui m'a fait creer ce post je me suis dit que partitionner ce disque en raid logiciel pourrait etre une bonne idée.

Est ce qu'il est donc possible de mettre en place un raid logiciel sur un disque en cours d'activité (avec des fichiers dessus) sans perte ?

Merci encore.

geole · Le 19/12/2020, à 19:03

Bonjour
L'installation d'un raids passe par un formatage, Ce qui dit perte des données.

Il est possible de faire un RAIDS1 avec un seul disque, Cela ne va pas protéger de la perte du firmware ou du moteur ou de la tête de lecture. Mais cela protège des secteurs illisibles.
Voici une démarche de principe.
1) Lancer gparted pour libérer de l'espace disque, il en faut 50 %
2) Créer une partition B avec l'espace libre
3) Créer le raid1 avec la partition B en disant qu'une partition est absente
4) Formater le raids
5) Transférer les données de la partition actuelle dans le raids
6) Formater la partition initiale elle sera la partiton A
7) Ajouter la partiton A au RAID
8) Surveiller la resynchronisation du raids. Lorsque c'est terminé, les données sont en double

Normalement un RAIDS1 se fait avec deux disques,
Voici une démarche de principe.
1) Créer le raid1 avec le second disque en disant que le premier est absent
2) Formater le raids
3) Transférer les données du disque actuel dans le raids
4) Formater le disque actuel
5) Ajouter le disque actuel au RAID
6) Surveiller la resynchronisation du raids. Lorsque c'est terminé, les données sont en double.

Je te laisse réfléchir a cette idée
Classer virtuellement les données en deux catégories: Données indispensables et données "dispensables"
Trouver la taille des données indispensables, la multiplier par deux soit 2T
Diminuer la taille de la partition des données de 2T
Avec l'espace libéré, fabriquer deux partitions de taille T
Fabriquer normalement un RAID1 avec ces deux partitions nouvelles
Transférer les données indispensables dans le RAID1

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

Finkelstein · Le 19/12/2020, à 20:54

Oui ! J'aime l'idée que tu me propose, du coup tout le disque ne serait pas en raid : je trouve que c'est bon compromis entre volume de stockage et sécurité des données.
Je vais mettre ca en place, merci

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 19/10/2020, à 20:52

Re : Recuperation des données d'un HDD de NAS

#52 Le 21/10/2020, à 17:02

Re : Recuperation des données d'un HDD de NAS

#53 Le 21/10/2020, à 17:30

Re : Recuperation des données d'un HDD de NAS

#54 Le 21/10/2020, à 18:21

Re : Recuperation des données d'un HDD de NAS

#55 Le 21/10/2020, à 18:29

Re : Recuperation des données d'un HDD de NAS

#56 Le 21/10/2020, à 18:35

Re : Recuperation des données d'un HDD de NAS

#57 Le 21/10/2020, à 18:45

Re : Recuperation des données d'un HDD de NAS

#58 Le 21/10/2020, à 19:26

Re : Recuperation des données d'un HDD de NAS

#59 Le 22/10/2020, à 11:12

Re : Recuperation des données d'un HDD de NAS

#60 Le 19/12/2020, à 18:33

Re : Recuperation des données d'un HDD de NAS

#61 Le 19/12/2020, à 19:03

Re : Recuperation des données d'un HDD de NAS

#62 Le 19/12/2020, à 20:54

Re : Recuperation des données d'un HDD de NAS

Pied de page des forums