RAID5 : Données récuperables ou pas ?

badmaniak · Février 21, 2016, 8:55pm

Bonjour,

J’ai un soucis avec mon NAS sur OpenMediaMault,j’ai un Raid 5 qui fonctionnait jusqu’alors, puis depuis peu je me suis rendu compte que je n’accédais plus à mes partages, en vérifiant dans l’interface Web d’admin, le RAID existe bien, mais le système de fichier a un statut marqué comme “manquant”, et rien ne s’affiche.
J’ai regardé sur pas mal de forum dont celui là, j’ai avancé un peu dans le diagnostique, mais j’aimerai avoir vos avis,savoir si je perds mon temps (donc mes données) pas récupérable en l’état, si j’ai fait/ou pas vu une connerie, ça doit être le cas vu l’état de mon RAID5, bref n’étant pas expert merci de jetez un coup d’œil.

Voici la commande uname :

root@openmediavault:/media# uname -a Linux openmediavault 2.6.32-5-amd64 #1 SMP Tue May 13 16:34:35 UTC 2014 x86_64 GNU/Linux

En console la commande :
La commande fdisk -l voit bien les disques :

[code]root@openmediavault:/media# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0000dce5

Device Boot Start End Blocks Id System
/dev/sda1 * 1 59846 480705536 83 Linux
/dev/sda2 59846 60802 7677953 5 Extended
Partition 2 does not start on physical sector boundary.
/dev/sda5 59846 60802 7677952 82 Linux swap / Solaris

Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn’t contain a valid partition table

Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/sdc doesn’t contain a valid partition table

Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Disk /dev/sdd doesn’t contain a valid partition table

Disk /dev/md127: 6001.2 GB, 6001182900224 bytes
2 heads, 4 sectors/track, 1465132544 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md127 doesn’t contain a valid partition table
[/code]
Par contre il précise dev/md127 ne contient pas de partition valide.

Voici le retour d’information du volume Raid /dev/md127

