Contenu | Rechercher | Menus

Annonce

L'équipe des administrateurs et modérateurs du forum vous souhaite d'excellentes fêtes de fin d'année !

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.

#1 Le 11/01/2011, à 13:05

rmy

[RESOLU] Récupération ardue Raid + LVM

@ Cep, Nasman, Chopinauher, Hoper, si vous passez dans le coin, j'ai besoin d'aide

Je suis confronté à une récup qui me résiste diablement. Il s'agit "à priori" d'une image d'un disque(probablement partiellement défectueux) provenant d'un raid1 dans un boitier iomega. J'y trouve une micro partition (comme souvent dans ces boitiers) mais rien de plus d'exploitable. Toutes vos idées et compétences raid et LVM sont les bienvenues…

1/ La partition détectée est bien membre d'un raid1, elle est accessible, se monte sans souci, pratiquement vide (un dossier vide).

sudo mdadm --examine /dev/sdi1

/dev/sdi1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : ad2a3362:2dccdac9:4c2ed0c5:d0bc6c5e
  Creation Time : Wed Jan  5 16:46:31 2011
     Raid Level : raid1
  Used Dev Size : 1020032 (996.29 MiB 1044.51 MB)
     Array Size : 1020032 (996.29 MiB 1044.51 MB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 2

    Update Time : Tue Jan 11 10:03:08 2011
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0
       Checksum : 3b6ddb95 - correct
         Events : 12


      Number   Major   Minor   RaidDevice State
this     0       8      129        0      active sync   /dev/sdi1

   0     0       8      129        0      active sync   /dev/sdi1
   1     1       0        0        1      faulty removed

Note : c'est moi qui l'ai assemblée sur md2, à l'origine c'était md0 mais j'en ai déjà un, md0…

2/ Je ne trouve pas de partition supplémentaire avec testdisk y compris en faisant une recherche approfondie sans tenir compte de l'alignement des secteurs

3/ Je trouve par contre la preuve qu'il y a bien eu un LVM sur une seconde partition.

sudo dd if=/dev/sdi bs=512 skip=2040258 count=63 | hd

00000000  4c 41 42 45 4c 4f 4e 45  01 00 00 00 00 00 00 00  |LABELONE........|
00000010  ec a5 4e 0d 20 00 00 00  4c 56 4d 32 20 30 30 31  |..N. ...LVM2 001|
00000020  52 56 71 45 35 51 31 39  56 53 71 6a 47 4f 51 6f  |RVqE5Q19VSqjGOQo|
00000030  4f 37 4e 4d 35 43 30 53  44 4a 67 39 59 76 7a 38  |O7NM5C0SDJg9Yvz8|
00000040  00 00 7b 32 74 00 00 00  00 00 03 00 00 00 00 00  |..{2t...........|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 10 00 00 00 00 00 00  |................|
00000070  00 f0 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000600  77 77 77 77 77 77 77 77  77 77 77 77 77 77 77 77  |wwwwwwwwwwwwwwww|
*
00000e00  5f 81 92 39 20 4c 56 4d  32 20 78 5b 35 41 25 72  |_..9 LVM2 x[5A%r|
00000e10  30 4e 2a 3e 01 00 00 00  00 10 00 00 00 00 00 00  |0N*>............|
00000e20  00 f0 02 00 00 00 00 00  00 06 00 00 00 00 00 00  |................|
00000e30  6b 03 00 00 00 00 00 00  72 47 60 aa 00 00 00 00  |k.......rG`.....|
00000e40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  6d 64 31 5f 76 67 20 7b  0a 69 64 20 3d 20 22 31  |md1_vg {.id = "1|
00001010  6f 6f 30 32 4c 2d 55 52  49 41 2d 37 31 6d 6d 2d  |oo02L-URIA-71mm-|
00001020  47 68 39 6a 2d 75 69 71  71 2d 42 69 77 6e 2d 70  |Gh9j-uiqq-Biwn-p|
00001030  45 39 6d 42 76 22 0a 73  65 71 6e 6f 20 3d 20 31  |E9mBv".seqno = 1|
00001040  0a 73 74 61 74 75 73 20  3d 20 5b 22 52 45 53 49  |.status = ["RESI|
00001050  5a 45 41 42 4c 45 22 2c  20 22 52 45 41 44 22 2c  |ZEABLE", "READ",|
00001060  20 22 57 52 49 54 45 22  5d 0a 65 78 74 65 6e 74  | "WRITE"].extent|
00001070  5f 73 69 7a 65 20 3d 20  34 30 39 36 0a 6d 61 78  |_size = 4096.max|
00001080  5f 6c 76 20 3d 20 30 0a  6d 61 78 5f 70 76 20 3d  |_lv = 0.max_pv =|
00001090  20 30 0a 0a 70 68 79 73  69 63 61 6c 5f 76 6f 6c  | 0..physical_vol|
000010a0  75 6d 65 73 20 7b 0a 0a  70 76 30 20 7b 0a 69 64  |umes {..pv0 {.id|
000010b0  20 3d 20 22 52 56 71 45  35 51 2d 31 39 56 53 2d  | = "RVqE5Q-19VS-|
000010c0  71 6a 47 4f 2d 51 6f 4f  37 2d 4e 4d 35 43 2d 30  |qjGO-QoO7-NM5C-0|
000010d0  53 44 4a 2d 67 39 59 76  7a 38 22 0a 64 65 76 69  |SDJ-g9Yvz8".devi|
000010e0  63 65 20 3d 20 22 2f 64  65 76 2f 6d 64 31 22 0a  |ce = "/dev/md1".|
000010f0  0a 73 74 61 74 75 73 20  3d 20 5b 22 41 4c 4c 4f  |.status = ["ALLO|
00001100  43 41 54 41 42 4c 45 22  5d 0a 64 65 76 5f 73 69  |CATABLE"].dev_si|
00001110  7a 65 20 3d 20 39 37 34  37 33 32 36 37 32 0a 70  |ze = 974732672.p|
00001120  65 5f 73 74 61 72 74 20  3d 20 33 38 34 0a 70 65  |e_start = 384.pe|
00001130  5f 63 6f 75 6e 74 20 3d  20 32 33 37 39 37 31 0a  |_count = 237971.|
00001140  7d 0a 7d 0a 0a 7d 0a 23  20 47 65 6e 65 72 61 74  |}.}..}.# Generat|
00001150  65 64 20 62 79 20 4c 56  4d 32 20 76 65 72 73 69  |ed by LVM2 versi|
00001160  6f 6e 20 32 2e 30 32 2e  32 39 20 28 32 30 30 37  |on 2.02.29 (2007|
00001170  2d 31 32 2d 30 35 29 3a  20 46 72 69 20 44 65 63  |-12-05): Fri Dec|
00001180  20 33 31 20 31 36 3a 30  33 3a 32 30 20 31 39 39  | 31 16:03:20 199|
00001190  39 0a 0a 63 6f 6e 74 65  6e 74 73 20 3d 20 22 54  |9..contents = "T|
000011a0  65 78 74 20 46 6f 72 6d  61 74 20 56 6f 6c 75 6d  |ext Format Volum|
000011b0  65 20 47 72 6f 75 70 22  0a 76 65 72 73 69 6f 6e  |e Group".version|
000011c0  20 3d 20 31 0a 0a 64 65  73 63 72 69 70 74 69 6f  | = 1..descriptio|
000011d0  6e 20 3d 20 22 22 0a 0a  63 72 65 61 74 69 6f 6e  |n = ""..creation|
000011e0  5f 68 6f 73 74 20 3d 20  22 73 74 6f 72 61 67 65  |_host = "storage|
000011f0  22 09 23 20 4c 69 6e 75  78 20 73 74 6f 72 61 67  |".# Linux storag|
00001200  65 20 32 2e 36 2e 32 32  2e 37 20 23 31 20 46 72  |e 2.6.22.7 #1 Fr|
00001210  69 20 4a 61 6e 20 39 20  30 38 3a 35 39 3a 31 32  |i Jan 9 08:59:12|
00001220  20 45 53 54 20 32 30 30  39 20 61 72 6d 76 35 74  | EST 2009 armv5t|
00001230  65 6a 6c 0a 63 72 65 61  74 69 6f 6e 5f 74 69 6d  |ejl.creation_tim|
00001240  65 20 3d 20 39 34 36 36  38 35 30 30 30 09 23 20  |e = 946685000.# |
00001250  46 72 69 20 44 65 63 20  33 31 20 31 36 3a 30 33  |Fri Dec 31 16:03|
00001260  3a 32 30 20 31 39 39 39  0a 0a 00 77 77 77 77 77  |:20 1999...wwwww|
00001270  77 77 77 77 77 77 77 77  77 77 77 77 77 77 77 77  |wwwwwwwwwwwwwwww|
*
00001400  6d 64 31 5f 76 67 20 7b  0a 69 64 20 3d 20 22 31  |md1_vg {.id = "1|
00001410  6f 6f 30 32 4c 2d 55 52  49 41 2d 37 31 6d 6d 2d  |oo02L-URIA-71mm-|
00001420  47 68 39 6a 2d 75 69 71  71 2d 42 69 77 6e 2d 70  |Gh9j-uiqq-Biwn-p|
00001430  45 39 6d 42 76 22 0a 73  65 71 6e 6f 20 3d 20 32  |E9mBv".seqno = 2|
00001440  0a 73 74 61 74 75 73 20  3d 20 5b 22 52 45 53 49  |.status = ["RESI|
00001450  5a 45 41 42 4c 45 22 2c  20 22 52 45 41 44 22 2c  |ZEABLE", "READ",|
00001460  20 22 57 52 49 54 45 22  5d 0a 65 78 74 65 6e 74  | "WRITE"].extent|
00001470  5f 73 69 7a 65 20 3d 20  34 30 39 36 0a 6d 61 78  |_size = 4096.max|
00001480  5f 6c 76 20 3d 20 30 0a  6d 61 78 5f 70 76 20 3d  |_lv = 0.max_pv =|
00001490  20 30 0a 0a 70 68 79 73  69 63 61 6c 5f 76 6f 6c  | 0..physical_vol|
000014a0  75 6d 65 73 20 7b 0a 0a  70 76 30 20 7b 0a 69 64  |umes {..pv0 {.id|
000014b0  20 3d 20 22 52 56 71 45  35 51 2d 31 39 56 53 2d  | = "RVqE5Q-19VS-|
000014c0  71 6a 47 4f 2d 51 6f 4f  37 2d 4e 4d 35 43 2d 30  |qjGO-QoO7-NM5C-0|
000014d0  53 44 4a 2d 67 39 59 76  7a 38 22 0a 64 65 76 69  |SDJ-g9Yvz8".devi|
000014e0  63 65 20 3d 20 22 2f 64  65 76 2f 6d 64 31 22 0a  |ce = "/dev/md1".|
000014f0  0a 73 74 61 74 75 73 20  3d 20 5b 22 41 4c 4c 4f  |.status = ["ALLO|
00001500  43 41 54 41 42 4c 45 22  5d 0a 64 65 76 5f 73 69  |CATABLE"].dev_si|
00001510  7a 65 20 3d 20 39 37 34  37 33 32 36 37 32 0a 70  |ze = 974732672.p|
00001520  65 5f 73 74 61 72 74 20  3d 20 33 38 34 0a 70 65  |e_start = 384.pe|
00001530  5f 63 6f 75 6e 74 20 3d  20 32 33 37 39 37 31 0a  |_count = 237971.|
00001540  7d 0a 7d 0a 0a 6c 6f 67  69 63 61 6c 5f 76 6f 6c  |}.}..logical_vol|
00001550  75 6d 65 73 20 7b 0a 0a  6d 64 31 76 6f 6c 31 20  |umes {..md1vol1 |
00001560  7b 0a 69 64 20 3d 20 22  63 6b 72 4d 6d 52 2d 69  |{.id = "ckrMmR-i|
00001570  4d 46 4a 2d 53 33 42 6f  2d 4a 70 52 6b 2d 69 6c  |MFJ-S3Bo-JpRk-il|
00001580  69 6d 2d 77 67 37 47 2d  6f 57 49 34 68 7a 22 0a  |im-wg7G-oWI4hz".|
00001590  73 74 61 74 75 73 20 3d  20 5b 22 52 45 41 44 22  |status = ["READ"|
000015a0  2c 20 22 57 52 49 54 45  22 2c 20 22 56 49 53 49  |, "WRITE", "VISI|
000015b0  42 4c 45 22 5d 0a 73 65  67 6d 65 6e 74 5f 63 6f  |BLE"].segment_co|
000015c0  75 6e 74 20 3d 20 31 0a  0a 73 65 67 6d 65 6e 74  |unt = 1..segment|
000015d0  31 20 7b 0a 73 74 61 72  74 5f 65 78 74 65 6e 74  |1 {.start_extent|
000015e0  20 3d 20 30 0a 65 78 74  65 6e 74 5f 63 6f 75 6e  | = 0.extent_coun|
000015f0  74 20 3d 20 32 33 37 39  37 31 0a 0a 74 79 70 65  |t = 237971..type|
00001600  20 3d 20 22 73 74 72 69  70 65 64 22 0a 73 74 72  | = "striped".str|
00001610  69 70 65 5f 63 6f 75 6e  74 20 3d 20 31 09 23 20  |ipe_count = 1.# |
00001620  6c 69 6e 65 61 72 0a 0a  73 74 72 69 70 65 73 20  |linear..stripes |
00001630  3d 20 5b 0a 22 70 76 30  22 2c 20 30 0a 5d 0a 7d  |= [."pv0", 0.].}|
00001640  0a 7d 0a 7d 0a 7d 0a 23  20 47 65 6e 65 72 61 74  |.}.}.}.# Generat|
00001650  65 64 20 62 79 20 4c 56  4d 32 20 76 65 72 73 69  |ed by LVM2 versi|
00001660  6f 6e 20 32 2e 30 32 2e  32 39 20 28 32 30 30 37  |on 2.02.29 (2007|
00001670  2d 31 32 2d 30 35 29 3a  20 46 72 69 20 44 65 63  |-12-05): Fri Dec|
00001680  20 33 31 20 31 36 3a 30  33 3a 32 30 20 31 39 39  | 31 16:03:20 199|
00001690  39 0a 0a 63 6f 6e 74 65  6e 74 73 20 3d 20 22 54  |9..contents = "T|
000016a0  65 78 74 20 46 6f 72 6d  61 74 20 56 6f 6c 75 6d  |ext Format Volum|
000016b0  65 20 47 72 6f 75 70 22  0a 76 65 72 73 69 6f 6e  |e Group".version|
000016c0  20 3d 20 31 0a 0a 64 65  73 63 72 69 70 74 69 6f  | = 1..descriptio|
000016d0  6e 20 3d 20 22 22 0a 0a  63 72 65 61 74 69 6f 6e  |n = ""..creation|
000016e0  5f 68 6f 73 74 20 3d 20  22 73 74 6f 72 61 67 65  |_host = "storage|
000016f0  22 09 23 20 4c 69 6e 75  78 20 73 74 6f 72 61 67  |".# Linux storag|
00001700  65 20 32 2e 36 2e 32 32  2e 37 20 23 31 20 46 72  |e 2.6.22.7 #1 Fr|
00001710  69 20 4a 61 6e 20 39 20  30 38 3a 35 39 3a 31 32  |i Jan 9 08:59:12|
00001720  20 45 53 54 20 32 30 30  39 20 61 72 6d 76 35 74  | EST 2009 armv5t|
00001730  65 6a 6c 0a 63 72 65 61  74 69 6f 6e 5f 74 69 6d  |ejl.creation_tim|
00001740  65 20 3d 20 39 34 36 36  38 35 30 30 30 09 23 20  |e = 946685000.# |
00001750  46 72 69 20 44 65 63 20  33 31 20 31 36 3a 30 33  |Fri Dec 31 16:03|
00001760  3a 32 30 20 31 39 39 39  0a 0a 00 77 77 77 77 77  |:20 1999...wwwww|
00001770  77 77 77 77 77 77 77 77  77 77 77 77 77 77 77 77  |wwwwwwwwwwwwwwww|
*
00007e00

4/ Enfin, je trouve bien un superblock raid (cf https://raid.wiki.kernel.org/index.php/ … k_formats) mais qui semble incomplet, et qui "serait" celui d'un raid0 (offset 0x48)…

sudo dd if=/dev/sdi bs=512 skip=976772929 count=8 |hd

00000000  fc 4e 2b a9 00 00 00 00  5a 00 00 00 00 00 00 00  |.N+.....Z.......|
00000010  00 00 00 00 7a 80 b0 c6  43 44 6d 38 01 00 00 00  |....z...CDm8....|
00000020  c0 9e 0c 1d 01 00 00 00  02 00 00 00 01 00 00 00  |................|
00000030  00 00 00 00 9b ac 04 ce  d1 07 7f 29 33 e4 14 19  |...........)3...|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  b4 bc ff 4c 01 00 00 00  01 00 00 00 01 00 00 00  |...L............|
00000090  01 00 00 00 00 00 00 00  51 c0 f9 22 fa db 05 00  |........Q.."....|
000000a0  00 00 00 00 fa db 05 00  00 00 00 00 ff ff ff ff  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 00 00 00 08 00 00 00  02 00 00 00 00 00 00 00  |................|
00000210  06 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000280  01 00 00 00 00 00 00 00  00 00 00 00 01 00 00 00  |................|
00000290  09 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000002a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000f80  00 00 00 00 08 00 00 00  02 00 00 00 00 00 00 00  |................|
00000f90  06 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000fa0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000

Des idées pour avancer ?

Dernière modification par rmy (Le 12/01/2011, à 17:58)

Hors ligne

#2 Le 11/01/2011, à 16:23

Hoper

Re : [RESOLU] Récupération ardue Raid + LVM

Heu.... Appeler iomega, ou leur envoyer un mail avec ce que tu as trouvé et en leur demandant plus de précision sur le fonctionnement de leur NAS ? Peu de chance que ca aboutisse, je te l'accorde, mais il me semble qu'il est absolument indispensable d'essayer...


Mes tutos et coups de gueule :
http://hoper.dnsalias.net/atdc/
Mastodon: @hoper@framapiaf.org

Hors ligne

#3 Le 11/01/2011, à 17:53

chopinhauer

Re : [RESOLU] Récupération ardue Raid + LVM

Les meta-données d'un volume physique LVM devraient commencent 512 octets du début de la partition. Tu pourrais copier les données à partir du secteur précédent à LABELONE (et jusqu'au meta-données md, peu importe si il y a trop de données) ailleurs et essayer de l'utiliser avec LVM.

En alternative essaie de créer une partition à partir du secteur 2040257 jusqu'à la fin.

Est-ce que tu peux poster les meta-données de LVM sans les faire passer par hd ? Ce sera plus lisible ainsi.


Pensez à donner un bon titre à vos sujets : cela permettra d'aider d'autres utilisateurs dans votre même situation. Ce n'est pas qu'en donnant des solutions qu'on aide, mais aussi en posant des bonnes questions et… facilement trouvables.

Hors ligne

#4 Le 12/01/2011, à 07:34

rmy

Re : [RESOLU] Récupération ardue Raid + LVM

Merci du retour, je jette un œil cet après-midi et vous tiens au courant.

Hors ligne

#5 Le 12/01/2011, à 16:04

rmy

Re : [RESOLU] Récupération ardue Raid + LVM

Hoper a écrit :

Heu.... Appeler iomega, ou leur envoyer un mail avec ce que tu as trouvé et en leur demandant plus de précision sur le fonctionnement de leur NAS ? Peu de chance que ca aboutisse, je te l'accorde, mais il me semble qu'il est absolument indispensable d'essayer...

Iomega propose un service de récupération de données…

chopinhauer a écrit :

Les meta-données d'un volume physique LVM devraient commencent 512 octets du début de la partition. Tu pourrais copier les données à partir du secteur précédent à LABELONE (et jusqu'au meta-données md, peu importe si il y a trop de données) ailleurs et essayer de l'utiliser avec LVM.

En alternative essaie de créer une partition à partir du secteur 2040257 jusqu'à la fin.

Est-ce que tu peux poster les meta-données de LVM sans les faire passer par hd ? Ce sera plus lisible ainsi.

Il n'y a que des 0 sur les secteur précédant le début du LVM, je ne comprends pas bien comment je pourrai exploiter le "fragment" extrait. Peux-tu préciser ton idée ?
En attendant, je vais tenter de créer une partition bidon commençant juste sur le secteur précédent, et voir si j'arrive à quelque chose, mais dans les métadonnées, de ce que j'arrive à lire, il est précisé que ce LVM était sur md1, et le pe de début et le nombre total est précisé aussi… ça risque pas de poser problème ?

Autre option un peu lourde à laquelle j'avais pensé, recréer sur un autre disque un raid1 là où il devrait se situer (en espérant qu'il s'agissait bien d'un raid1 puisque je n'ai qu'un seul des deux disques), refaire un LVM par dessus, puis dumper les données du disque actuel sur l'autre en modifiant à la main les ID dans les métadonnées après LABELONE… ça vous parait faisable ?

Sinon, y a-t-il quelque chose à faire du côté de vgcfgrestore en fabriquant de toutes pièces un fichier de conf sur la base des infos visibles dans les métadonnées ?

Je reporte ci dessous ces données, extraites de hd, mais je n'ai pas d'autre retour possible car il n'y a ni partition ni raid détecté sur ce disque (hormis la première qui elle est saine) et donc pas de retour d'infos de lvm.

LABELONE
LVM2 001RVqE5Q19VSqjGOQoO7NM5C0SDJg9Yvz8
LVM2 x[5A%r0N*>

md1_vg {
    id = "1oo02L-URIA-71mm-Gh9j-uiqq-Biwn-pE9mBv"
    seqno = 1
    status = ["RESIZEABLE", "READ", "WRITE"]
    extent_size = 4096
    max_lv = 0
    max_pv = 0
    physical_volumes 
            {
            pv0 
                {
                id = "RVqE5Q-19VS-qjGO-QoO7-NM5C-0SDJ-g9Yvz8"
                device = "/dev/md1"
                status = ["ALLOCATABLE"]
                dev_size = 974732672
                pe_start = 384
                pe_count = 237971
                }
            }
    }
# Generated by LVM2 version 2.02.29 (2007-12-05): Fri Dec 31 16:03:20 1999

contents = "Text Format Volume Group"
version = 1
description = ""
creation_host = "storage"

# Linux storage 2.6.22.7 #1 Fri Jan 9 08:59:12 EST 2009 armv5tejl
creation_time = 946685000
# Fri Dec 31 16:03:20 1999

md1_vg {
    id = "1oo02L-URIA-71mm-Gh9j-uiqq-Biwn-pE9mBv"
    seqno = 2
    status = ["RESIZEABLE", "READ", "WRITE"]
    extent_size = 4096
    max_lv = 0.max_pv = 0
    physical_volumes 
            {
            pv0 
                {
                id = "RVqE5Q-19VS-qjGO-QoO7-NM5C-0SDJ-g9Yvz8"
                device = "/dev/md1"
                status = ["ALLOCATABLE"]
                dev_size = 974732672
                pe_start = 384
                pe_count = 237971
                }
            }
    
    logical_volumes 
            {
            md1vol1
                {
                id = "ckrMmR-iMFJ-S3Bo-JpRk-ilim-wg7G-oWI4hz"
                status = ["READ", "WRITE", "VISIBLE"]
                segment_count = 1
                
                segment1 
                    {
                    start_extent = 0
                    extent_count = 237971
                    type = "striped"
                    stripe_count = 1
                    # linear
                    stripes = [ "pv0", 0 ]
                    }

                }
            }
        }

# Generated by LVM2 version 2.02.29 (2007-12-05): Fri Dec 31 16:03:20 1999
contents = "Text Format Volume Group"
version = 1
description = ""
creation_host = "storage"

# Linux storage 2.6.22.7 #1 Fri Jan 9 08:59:12 EST 2009 armv5tejl
creation_time = 946685000
# Fri Dec 31 16:03:20 1999

Hors ligne

#6 Le 12/01/2011, à 16:22

chopinhauer

Re : [RESOLU] Récupération ardue Raid + LVM

rmy a écrit :

Il n'y a que des 0 sur les secteur précédant le début du LVM, je ne comprends pas bien comment je pourrai exploiter le "fragment" extrait. Peux-tu préciser ton idée ?
En attendant, je vais tenter de créer une partition bidon commençant juste sur le secteur précédent, et voir si j'arrive à quelque chose, mais dans les métadonnées, de ce que j'arrive à lire, il est précisé que ce LVM était sur md1, et le pe de début et le nombre total est précisé aussi… ça risque pas de poser problème ?

Un volume physique a n'importe quoi dans le premier secteur, suivi des métadonnées sur le groupe de volumes. Si tu créé un périphérique avec telles caractéristiques (par exemple une partition) il devrait tout retrouver. Mets LVM comme type de partition pour aider encore le pilote et fait un :

sudo pvs

ou

sudo pvdisplay

Pour le nom du volume physique, c'est l'ID du volume qui compte (il est écrit dans la deuxième ligne du fichier), pas le nom du périphérique qui est une indication.

Dernière modification par chopinhauer (Le 12/01/2011, à 16:24)


Pensez à donner un bon titre à vos sujets : cela permettra d'aider d'autres utilisateurs dans votre même situation. Ce n'est pas qu'en donnant des solutions qu'on aide, mais aussi en posant des bonnes questions et… facilement trouvables.

Hors ligne

#7 Le 12/01/2011, à 16:35

cep

Re : [RESOLU] Récupération ardue Raid + LVM

sudo mdadm --examine /dev/sdi1

/dev/sdi1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : ad2a3362:2dccdac9:4c2ed0c5:d0bc6c5e
  Creation Time : Wed Jan  5 16:46:31 2011
     Raid Level : raid1
  Used Dev Size : 1020032 (996.29 MiB 1044.51 MB)
     Array Size : 1020032 (996.29 MiB 1044.51 MB)

Curieux non ? tu as parcouru un peu le disque ? pas trouvé de nombres magiques par çi par là ?
Sur ces systèmes nas il n'y a pas une reconstruction auto en cas de défaillance d'un disque ? le gars n'a pas lancé la reconstruction en se trompant de cible ?

Hors ligne

#8 Le 12/01/2011, à 17:34

rmy

Re : [RESOLU] Récupération ardue Raid + LVM

Tiens, salut cep ^^

Non rien de curieux, c'est un disque extrait d'un boitier iomega ix2-200 et de ce que j'ai constaté il y a toujours une petite partition système plus ou moins vide, en raid1. La partition de données exploitables par l'utilisateur final se trouve après, sur tout le reste.

Ici, j'ai bien retrouvé un magic à la fin de ce que devrait être la taille d'un disque de 500Gio (oui, je bosse sur un dump sur un disque de 1Tio, ça simplifie pas les choses…) que j'ai mis dans mon premier message. Mais il semble très partiel. J'ai tenté tout de même de reconstruire une partition de type 'fd' en lui donnant une taille qui situait ce "md superbloc" entre 64 et 128K de la fin, mais ça n'a rien donné, mdadm me dit "superbloc invalide". Peut-être que je ne l'ai pas aligné correctement ?

@chopinhauer : je vais essayer ça tout de suite. Pour gagner du temps, est-ce que tu penses que je peux passer par un loopdevice avec un offset de 2040257*512 ?
(je pose la question, mais je vais essayer de toutes façons…)

Hors ligne

#9 Le 12/01/2011, à 17:38

chopinhauer

Re : [RESOLU] Récupération ardue Raid + LVM

rmy a écrit :

@chopinhauer : je vais essayer ça tout de suite. Pour gagner du temps, est-ce que tu penses que je peux passer par un loopdevice avec un offset de 2040257*512 ?
(je pose la question, mais je vais essayer de toutes façons…)

Oui, c'est tout à fait pareil. De toute manière un périphérique disque peut toujours être plus grand que le volume LVM inclus.


Pensez à donner un bon titre à vos sujets : cela permettra d'aider d'autres utilisateurs dans votre même situation. Ce n'est pas qu'en donnant des solutions qu'on aide, mais aussi en posant des bonnes questions et… facilement trouvables.

Hors ligne

#10 Le 12/01/2011, à 17:57

rmy

Re : [RESOLU] Récupération ardue Raid + LVM

Vous êtes des dieux ! (Chopinhauer surtout toi sur ce coup là…)

Donc après mon loopdevice :

 sudo losetup /dev/loop0 /dev/sdi -o 1044611584
sudo pvs
  PV                    VG     Fmt  Attr PSize   PFree
  /dev/loop0            md1_vg lvm2 a-   464,79g    0 
  /dev/mapper/cryptraid debian lvm2 a-     5,46t    0 
sudo pvdisplay
   
  --- Physical volume ---
  PV Name               /dev/loop0
  VG Name               md1_vg
  PV Size               464,79 GiB / not usable 1,69 MiB
  Allocatable           yes (but full)
  PE Size               2,00 MiB
  Total PE              237971
  Free PE               0
  Allocated PE          237971
  PV UUID               RVqE5Q-19VS-qjGO-QoO7-NM5C-0SDJ-g9Yvz8
   
rmy@rmyprod:~$ sudo lvdisplay

  --- Logical volume ---
  LV Name                /dev/md1_vg/md1vol1
  VG Name                md1_vg
  LV UUID                ckrMmR-iMFJ-S3Bo-JpRk-ilim-wg7G-oWI4hz
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                464,79 GiB
  Current LE             237971
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:5

Le FS est corrompu, mais testdisk accède a des fichiers, j'ai donc bien au moins un superbloc de secours sain. Je suis en train de faire une vérif avec e2fsck, sujet résolu !

Hors ligne

#11 Le 12/01/2011, à 21:09

Hoper

Re : [RESOLU] Récupération ardue Raid + LVM

@chopinhauer : Je me joint à rmy pour les félicitations (et les remerciements). J'avais faillit suggérer la création d'une partition, mais il me manquait vraiment l'information essentielle, l'organisation d'un PV.

512 octets de bruit, les méta data, puis la suite du volume. J'ai bien résumé ?


Mes tutos et coups de gueule :
http://hoper.dnsalias.net/atdc/
Mastodon: @hoper@framapiaf.org

Hors ligne

#12 Le 12/01/2011, à 21:25

chopinhauer

Re : [RESOLU] Récupération ardue Raid + LVM

Oui, les 512 octets initiaux ne sont utilisés dans aucun système que je connais : ext2/3/4, lvm, RAID, GPT,… C'est plus au moins réservé à accueillir le secteur de démarrage d'un système d'exploitation, même si ce serait impossible à l'heure actuelle de placer un LVM sur /dev/sda et démarrer l'ordinateur.

Suivent les métadonnées en ASCII et en plusieurs copies et à partir des métadonnées on peut retrouver le début des données : dans le cas de rmy elles commencent au secteur 384 et s'étalent sur 237971 morceaux de 4096 secteurs.

L'astuce de rmy de créer un boîte qui place les métadonnées md sur une frontière des 64 kio entre 64 et 128 kio de la fin du périphérique aurait probablement aussi marché pour restaurer le RAID.


Pensez à donner un bon titre à vos sujets : cela permettra d'aider d'autres utilisateurs dans votre même situation. Ce n'est pas qu'en donnant des solutions qu'on aide, mais aussi en posant des bonnes questions et… facilement trouvables.

Hors ligne

#13 Le 12/01/2011, à 21:50

rmy

Re : [RESOLU] Récupération ardue Raid + LVM

Merci pour ces précisions !

Note, j'ai essayé la "boite" pour reconstruire le raid, mais soit j'ai mal placé les métadonnées md soit celles-cis étaient trop corrompues…

Hors ligne