☰

シンプルな背景

tag-icon • tag-icon lvm data-recovery raid software-raid qnap
シンプルな背景

シンプルな背景

QNAP TS-451があります。 NASが失敗しましたが、ドライブはまだ破損していないと確信しています。新しいQNAP TS-462を交換しようとしていますが、新しいシステムで自分のデータがそのまま残っていることを確認したいと思います。

質問

RAIDを組み立てることができない場合、LVMのコンテンツにどのようにアクセスしますか？

（詳細は下記の質問）

環境

これTS-451システムがハングして再起動しません。その構成は次のとおりです。

  • ドライブA - 20TB RAID1ミラー
  • ドライブB - 20TB RAID1ミラー
  • ドライブC - 8TB RAIDなし
  • ドライブD - 14TB RAIDなし

これTS-462ドライブ A/B/C/D を移行する新しいシステムです。

分離Linuxシステム（理想的には）ドライブA / B / C / Dからロスレスデータを読み取る：

  • Fedora 38
  • Linuxカーネル6.2.14-300
  • 古いBIOS（つまり、GPTパーティションから起動できないようです。この場合は問題ありません）
  • Pentium Dual Core E6500（このシステムがどれほど古いかを知らせるため）

実験1

重要ではないドライブ（Cドライブ）の1つを新しいTS-462に移動しようとしましたが、TS-462はそれを読み取れないようです。私が知る限り、パーティションテーブルについて混乱しているようです（fdiskは1つを報告し、blkid / lsblkは他のものを報告します）。

別々のLinuxシステム（Fedora 38）からLVMを読み取り、CドライブとDドライブにパーティションをマウントし、ファイルが破損していないことを確認できました。

実験2

だから私はBドライブを読み取ろうと同じことを試しました。ドライブA / BはRAID1ミラーの一部なので、ドライブの1つを（慎重に）実験し、もう1つをバックアップとして維持するのは大丈夫だと思いました。

残念ながら、LVMを有効にできないようです。以下は、Linuxシステムで試したいくつかのことです。

# fdisk -l /dev/sdc
Disk /dev/sdc: 18.19 TiB, 20000588955648 bytes, 39063650304 sectors
Disk model: WDC WD201KFGX-68
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DFC9F3CE-9CFA-4251-8DD1-48BF99476C04

Device           Start         End     Sectors   Size Type
/dev/sdc1           40     1060289     1060250 517.7M Microsoft basic data
/dev/sdc2      1060296     2120579     1060284 517.7M Microsoft basic data
/dev/sdc3      2120584 39045853979 39043733396  18.2T Microsoft basic data
/dev/sdc4  39045853984 39046914269     1060286 517.7M Microsoft basic data
/dev/sdc5  39046914272 39063621869    16707598     8G Microsoft basic data

私が集めた情報ではhttp://www.rodsbooks.com/linux-fs-code/、これらのパーティションが表示されるという事実はMicrosoft basic data問題ではありませんが、これが非常に古いLinux / fdiskバージョンに設定されているという証拠にすぎません。 （私は2015年頃からTS-451を使用しました。）

# gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.9

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdc: 39063650304 sectors, 18.2 TiB
Model: WDC WD201KFGX-68
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): DFC9F3CE-9CFA-4251-8DD1-48BF99476C04
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 39063650270
Partitions will be aligned on 8-sector boundaries
Total free space is 28423 sectors (13.9 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40         1060289   517.7 MiB   0700  primary
   2         1060296         2120579   517.7 MiB   0700  primary
   3         2120584     39045853979   18.2 TiB    0700  primary
   4     39045853984     39046914269   517.7 MiB   0700  primary
   5     39046914272     39063621869   8.0 GiB     0700  primary

# cat /proc/mdstat 
Personalities : 
md123 : inactive sdc5[1](S)
      8353780 blocks super 1.0
       
md124 : inactive sdc4[25](S)
      530124 blocks super 1.0
       
md125 : inactive sdc1[26](S)
      530108 blocks super 1.0
       
md126 : inactive sdc2[1](S)
      530124 blocks super 1.0
       
md127 : inactive sdc3[2](S)
      19521865728 blocks super 1.0
       
unused devices: <none>

# mdadm --assemble --readonly /dev/sdc3
mdadm: device /dev/sdc3 exists but is not an md array.

なぜ？ ？ ？ :-(

pvdisplayそして、さまざまなLVMツールは最初にLVMを見つけられませんでした。パーティション化が明示的に指定されている場合：

# pvdisplay /dev/sdc3
  Cannot use /dev/sdc3: device is an md component

何？しかし、mdadmではないと言いました。 :-(

# mdadm --examine /dev/sdc3

/dev/sdc3:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : 5a6e38ee:eb6bf302:79856803:58887046
           Name : 1
  Creation Time : Wed Nov 25 03:18:54 2015
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 39043731456 sectors (18.18 TiB 19.99 TB)
     Array Size : 19521865728 KiB (18.18 TiB 19.99 TB)
   Super Offset : 39043733376 sectors
   Unused Space : before=0 sectors, after=1920 sectors
          State : active
    Device UUID : f2a96ebc:996e4231:1576a39a:8606a71c

    Update Time : Sun Mar 26 00:56:13 2023
       Checksum : 893841dd - correct
         Events : 436627


   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

チェックサムは大丈夫です。それでは、これが有効なRAIDパーティションであることを意味しますか？ （他のパーティション（スワップパーティションも含む）では、有効なRAID情報とチェックサムが表示されるので、これが何を意味するのかわかりません。）

別のパスを試してみましょう...

ところで設定md_component_detection=0して/etc/lvm/lvm.conf実行するとpvscan --cache --devices /dev/sdcLVMデータが得られました…

# pvdisplay /dev/sdc3
  --- Physical volume ---
  PV Name               /dev/sdc3
  VG Name               vg1
  PV Size               18.18 TiB / not usable 0   
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              4766080
  Free PE               0
  Allocated PE          4766080
  PV UUID               Xt2uVv-PMCy-oHuK-0UAc-43ZI-z7TH-hHAK7A

# vgdisplay vg1
  --- Volume group ---
  VG Name               vg1
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  131
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               18.18 TiB
  PE Size               4.00 MiB
  Total PE              4766080
  Alloc PE / Size       4766080 / 18.18 TiB
  Free  PE / Size       0 / 0   
  VG UUID               oNdjeV-lPuv-PgPR-J11o-zbHQ-X7az-93sr9J

# lvdisplay vg1
  --- Logical volume ---
  LV Path                /dev/vg1/lv544
  LV Name                lv544
  VG Name                vg1
  LV UUID                z1gyiX-FhGG-cTaM-shPx-wZg4-G1xN-b9fS37
  LV Write Access        read/write
  LV Creation host, time NASEFF3AE, 2015-11-25 03:18:56 -0800
  LV Status              NOT available
  LV Size                144.00 GiB
  Current LE             36864
  Segments               2
  Allocation             inherit
  Read ahead sectors     8192
   
  --- Segments ---
  Logical extents 0 to 5119:
    Type                linear
    Physical volume     /dev/sdc3
    Physical extents    0 to 5119
   
  Logical extents 5120 to 36863:
    Type                linear
    Physical volume     /dev/sdc3
    Physical extents    1428360 to 1460103
   
   
  --- Logical volume ---
  LV Path                /dev/vg1/lv1
  LV Name                lv1
  VG Name                vg1
  LV UUID                4lsaNW-E4Bg-g93F-ko0a-Ep1m-wHD0-3Hc3Cb
  LV Write Access        read/write
  LV Creation host, time NASEFF3AE, 2015-11-25 03:19:03 -0800
  LV Status              NOT available
  LV Size                18.04 TiB
  Current LE             4729216
  Segments               2
  Allocation             inherit
  Read ahead sectors     8192
   
  --- Segments ---
  Logical extents 0 to 1423239:
    Type                linear
    Physical volume     /dev/sdc3
    Physical extents    5120 to 1428359
   
  Logical extents 1423240 to 4729215:
    Type                linear
    Physical volume     /dev/sdc3
    Physical extents    1460104 to 4766079

はい、それでドライブをマウントできるはずです。

# vgchange -ay vg1
  WARNING: PV /dev/sdc3 in VG vg1 is using an old PV header, modify the VG to update.
  device-mapper: reload ioctl on  (253:3) failed: Device or resource busy
  device-mapper: reload ioctl on  (253:3) failed: Device or resource busy
  0 logical volume(s) in volume group "vg1" now active

うーん…多分これはmd_component_detection=0正しいアプローチではありませんか？

実験3

徹底的なテストのために、最終結果、メス、テストディスクをテストしました。これらは素晴らしいツールですが、現状では少し面倒だと思います。ディスクは完全で読み取り可能でなければなりません。パーティションとファイルシステムは破損しないでください。どこかにバージョン非互換性があるようですが？

目標と問題点（見直し）

私の目標は、主に何とか（ドライブA / Bの）古いデータにアクセスすることです。ドライブの1つを再フォーマットして別のシステムから移行してもかまいません。または、データにアクセスできると合理的に期待されている場合は、TS-462に入れてください。

私の現在のパス（実験2と一緒に）で私が詰まった部分は、LinuxにRAIDを認識させる方法を見つけることです。頑張ると思います。フロストスーツ素晴らしいアドバイス記録中にコピーを上書きする~ と共有Linux Raid1メンバーディスクからのファイルの回復 - できるだけ悪い。

しかし、私は提案を受け入れる準備ができています！

答え1

# mdadm --assemble --readonly /dev/sdc3
mdadm: device /dev/sdc3 exists but is not an md array.

なぜ？ ？ ？ :-(

これは完全に間違ったコマンドです。 mdadmを使用すると、デバイスで/dev/mdはなくデバイスを組み立てることができます/dev/sd。

あなたは試すことができます：

mdadm --assemble --run --readonly /dev/md42 /dev/sdc3

ただし、sdc3( ) 用の/dev/md127md デバイスはすでに組み立てているため、mdadm --stop /dev/md127再組み立てする前にまず組み立てる必要があります。

/dev/sdc3この既存のmdデバイスは、raidレイヤーを無視してvgchangeを試みると表示される「デバイス使用中」エラーの原因でもあります。

答え2

QNAPデバイスが破損していると、Linuxコンピュータのディスク上のファイルにアクセスできません。これは、QNAP がカーネルお​​よび lvm ツールを変更したためです。

これらのファイルにアクセスするには、qnapカーネルとqnapの変更されたlvmツールをソースからコンパイルする必要があります。

同僚（モデルTS-251 +）のためにqnapディスクからファイルを回復するためのサイドプロジェクトで、VMを作成してディスク上のファイルにアクセスできるように、LVMツールを含むカーネルとinitrdをコンパイルしました。

以下では、カーネルと指示を見つけることができます。https://github.com/thanosz/qnap-kernel-lvm

関連情報