Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#76 Le 31/01/2017, à 00:55

Bougron

Re : Récupération données Raid 5 provenant d'un NAS

jamesbad000 a écrit :

Après, les pannes de disques, ça fait partie de la règle du jeux. C'est pour ça qu'il faut faire des sauvegardes...

Une autre règle du jeu totalement oubliée lorsqu'on utilise du RAID
   Le court-circuit   qui bousille d'un seul coup deux disques  (cela n'est arrivé!!!) et la carte mère.....
   Le dégât des eaux
   L'incendie
   Le vol
   Le tremblement de terre
   Les virus
  La fausse manip si simple  sudo rm  -Rv /
  etc...

Mais, il probable que maintenant, tu  n'aies plus que le choix de recréer le raids  avec  sda sdb et la duplication de SDD
=> Attendons malgré tout avant ce choix car Jamesbabd00 a plein d'idées.
(PS Une nouvelle discussion pour SDC que je n'ai pas vue apparaître)

Dernière modification par Bougron (Le 31/01/2017, à 02:32)

Hors ligne

#77 Le 31/01/2017, à 01:23

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

ca fait une heure que ca tourne. Pas plus de récup de données que lorsque je l'ai relancé.
242 erreurs ; 1843ko

C'est sur que l'idéal est d'avoir une sauvegarde chez soit et une ailleurs.

Non pas d'autre discussion à propos de SDC.

Pour l'instant on reste sur celle là. 

On fait le point demain matin voir si le nombre d'erreurs a diminué.

Hors ligne

#78 Le 31/01/2017, à 02:49

Bougron

Re : Récupération données Raid 5 provenant d'un NAS

jamesbad000 a écrit :

Mais pour l'autre disque, à moins que j'ai loupé quelque chose, il n'y a pas eu de ddrescue.

Bonsoir Jamesbad000
C'était avant que je t'appelle au secours.
La commande  lancée a été

sudo badblocks -s -b 512 -o ~/SDC4.badblocks   /dev/sdc4

et elle ne s'est pas terminée.
J'ignorais que je pouvais  faire bousiller un disque avec cela. Cela fera mon second disque. Le premier ayant été fait via la commande "dd" que je n'utilise plus suite  à ce problème. Donc maintenant je vire aussi la commande badblock  de mon registre de dépannage; Je ferais attaquer directement par ddrescue.

Hors ligne

#79 Le 31/01/2017, à 07:56

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

Après quasiment 8h (4e passe), nous sommes à 234erreurs et 1779ko
Après 20h : 225 erreurs ; 1724ko en erreurs; 8e passe

Dernière modification par jmvau54 (Le 31/01/2017, à 20:33)

Hors ligne

#80 Le 31/01/2017, à 21:42

jamesbad000

Re : Récupération données Raid 5 provenant d'un NAS

Bougron a écrit :

J'ignorais que je pouvais  faire bousiller un disque avec cela.

C'est simple, toute tentative de lire, ou pire d'écrire, sur un disque endommagé, ou même de laisser tourner à vide dans certain cas, risque de l'endommager encore plus. Y compris avec ddrescue...
Sauf qu'avec ce dernier tu as quand même des chances de récupérer le maximum de données, grace à sa stratégie "d'évitement" des zones trop difficile à lire.
La seule autre meilleurs option étant de  confier le disque à un professionnel...

jmvau54 a écrit :

Après 20h : 225 erreurs ; 1724ko en erreurs; 8e passe

Ok ça ne progresse quasiment plus. mais comme je ne suis pas encore prêt pour la suite, il n'y a qu'a laisser tourner encore


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#81 Le 01/02/2017, à 07:56

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

Bonjour,
Ca diminue toujours tout doucement
216 erreurs, 1667ko en erreurs

Ce soir : 207 erreurs
1619ko en erreurs

Dernière modification par jmvau54 (Le 01/02/2017, à 20:35)

Hors ligne

#82 Le 02/02/2017, à 11:14

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

Bonjour,
Ce matin, 206 erreurs.

Est ce que je peux t'aider à faire quelque chose ?

Hors ligne

#83 Le 02/02/2017, à 14:00

Bougron

Re : Récupération données Raid 5 provenant d'un NAS

Bonjour

Une erreur récupérée en  une  douzaine d'heures.

Tu en es à quelle passe???

Dernière modification par Bougron (Le 02/02/2017, à 14:02)

Hors ligne

#84 Le 02/02/2017, à 20:19

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

Bonsoir.
À cette heure, j'en suis à la 27e passe.
1523ko en erreur
193 erreurs

Hors ligne

#85 Le 03/02/2017, à 22:07

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

jamesbad000, tu es toujours là ?
il reste 187 erreurs et 1479ko en erreurs.
passe 38

Hors ligne

#86 Le 03/02/2017, à 22:30

jamesbad000

Re : Récupération données Raid 5 provenant d'un NAS

Oui je suis là. On est sur la bonne voie, plus que 14 jours au rythme actuel roll

A part, ça, je ne suis pas encore tout à fait au point pour la suite. Je suis en train de préparer un script pour pouvoir tester différentes options de réparations sans risquer de tout bousiller, et ce sans faire un double des 3 disques. Car si on doit reconstruire avec l'option create de mdadm, ce qui est l'option ma plus probable, il y vraiment des risques de tout perdre si on se loupe sur un paramètre (J'ai vu des exemple sur le forum....)
L'idée c'est qu'on va utiliser la technique des snapshot qui permet de dérouter toutes les écritures vers un autre emplacement. Ensuite pour les lecture, le système se démerde pour savoir si les données les plus fraiche sont sur le disque d'origine ou ailleurs.

Par contre pour utiliser cette technique y compris pour la réparation du système de fichier, il va falloir un espace dispo d'au minimum 200Gb dans un file système ext4. (plus on en aura, moins on aura de risque de se retrouver planté en cours de route)

Pas forcément nécessaire que les disques soient d'une haute fiabilité (ce sera du jetable), mais s'ils marchent trop mal ou nous lâchent en cours de route on perdra du temps.

Au pire on peu assembler des morceaux (disques, partitions, voir même image disque placée dans du NTFS) avec LVM pour faire un espace disque suffisant...

Enfin si tu as juste un disque neuf et vide de 2To tout sera beaucoup plus simple smile

Dernière modification par jamesbad000 (Le 03/02/2017, à 22:31)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#87 Le 04/02/2017, à 00:16

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

J'ai un autre disque de 2 to de vide.
Après, j'ai un nas où il reste 3to de libre et disque usb où il reste aussi environ 3to.
Jai commandé 2 disques de 5to pour remettre dans un autre nas mais je ne les aurai pas avant la mi du mois.

En sachant qu'il faut que je garde de la place pour copier mes données ou remettre le raid d'aplomb.

Hors ligne

#88 Le 04/02/2017, à 00:40

jamesbad000

Re : Récupération données Raid 5 provenant d'un NAS

C'est bon on utilisera le disque de 2To. De toute façon, si il y a plus de quelque centaines de Go à réécrire, c'est surement que ça se passe mal. Si tu peux préparer une partition en ext4 dessus ça sera parfait


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#89 Le 04/02/2017, à 16:21

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

Le disque sdf est formaté en ext 4. Une partition de 2to

Sinon, on en est à 177erreurs et 1418ko en erreurs, passe 46

Dernière modification par jmvau54 (Le 04/02/2017, à 16:22)

Hors ligne

#90 Le 04/02/2017, à 17:40

jamesbad000

Re : Récupération données Raid 5 provenant d'un NAS

On va pouvoir commencer. Copier les lignes ci-dessous d'un bloc dans le terminal et valider par entrée pour créer le script devOverlay.sh dans ton home

cat <<'EOS' > ~/devOverlay.sh
#!/bin/bash
# https://www.kernel.org/doc/Documentation/device-mapper/snapshot.txt
option=$1
ovrPath=$2
basDev=$3
ovrDev=$(basename $basDev)

overlay_start()
{
  [ -e /dev/mapper/$ovrDev ] && echo "/dev/mapper/$ovrDev allready in use" && exit 1
  # blockdev --setro $basDev
  basDevSize=$(blockdev --getsz $basDev) # 512 byte sectors
  
  if [ "$option" = "--create" ]; then
    truncate -s $(( ($basDevSize + 2048) * 512 )) "$ovrPath/$ovrDev.ovr" 
    [ $? != 0 ] && echo "failed to create $ovrPath/$ovrDev.ovr" && exit 1
  else
    [ ! -f "$ovrPath/$ovrDev.ovr" ] && echo "$ovrPath/$ovrDev.ovr does not exists, use --create instead of --start" && exit 1
  fi
  
  loop=$(losetup -f --show "$ovrPath/$ovrDev.ovr")
  dmsetup create $ovrDev --table "0 $basDevSize snapshot $basDev $loop P 8"
  if [ $? = 0 ]; then
    echo "overlay for $basDev on /dev/mapper/$ovrDev using $loop on backup file $ovrPath/$ovrDev.ovr"
  else
    overlay_stop
  fi
}

overlay_stop()
{
  # blockdev --setrw $basDev
  [ -e /dev/mapper/$ovrDev ] && dmsetup remove $ovrDev 
  if [ -f "$ovrPath/$ovrDev.ovr" ]; then
    loop=$(losetup -j "$ovrPath/$ovrDev.ovr" | cut -d : -f1)
    [ -n "$loop" ] && losetup -d $loop
  fi
}

case "$option" in 
  --start|--create) 
    overlay_start;;
    
  --stop)
    overlay_stop;;
  *)
    echo "option invalide" && exit 1;;