[code]root@openmediavault:~# mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Sun Aug 3 01:00:18 2014
Raid Level : raid5
Array Size : 5860530176 (5589.04 GiB 6001.18 GB)
Used Dev Size : 2930265088 (2794.52 GiB 3000.59 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Oct  7 04:19:53 2014
      State : active

Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

     Layout : left-symmetric
 Chunk Size : 512K

       Name : openmediavault:Backup  (local to host openmediavault)
       UUID : 654ae289:d83cfa8e:087f89a1:e48d8157
     Events : 143

Number   Major   Minor   RaidDevice State
   0       8       16        0      active sync   /dev/sdb
   1       8       32        1      active sync   /dev/sdc
   2       8       48        2      active sync   /dev/sdd

[/code]
Tout à l’air ok sauf peut être "Superblock is persistent"
et

[code]root@openmediavault:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md127 : active raid5 sdb[0] sdd[2] sdc[1]
5860530176 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices:
[/code]
Semble lui aussi correcte.

Pour info le fstab :

[code]root@openmediavault:~# cat /etc/fstab

/etc/fstab: static file system information.

Use ‘blkid’ to print the universally unique identifier for a

device; this may be used with UUID= as a more robust way to name devices

that works even if disks are added and removed. See fstab(5).

proc /proc proc defaults 0 0

/ was on /dev/sda1 during installation

UUID=90cedf74-814b-473f-9d8f-6115c5a05a49 / ext4 errors=remount-ro 0 1

swap was on /dev/sda5 during installation

UUID=5e018fca-4c9d-4590-9136-0d48c6b7ec76 none swap sw 0 0
/dev/sdb1 /media/usb0 auto rw,user,noauto 0 0
tmpfs /tmp tmpfs defaults 0 0

>>> [openmediavault]

UUID=5b6dfd70-61b6-421c-9501-531f0656b356 /media/5b6dfd70-61b6-421c-9501-531f0656b356 ext4 defaults,nofail,acl,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 2
UUID=a86f94d5-dd82-4963-afd6-6ffa8e96b3c2 /media/a86f94d5-dd82-4963-afd6-6ffa8e96b3c2 ext4 defaults,nofail,acl,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 2
UUID=72698475-d0f5-4cae-bb1a-92d407e1325e /media/72698475-d0f5-4cae-bb1a-92d407e1325e ext4 defaults,nofail,acl,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0 0 2
/media/a86f94d5-dd82-4963-afd6-6ffa8e96b3c2/test/ /home/ftp/test none bind 0 0
/media/a86f94d5-dd82-4963-afd6-6ffa8e96b3c2/Multimedia /home/ftp/Multimédia none bind 0 0
/media/a86f94d5-dd82-4963-afd6-6ffa8e96b3c2/Documents/ /home/ftp/Documents none bind 0 0
/media/a86f94d5-dd82-4963-afd6-6ffa8e96b3c2/Sauvegarde/ /export/Sauvegarde none bind 0 0
/media/a86f94d5-dd82-4963-afd6-6ffa8e96b3c2/Documents/ /export/Documents none bind 0 0
/media/a86f94d5-dd82-4963-afd6-6ffa8e96b3c2/Multimedia /export/Multimédia none bind 0 0

<<< [openmediavault]

[/code]

Je pense que peut être le, problème viendrai de la avec le UUID.

dernière info que j’ai à fournir :

root@openmediavault:~# dmesg | tail [ 3860.375817] md: minimum _guaranteed_ speed: 10000 KB/sec/disk. [ 3860.375823] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync. [ 3860.375834] md: using 128k window, over a total of 2930265088 blocks. [22271.276732] md: md127: resync done. [22271.733759] RAID5 conf printout: [22271.733764] --- rd:3 wd:3 [22271.733767] disk 0, o:1, dev:sdb [22271.733769] disk 1, o:1, dev:sdc [22271.733771] disk 2, o:1, dev:sdd [35693.584187] EXT4-fs (md127): VFS: Can't find ext4 filesystem
Bon voila ou je voulais en venir, le “filesystem” n’existe pas/plus pourtant c’était le cas auparavant, si je lance la création en EXT4 vais je perdre mes données sur le volume md127?
Je compte installer la nouvelle version d’OpenMediavault qui est en Wheezy depuis peu, mon raid 5 existant en l’état actuel sera t’il reconnu avec la possibilité de le monté sans perdre les données?
Merci d’avance à tous ceux qui prendront le temps de me lire et de répondre.

ps: si la réponse était dans un post désolé de l’avoir raté pourtant j’ai cherché.
ps2: n’hésitez pas à me reprendre si je dis une connerie, bien au contraire.

fran.b · Février 21, 2016, 8:55pm

[quote=“badmaniak”]
Bon voila ou je voulais en venir, le “filesystem” n’existe pas/plus pourtant c’était le cas auparavant, si je lance la création en EXT4 vais je perdre mes données sur le volume md127?
Je compte installer la nouvelle version d’OpenMediavault qui est en Wheezy depuis peu, mon raid 5 existant en l’état actuel sera t’il reconnu avec la possibilité de le monté sans perdre les données?
Merci d’avance à tous ceux qui prendront le temps de me lire et de répondre.

ps: si la réponse était dans un post désolé de l’avoir raté pourtant j’ai cherché.[/quote]

Le raid semble fonctionner, ce n’(est pas un souci du raid mais du système de fichiers. Essaye de faire de la récupération de fichier classique, tu peux notamment récupérer les numeros des copies des superblocks par mkfs.ext4 -n /dev/md123 (n’oublie pas le -n), ou bien même essayer testdisk…

badmaniak · Février 21, 2016, 8:55pm

[quote=“fran.b”]
Le raid semble fonctionner, ce n’(est pas un souci du raid mais du système de fichiers. Essaye de faire de la récupération de fichier classique, tu peux notamment récupérer les numeros des copies des superblocks par mkfs.ext4 -n /dev/md123 (n’oublie pas le -n), ou bien même essayer testdisk…[/quote]
Merci pour ta réponse,

Donc dans l’état actuel des choses, je ne peux pas accéder à mes fichiers simplement?

Désolé pour la question stupide, mais avec la commande que tu ma donnée, une fois que j’ai l’emplacement des superblocks, je fais quoi ?

root@openmediavault:~# mkfs.ext4 -n /dev/md127 mke2fs 1.41.12 (17-May-2010) Étiquette de système de fichiers= Type de système d'exploitation : Linux Taille de bloc=4096 (log=2) Taille de fragment=4096 (log=2) « Stride » = 128 blocs, « Stripe width » = 256 blocs 366288896 i-noeuds, 1465132544 blocs 73256627 blocs (5.00%) réservés pour le super utilisateur Premier bloc de données=0 Nombre maximum de blocs du système de fichiers=4294967296 44713 groupes de blocs 32768 blocs par groupe, 32768 fragments par groupe 8192 i-noeuds par groupe Superblocs de secours stockés sur les blocs : 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848, 512000000, 550731776, 644972544

Testdisk sera mon derniers recours pour retrouver mes données, il y a quand même 2To

Cordialement,

Badmaniak.

fran.b · Février 21, 2016, 8:55pm

Imagine tu tu ais

Superblocs de secours stockés sur les blocs : 8193, 24577, 40961, 57345, 73729
Tu peux essayer fsck.ext4 -b 8193 /dev/md123 puis, si ça gueule, les suivants…

badmaniak · Février 21, 2016, 8:55pm

Ok je teste le premier :

root@openmediavault:~# fsck.ext4 -b 32768 /dev/md127 e2fsck 1.41.12 (17-May-2010) le drapeau needs_recovery n'est pas activé, mais le journal contient des données. Le drapeau de récupération n'est pas activé dans le superbloc de secours, le journal sera donc quand même exécuté. Backup : récupération du journal Le checksum d'un ou de plusieurs descripteurs de groupe de bloc est invalide. Corriger<o>?

Je mets oui ?

Edit : bon j’ai mis oui “o” à chaque fois la ça tourne depuis pas mal de temps…

fran.b · Février 21, 2016, 8:55pm

Hum, ça me parait le plus sage mais ça n’est pas de bon augure… Tu sais ce qui a causé le souci?

badmaniak · Février 21, 2016, 8:55pm

Bon, ça à durée pas mal de temps…

j’ai par erreur fermé la fenêtre de console (le con) , sinon le message etait que le systeme de fichier avait été modifié …pour le volume backup.

Sur l’interface web de Openmediavault le système de fichier apparait, cool :

Périphérique : /dev/md127 libellé: Backup système de fichier:EXT4 capacité:5.37To Utilisé: 1.4To status en ligne

Les partages re-fonctionnent, tout à l’air d’etre de nouveau disponible.
J’accède aussi en console à mes données.
Je vais le mettre à jour avec la nouvelle version, qui est en debian 7.

Merci encore pour ton intervention net et sans bavure

Pour répondre à ta question je ne sais pas trop, j’ai mis en place un partage ISCSI avec le volume backup entier, qui fonctionnait puis j’ai rajouté un disque suplementaire dans l’idée de partager uniquement ce disque pour des tests, j’ai mis à jour il y a 2 jours le systeme, Openmediavault et les plugins qui le demandaient ( dailleurs l’interface web de calibre c’est mit à fonctionner)…depuis hier plus d’accès au système de fichier, je pense qu’en regardant les logs on pourrait trouver, je compte faire une ré-installation par dessus ça devrait le faire.

ps: si tu as des sugestions à me faire n’hesites pas je suis preneur.
ps: validé oui à chaque fois c’était vraiment long…