Pages : 1
#1 Le 14/05/2013, à 17:27
- Bob Morane
Problèmes pour monter un RAID1 venant d'un NAS dans Ubuntu
Bonjour tout le monde. Je galère depuis quelques jours pour essayer de monter les disques (ou un des deux) provenant d'une grappe RAID1 issue d'un NAS Synology DS210j sur mon PC sous kUbuntu 13.04.
Les détails :
Le NAS possède un OS basé sur Linux, son système de fichier est du ext. Vu qu'il tourne depuis quelques années, je ne sais plus quelle version.
Dernièrement des fichiers semblent avoir disparu. Mauvaise manip ou erreur logicielle, je n'en sais rien, mais certains de ces fichiers n’existaient plus que sur ce NAS (ben oui, maintenant je saurai qu'il ne faut pas se fier à une seule sauvegarde, même si c'est du RAID1).
Je voudrais récupérer ce qui peut l'être avec un programme du genre extundelete ou photorec, qui n'existent pas pour le processeur Marvell Kirkwood de ce modèle (photorec a été compilé pour d'autres NAS, mais pas celui-là). J'ai donc éteint le NAS, repris les disques et j'essaye de les monter sur mon PC.
Impossible de monter un des disques directement car le système de fichier est "RAID Linux autodétecté" et même si je lui dis de le monter comme du ext2,3 ou 4, je n'ai rien (ni message d'erreur, ni fichiers dans le point de montage).
J'ai donc mis les deux disque dans mon PC, et j'essaye de récupérer la grappe RAID1 en utilisant mdadm. En suivant des instructions trouvées sur le forum de Synology, j'ai reconstruit un volume virtuel qui utilise mes deux disques
~$ mdadm -C /dev/md3 -l1 -n2 /dev/sdc3 /dev/sdd3Au passage il m'a signalé que le disque est en ext2. mdadm détecte à présent la présence du volume
sudo mdadm -E /dev/sdc3 /dev/sdc3: Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 2f82fc31:879dda38:257903aa:498453c0 Name : Rd:3 (local to host Rd) Creation Time : Tue May 14 15:45:43 2013 Raid Level : raid1 Raid Devices : 2 Avail Dev Size : 1946976506 (928.39 GiB 996.85 GB) Array Size : 973488064 (928.39 GiB 996.85 GB) Used Dev Size : 1946976128 (928.39 GiB 996.85 GB) Data Offset : 262144 sectors Super Offset : 8 sectors State : active Device UUID : 1b0542a8:68ff7a00:b5a24d79:41bd2698 Update Time : Tue May 14 16:05:43 2013 Checksum : 277937a - correct Events : 4 Device Role : Active device 0 Array State : AA ('A' == active, '.' == missing)Mais impossible de le monter. Il me demande à nouveau quel est le système de fichier, et j'ai beau lui dire de le monter en ext2, rien à faire. De plus, si je lance un fdisk -l
Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 255 têtes, 63 secteurs/piste, 121601 cylindres, total 1953525168 secteurs Unités = secteurs de 1 * 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Identifiant de disque : 0x00000000 Périphérique Amorce Début Fin Blocs Id Système /dev/sdc1 63 4980149 2490043+ fd RAID Linux autodétecté /dev/sdc2 4980150 6024374 522112+ fd RAID Linux autodétecté /dev/sdc3 6281415 1953520064 973619325 fd RAID Linux autodétecté Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes 255 têtes, 63 secteurs/piste, 121601 cylindres, total 1953525168 secteurs Unités = secteurs de 1 * 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Identifiant de disque : 0x00000000 Périphérique Amorce Début Fin Blocs Id Système /dev/sdd1 63 4980149 2490043+ fd RAID Linux autodétecté /dev/sdd2 4980150 6024374 522112+ fd RAID Linux autodétecté /dev/sdd3 6281415 1953520064 973619325 fd RAID Linux autodétecté Disk /dev/md3: 996.9 GB, 996851777536 bytes 2 têtes, 4 secteurs/piste, 243372016 cylindres, total 1946976128 secteurs Unités = secteurs de 1 * 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Identifiant de disque : 0x00000000 Le disque /dev/md3 ne contient pas une table de partitions valableApparemment, je n'ai pas de table de partition sur le volume virtuel. Donc pas étonnant que je ne sache pas le monter. Mais je ne peux pas le formater pour lui en mettre une, il faudrait que je retrouve celle de l'ancien volume.
Une idée de ce que je peux faire à présent? Est-ce que par hasard je devrais créer le volume RAID avec le disque entier (donc sdc et sdd) au lieu des partitions qui contenaient les données? C'est bien une partition qui avait été donnée par quelqu'un du service technique de synology mais bon, avec les recherches internet qui donnent des solutions pour un problème similaire à 99.9%, on a parfois des surprises et je ne connais pas grand chose au RAID, le principe oui, l'administration non. L'interface de contrôle du synology faisait tout le boulot (apparemment pas toujours bien) pour moi et je n'avais pas eu besoin de me plonger dans les détails jusqu'ici 
Hors ligne
#2 Le 18/05/2013, à 13:31
- Bob Morane
Re : Problèmes pour monter un RAID1 venant d'un NAS dans Ubuntu
Petit UP et évolution du problème.
Je n'ai toujours pas réussi à reconstruire la grappe RAID. J'ai donc adopté une autre approche et fait tourné photorec sur la partition non montée avec un certain succès (récupération de plusieurs centaines de milliers de fichiers sans le nom des fichiers ).
Par contre, j'aimerais quand même pouvoir monter au moins un des disques pour récupérer tout ce qui peut l'être sans passer par photorec (vu le broll qu'il me récupère en vrac). Quitte à casser la grappe RAID et reformater ensuite tout cela au propre, mais en récupérant le maximum avant.
Vu que la partition est en principe du ext2, je devrais pouvoir la monter en local, avec un seul disque. Sauf que cela ne marche pas (comme signalé dans mon premier message). J'ai tout de même lancé e2fsk en mode "diagnostic" (donc -n) et voici ce qu'il me dit :
sudo e2fsck -n /dev/sdd3
e2fsck 1.42.5 (29-Jul-2012)
Warning! /dev/sdd3 is in use.
exet2fs_check_desc: Descripteur de groupe corrompu : bloc invalide pour le bitmap de blocs
e2fsck : Les descripteurs de groupe semblent en mauvais état... tentons d'utiliser les blocs de sauvetage...
1.41.3-0959 n'a pas été démonté proprement, vérification forcée.
Passe 1 : vérification des i-noeuds, des blocs et des tailles
l'i-noeud 16385 a le drapeau INDEX_FL activé sur le système de fichiers sans support des htrees.
Effacer l'index HTree ? nonSuivent des tonnes de message pour d'autres noeuds avec toujours la même chose INDEX_FL et pas de support des htrees. Ensuite j'ai plein d'erreurs comme celles-ci :
Le décompte des i-noeuds libres est erroné pour le groupe n°7427 (8192, décompté=8166).
Corriger ? non
Le décompte des répertoires est erroné pour le groupe n°7427 (0, décompté=5).
Corriger ? nonEt pour finir le résumé :
1.41.3-0959 : **ATTENTION : le système de fichiers contient encore des erreurs**
11 inodes used (0.00%, out of 60858368)
13609 non-contiguous files (123718.2%)
163 non-contiguous directories (1481.8%)
# of inodes with ind/dind/tind blocks: 58604/17140/1
3870788 blocks used (1.59%, out of 243404800)
0 bad blocks
3 large files
181859 regular files
14593 directories
0 character device files
0 block device files
0 fifos
0 links
1075 symbolic links (1075 liens symboliques rapides)
0 sockets
------------
197527 filesEst-ce que je dois le lancer en mode réparation et supprimer ces htrees? J'avoue que mes recherches me laissent perplexe. Les htrees sont-ils une sécurité du système de fichier pour garder une trace de la structure des dossiers, ou un élément nécessaire pour connaître cette structure? Bref, si je les supprime, est-ce que j'ai une chance de récupérer mes données, ou plutôt de tout perdre pour de bon?
Ce coup ci, je me méfie des recherches qui me donnent les manoeuvres ayant réussi pour d'autres personnes avec à peu près le même problème, car avec la première manip j'ai peut-être fait empirer la situation.
Hors ligne