esac
EOS
chmod a+x ~/devOverlay.sh

Ensuite, monter la nouvelle partition ext4 de sdf, si ce n'est déjà fait, et me renvoyer le résultat d'un lsblk

edit, je viens de désactiver 2 lignes dans le script, car ça nous empêcherais de l'utiliser pendant que ddrescue continue à tourner.
Donc si tu l'a déjà créé, recommence la manip.

Dernière modification par jamesbad000 (Le 04/02/2017, à 17:44)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#91 Le 04/02/2017, à 19:33

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

Voila

jm@jm-P35C-DS3R:~$ lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda       8:0    0   1,8T  0 disk  
├─sda1    8:1    0   512M  0 part  
│ └─md0   9:0    0   512M  0 raid1 
├─sda2    8:2    0   1,8T  0 part  
├─sda3    8:3    0     1G  0 part  
└─sda4    8:4    0     1G  0 part  
sdb       8:16   0   1,8T  0 disk  
├─sdb1    8:17   0   512M  0 part  
│ └─md0   9:0    0   512M  0 raid1 
├─sdb2    8:18   0   1,8T  0 part  
├─sdb3    8:19   0     1G  0 part  
└─sdb4    8:20   0     1G  0 part  
sdc       8:32   0   1,8T  0 disk  
├─sdc1    8:33   0   512M  0 part  
│ └─md0   9:0    0   512M  0 raid1 
├─sdc2    8:34   0   1,8T  0 part  
├─sdc3    8:35   0     1G  0 part  
└─sdc4    8:36   0     1G  0 part  
sdd       8:48   0   1,8T  0 disk  
├─sdd1    8:49   0   512M  0 part  
├─sdd2    8:50   0   1,8T  0 part  
├─sdd3    8:51   0     1G  0 part  
└─sdd4    8:52   0     1G  0 part  
sde       8:64   0   1,8T  0 disk  
├─sde1    8:65   0   512M  0 part  
├─sde2    8:66   0   1,8T  0 part  
├─sde3    8:67   0     1G  0 part  
└─sde4    8:68   0     1G  0 part  
sdf       8:80   0   1,8T  0 disk  
└─sdf1    8:81   0   1,8T  0 part  /media/jm/2f94304d-3a7a-46a0-88d1-d5f966d8720
sdg       8:96   0 111,8G  0 disk  
├─sdg1    8:97   0 107,8G  0 part  /
└─sdg5    8:101  0     4G  0 part  [SWAP]
jm@jm-P35C-DS3R:~$ 

Hors ligne

#92 Le 04/02/2017, à 20:02

jamesbad000

Re : Récupération données Raid 5 provenant d'un NAS

Hum, juste pour être certain de ne pas s'égarer dans cette forêt...

ls -l /dev/disk/by-id/ | grep -E 'sd[abcde]2|sdf'

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#93 Le 04/02/2017, à 20:42

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

jm@jm-P35C-DS3R:~$ ls -l /dev/disk/by-id/ | grep -E 'sd[abcde]2|sdf'
lrwxrwxrwx 1 root root  9 févr.  4 18:29 ata-Hitachi_HUA722020ALA330_JK11A8B9GK7NHF -> ../../sdf
lrwxrwxrwx 1 root root 10 févr.  4 18:29 ata-Hitachi_HUA722020ALA330_JK11A8B9GK7NHF-part1 -> ../../sdf1
lrwxrwxrwx 1 root root 10 févr.  4 18:29 ata-Hitachi_HUA722020ALA330_JK11B1B9KZGETF-part2 -> ../../sde2
lrwxrwxrwx 1 root root 10 févr.  4 18:29 ata-ST2000DL003-9VT166_5YD0XFK9-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 févr.  4 18:29 ata-ST2000DL003-9VT166_5YD0Y2H4-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 févr.  4 18:32 ata-WDC_WD20EARS-00MVWB0_WD-WMAZA0733372-part2 -> ../../sdd2
lrwxrwxrwx 1 root root 10 févr.  4 18:29 ata-WDC_WD20EARS-00MVWB0_WD-WMAZA0775988-part2 -> ../../sdc2
lrwxrwxrwx 1 root root 10 févr.  4 18:29 wwn-0x5000c5002eff7c50-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 févr.  4 18:29 wwn-0x5000c5002f0302ea-part2 -> ../../sda2
lrwxrwxrwx 1 root root  9 févr.  4 18:29 wwn-0x5000cca222c7d711 -> ../../sdf
lrwxrwxrwx 1 root root 10 févr.  4 18:29 wwn-0x5000cca222c7d711-part1 -> ../../sdf1
lrwxrwxrwx 1 root root 10 févr.  4 18:29 wwn-0x5000cca222f81fde-part2 -> ../../sde2
lrwxrwxrwx 1 root root 10 févr.  4 18:32 wwn-0x50014ee0026a39df-part2 -> ../../sdd2
lrwxrwxrwx 1 root root 10 févr.  4 18:29 wwn-0x50014ee6006d7948-part2 -> ../../sdc2
jm@jm-P35C-DS3R:~$

Hors ligne

#94 Le 04/02/2017, à 20:49

jamesbad000

Re : Récupération données Raid 5 provenant d'un NAS

Parfais, tout est là ou il faut. Donc voici la suite. Il n'est pas interdit d'y aller sans précipitation en vérifiant que je ne me suis pas pris les pieds dans le tapis, et que les devices que j'indique sont cohérent avec les explications...

sudo ~/devOverlay.sh --create /media/jm/2f94304d-3a7a-46a0-88d1-d5f966d8720 /dev/sda2

refaire la même commande avec sdb2,et sde2 (on travail avec la copie de sdd et non avec l'original)

Ensuite nous allons travailler avec les devices créés dans /dev/mapper. Ce qui va envoyer les éventuelles écritures vers les fichier .ovr créé par la commande ci-dessus dans la partition de sdf. Et les lectures seront faite soit directement à partir des /dev originaux, soit à partir des fichiers .ovr pour les blocs qui auront été modifiés....

On va d'abort retenter un assemblage classique. Avec sde peut-être que ça fonctionnera mieux qu'avec le sdd pourri.

sudo mdadm -S /dev/md*
sudo mdadm -A -v -f /dev/md1 /dev/mapper/sd[abe]2

si ça echoue essayer directement derrière

sudo mdadm -S /dev/md1
sudo mdadm -A -v -U resync -f /dev/md1 /dev/mapper/sd[abe]2

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#95 Le 04/02/2017, à 23:04

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

J'ai du arrêté md1
J'ai du installé dmsetup
et il manquait un "3" à la fin du nom du disque sdf

toujours la même réponse pour l'assemblage

jm@jm-P35C-DS3R:~$ sudo mdadm -S /dev/md*
mdadm: stopped /dev/md0
mdadm: stopped /dev/md1
mdadm: stopped /dev/md127
jm@jm-P35C-DS3R:~$ 
jm@jm-P35C-DS3R:~$ sudo mdadm -A -v -f /dev/md1 /dev/mapper/sd[abe]2
mdadm: looking for devices for /dev/md1
mdadm: /dev/mapper/sda2 is identified as a member of /dev/md1, slot 0.
mdadm: /dev/mapper/sdb2 is identified as a member of /dev/md1, slot 1.
mdadm: /dev/mapper/sde2 is identified as a member of /dev/md1, slot 3.
mdadm: added /dev/mapper/sdb2 to /dev/md1 as 1
mdadm: no uptodate device for slot 4 of /dev/md1
mdadm: added /dev/mapper/sde2 to /dev/md1 as 3 (possibly out of date)
mdadm: added /dev/mapper/sda2 to /dev/md1 as 0
mdadm: /dev/md1 assembled from 2 drives - not enough to start the array.
jm@jm-P35C-DS3R:~$ ^C

Et pour la resynchro, ca ne fonctionne pas non plus

jm@jm-P35C-DS3R:~$ sudo mdadm -S /dev/md1
mdadm: stopped /dev/md1
jm@jm-P35C-DS3R:~$ sudo mdadm -A -v -U resync -f /dev/md1 /dev/mapper/sd[abe]2
mdadm: looking for devices for /dev/md1
mdadm: /dev/mapper/sda2 is identified as a member of /dev/md1, slot 0.
mdadm: /dev/mapper/sdb2 is identified as a member of /dev/md1, slot 1.
mdadm: /dev/mapper/sde2 is identified as a member of /dev/md1, slot 3.
mdadm: Marking array /dev/md1 as 'clean'
mdadm: added /dev/mapper/sdb2 to /dev/md1 as 1
mdadm: no uptodate device for slot 4 of /dev/md1
mdadm: added /dev/mapper/sde2 to /dev/md1 as 3 (possibly out of date)
mdadm: added /dev/mapper/sda2 to /dev/md1 as 0
mdadm: /dev/md1 assembled from 2 drives - not enough to start the array.
jm@jm-P35C-DS3R:~$ 

Hors ligne

#96 Le 04/02/2017, à 23:18

jamesbad000

Re : Récupération données Raid 5 provenant d'un NAS

Ok, alors sans arrêter md1 avant (c.a.d en l'état après la tentative d'assemblage) que donnes

sudo mdadm --run /dev/md1
sudo mdadm -D /dev/md1

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#97 Le 04/02/2017, à 23:21

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

jm@jm-P35C-DS3R:~$ sudo mdadm -A -v -U resync -f /dev/md1 /dev/mapper/sd[abe]2
mdadm: looking for devices for /dev/md1
mdadm: /dev/mapper/sda2 is identified as a member of /dev/md1, slot 0.
mdadm: /dev/mapper/sdb2 is identified as a member of /dev/md1, slot 1.
mdadm: /dev/mapper/sde2 is identified as a member of /dev/md1, slot 3.
mdadm: Marking array /dev/md1 as 'clean'
mdadm: added /dev/mapper/sdb2 to /dev/md1 as 1
mdadm: no uptodate device for slot 4 of /dev/md1
mdadm: added /dev/mapper/sde2 to /dev/md1 as 3 (possibly out of date)
mdadm: added /dev/mapper/sda2 to /dev/md1 as 0
mdadm: /dev/md1 assembled from 2 drives - not enough to start the array.
jm@jm-P35C-DS3R:~$ sudo mdadm --run /dev/md1
[sudo] Mot de passe de jm :
mdadm: failed to start array /dev/md1: Invalid argument
jm@jm-P35C-DS3R:~$ sudo mdadm -D /dev/md1
/dev/md1:
        Version :
     Raid Level : raid0
  Total Devices : 0

          State : inactive

    Number   Major   Minor   RaidDevice
jm@jm-P35C-DS3R:~$

Hors ligne

#98 Le 04/02/2017, à 23:30

jamesbad000

Re : Récupération données Raid 5 provenant d'un NAS

Bon cette voie me semble définitivement impraticable. Passons au plan B...

sudo mdadm -S /dev/md1
sudo mdadm --create /dev/md1 --metadata=1.0 --level=5 --layout=left-symmetric --chunk=64 --assume-clean -n 4 /dev/mapper/sda2 /dev/mapper/sdb2 missing /dev/mapper/sde2

Edit: Je précise pour de futurs lecteurs que les valeurs associées aux paramètres sont tirés des attributs de superblock raid obtenus via mdadm -E.
Et qu'il est également crucial de déclarer les différents disque / partition dans le même ordre qu'à l'origine et avec le bon rôle. (Info trouvée  également dans les superblock)

Dernière modification par jamesbad000 (Le 18/02/2017, à 01:24)


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#99 Le 04/02/2017, à 23:35

jmvau54

Re : Récupération données Raid 5 provenant d'un NAS

jm@jm-P35C-DS3R:~$ sudo mdadm --create /dev/md1 --metadata=1.0 --level=5 --layout=left-symmetric --chunk=64 --assume-clean -n 4 /dev/mapper/sda2 /dev/mapper/sdb2 missing /dev/mapper/sde2
mdadm: /dev/mapper/sda2 appears to contain an ext2fs file system
       size=5852655616K  mtime=Mon Jan 16 23:56:18 2017
mdadm: /dev/mapper/sda2 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sat Apr  6 09:30:03 2013
mdadm: /dev/mapper/sdb2 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sat Apr  6 09:30:03 2013
mdadm: /dev/mapper/sde2 appears to contain an ext2fs file system
       size=5584220160K  mtime=Mon Jan 16 23:56:18 2017
mdadm: /dev/mapper/sde2 appears to be part of a raid array:
       level=raid5 devices=4 ctime=Sat Apr  6 09:30:03 2013
Continue creating array? 

Je suppose que je réponds yes

Hors ligne

#100 Le 04/02/2017, à 23:43

jamesbad000

Re : Récupération données Raid 5 provenant d'un NAS

yes


L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne