私はこの状況に入るためにいくつかの愚かな動きをしたことを知っています、私に思い出させないでください、そして理由を尋ねないでください:-/
私はこのSynologyDS1515 +を持っており、SHRに2x6TBドライブがあります。つまり、MD RAID1で、LVMが上にあります。
RAID1からRAID5への変換を開始し、それを中止してディスクをいじくった後、ext4ファイルシステムをマウントできません。
RAID1からRAID5への変換が約10%しか完了していなくても、システムが何度も再起動してディスクを削除することで単に「混乱」し、ディスクスペース全体をRAID5ボリュームとして扱う可能性はありますか?もしそうなら、3番目のディスクを追加してRAIDアレイを再構築させれば、ファイルシステムを修正する可能性があると思いますか?それとも、現在とまったく同じデータ、つまり破損したファイルシステムを持つ論理ボリュームに再構築されるのでしょうか。
スペース全体がRAID5に変換されるまで、MDまたはLVM、あるいはその両方がRAID5またはRAID1として扱われるべきブロックデバイスのどの部分を知っている必要があるため、実際の変換プロセスがどのように行われるかについて少し興味があります。これについてもっと知っている人はいますか?
助けてくれてありがとう:-)
これが私がしたことです。 (これまでの私の救助の試み、およびログエントリは以下にリストされています)
新しい6 TBディスクをNASにホットプラグしました。
SynologyのUIに、ディスクを既存のボリュームに追加して12TBに拡張するように指示しました(3x6TB RAID5になります)
NASをシャットダウンし(-Pを今すぐシャットダウン)、成長プロセスに数人入れて、新しいドライブを取り外しました。NASは正常に起動しましたが、ボリュームが低下したと報告されました。それでも6 TBファイルシステムが報告され、すべてにアクセスできました。
ディスク3を再度ホットプラグし、ワイプして、別の単一ディスクボリュームを作成しました。
NASをシャットダウンし、ディスク2を取り外し(これは間違いでした!)、電源を入れました。ビープ音が鳴り始め、ボリュームがクラッシュしたと通知されました。
NASを再度シャットダウンし、不足しているdisk2を再挿入しました。しかし、Synologyはボリュームがクラッシュしたと報告し、修復オプションを提供しませんでした。 。
だから、私のデータはすべて利用できなくなりました!
私はその問題の調査を始めました。 MDがアレイを適切に組み立てているようです。
State : clean, degraded
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
Name : DiskStation:2 (local to Host DiskStation)
UUID : 58290cba:75757ee2:86fe074c:ada2e6d2
Events : 31429
Number Major Minor RaidDevice State
0 8 5 0 active sync /dev/sda5
1 8 21 1 active sync /dev/sdb5
2 0 0 2 removed
また、元の2つのディスクのメタデータも正常に見えます。
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing)
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
LVMはRAID5ボリュームも認識し、そのデバイスを公開します。
--- Logical volume ---
LV Path /dev/vg1000/lv
LV Name lv
VG Name vg1000
しかし、読み取り専用でマウントしようとすると、/ dev/vg1000/lv上のファイルシステムが破損しているようです。
mount: wrong fs type, bad option, bad superblock on /dev/vg1000/lv, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program)
In some cases useful info is found in syslog - try dmesg | tail or so.
だから、ここで私は壊れたファイルシステムを持っていますが、それを修復することは不可能だと思います(以下の私の試みのリストを参照してください)。
これまでに試した手順は次のとおりです:
/ dev/vg1000/lvを空のハードドライブ上のパーティションに複製し、e2fsckを実行しましたこのプロセスを1週間実行してから、中断しました。何百万もの障害のあるinodeや複数請求されたブロックなどが見つかりました。その量のFSエラーがあるため、いつか完了しても、有用なデータは返されないと思います。
データのある2つのハードドライブをUSBドックに移動し、Ubuntu仮想マシンに接続し、オーバーレイデバイスを作成してすべての書き込みをキャッチしました(dmsetupを使用)
まず、RAIDアレイを再作成しようとしました。同じパラメーターで配列を作成するコマンドを見つけることから始め、mdadm -Eで既に指定されているので、順序を変更して、結果が異なるかどうかを確認しました(つまり、sda、missing、sdb、sda、sdb、missing 、欠落、sdb、sda)。 6つの組み合わせのうち4つで、LVMがボリュームグループを検出しましたが、ファイルシステムはまだ壊れていました。
R-Studioを使用して配列を組み立て、ファイルシステムを検索しました
これにより、実際にいくつかの結果が得られます-アセンブルしたRAIDボリュームでEXT4ファイルシステムをスキャンして見つけることができ、ファイルを参照できましたが、実際のファイルのサブセット(10など)のみがファイルに表示されましたビューア。デバイスの順序を切り替えてみたところ、4つの組み合わせでR-Studioがext4ファイルシステムを検出しましたが(上記と同様)、元の設定(sda、sdb、欠落)のみでR-studioはファイルを検出できましたドライブのルートから。
-o sb = XXXXXを使用してマウントを試み、代替スーパーブロックをポイントしました
これにより、スーパーブロックの位置を指定しない場合と同じエラーが発生しました。
debugfsを試しました
これにより、「ls」と入力したときにIOエラーが発生しました。
問題の原因となった上記の操作のログメッセージを次に示します。
低下したRAID5として実行されていたファイルシステムがまだ機能しているシステムのシャットダウン
2017-02-25T18:13:27+01:00 DiskStation umount: kill the process "synoreport" [pid = 15855] using /volume1/@appstore/StorageAnalyzer/usr/syno/synoreport/synoreport
2017-02-25T18:13:28+01:00 DiskStation umount: can't umount /volume1: Device or resource busy
2017-02-25T18:13:28+01:00 DiskStation umount: can't umount /volume1: Device or resource busy
2017-02-25T18:13:28+01:00 DiskStation umount: SYSTEM: Last message 'can't umount /volume' repeated 1 times, suppressed by syslog-ng on DiskStation
2017-02-25T18:13:28+01:00 DiskStation syno_poweroff_task: lvm_poweroff.c:49 Failed to /bin/umount -f -k /volume1
2017-02-25T18:13:29+01:00 DiskStation syno_poweroff_task: lvm_poweroff.c:58 Failed to /sbin/vgchange -an
2017-02-25T18:13:29+01:00 DiskStation syno_poweroff_task: raid_stop.c:28 Failed to mdadm stop '/dev/md2'
2017-02-25T18:13:29+01:00 DiskStation syno_poweroff_task: syno_poweroff_task.c:331 Failed to stop RAID [/dev/md2]
「RAIDの停止に失敗しました」に注意してください-それが問題の考えられる原因ですか?
disk2(sdb)を削除した後の最初の起動
2017-02-25T18:15:27+01:00 DiskStation kernel: [ 10.467975] set group disks wakeup number to 5, spinup time deno 1
2017-02-25T18:15:27+01:00 DiskStation kernel: [ 10.500561] synobios: unload
2017-02-25T18:15:27+01:00 DiskStation kernel: [ 10.572388] md: invalid raid superblock magic on sda5
2017-02-25T18:15:27+01:00 DiskStation kernel: [ 10.578043] md: sda5 does not have a valid v0.90 superblock, not importing!
2017-02-25T18:15:27+01:00 DiskStation kernel: [ 10.627381] md: invalid raid superblock magic on sdc5
2017-02-25T18:15:27+01:00 DiskStation kernel: [ 10.633034] md: sdc5 does not have a valid v0.90 superblock, not importing!
2017-02-25T18:15:27+01:00 DiskStation kernel: [ 10.663832] md: sda2 has different UUID to sda1
2017-02-25T18:15:27+01:00 DiskStation kernel: [ 10.672513] md: sdc2 has different UUID to sda1
2017-02-25T18:15:27+01:00 DiskStation kernel: [ 10.784571] Got empty serial number. Generate serial number from product.
2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md3
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.339243] md/raid:md2: not enough operational devices (2/3 failed)
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.346371] md/raid:md2: raid level 5 active with 1 out of 3 devices, algorithm 2
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.355295] md: md2: set sda5 to auto_remap [1]
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.355299] md: reshape of RAID array md2
2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: spacetool.c:1223 Try to force assemble RAID [/dev/md2]. [0x2000 file_get_key_value.c:81]
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.414839] md: md2: reshape done.
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.433218] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.494964] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.549962] md/raid:md2: not enough operational devices (2/3 failed)
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.557093] md/raid:md2: raid level 5 active with 1 out of 3 devices, algorithm 2
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.566069] md: md2: set sda5 to auto_remap [1]
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.566073] md: reshape of RAID array md2
2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md2
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.633774] md: md2: reshape done.
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.645025] md: md2: change number of threads from 0 to 1
2017-02-25T18:15:41+01:00 DiskStation kernel: [ 31.645033] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1000], New vg path: [/dev/vg1000], UUID: [Fund9t-vUVR-3yln-QYVk-8gtv-z8Wo-zz1bnF]
2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1001], New vg path: [/dev/vg1001], UUID: [FHbUVK-5Rxk-k6y9-4PId-cSMf-ztmU-DfXYoL]
2017-02-25T18:22:50+01:00 DiskStation umount: can't umount /volume2: Invalid argument
2017-02-25T18:22:50+01:00 DiskStation syno_poweroff_task: lvm_poweroff.c:49 Failed to /bin/umount -f -k /volume2
2017-02-25T18:22:50+01:00 DiskStation kernel: [ 460.374192] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:22:50+01:00 DiskStation kernel: [ 460.404747] md: md3: set sdc5 to auto_remap [0]
2017-02-25T18:28:01+01:00 DiskStation umount: can't umount /initrd: Invalid argument
disk2(sdb)が再び存在する状態で再度ブートします
2017-02-25T18:28:17+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md3
2017-02-25T18:28:17+01:00 DiskStation kernel: [ 32.442352] md: kicking non-fresh sdb5 from array!
2017-02-25T18:28:17+01:00 DiskStation kernel: [ 32.478415] md/raid:md2: not enough operational devices (2/3 failed)
2017-02-25T18:28:17+01:00 DiskStation kernel: [ 32.485547] md/raid:md2: raid level 5 active with 1 out of 3 devices, algorithm 2
2017-02-25T18:28:17+01:00 DiskStation spacetool.shared: spacetool.c:1223 Try to force assemble RAID [/dev/md2]. [0x2000 file_get_key_value.c:81]
2017-02-25T18:28:17+01:00 DiskStation kernel: [ 32.515567] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:28:18+01:00 DiskStation kernel: [ 32.602256] md/raid:md2: raid level 5 active with 2 out of 3 devices, algorithm 2
2017-02-25T18:28:18+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md2
2017-02-25T18:28:18+01:00 DiskStation kernel: [ 32.654279] md: md2: change number of threads from 0 to 1
2017-02-25T18:28:18+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1000], New vg path: [/dev/vg1000], UUID: [Fund9t-vUVR-3yln-QYVk-8gtv-z8Wo-zz1bnF]
2017-02-25T18:28:18+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1001], New vg path: [/dev/vg1001], UUID: [FHbUVK-5Rxk-k6y9-4PId-cSMf-ztmU-DfXYoL]
2017-02-25T18:28:18+01:00 DiskStation spacetool.shared: spacetool.c:3030 [Info] Activate all VG
2017-02-25T18:28:18+01:00 DiskStation synovspace: virtual_space_conf_check.c:78 [INFO] "PASS" checking configuration of virtual space [FCACHE], app: [1]
2017-02-25T18:28:18+01:00 DiskStation synovspace: virtual_space_conf_check.c:74 [INFO] No implementation, skip checking configuration of virtual space [HA]
2017-02-25T18:28:18+01:00 DiskStation synovspace: virtual_space_conf_check.c:74 [INFO] No implementation, skip checking configuration of virtual space [SNAPSHOT_ORG]
2017-02-25T18:28:18+01:00 DiskStation synovspace: vspace_wrapper_load_all.c:76 [INFO] No virtual layer above space: [/volume2] / [/dev/vg1001/lv]
2017-02-25T18:28:18+01:00 DiskStation synovspace: vspace_wrapper_load_all.c:76 [INFO] No virtual layer above space: [/volume1] / [/dev/vg1000/lv]
2017-02-25T18:28:19+01:00 DiskStation kernel: [ 33.792601] BTRFS: has skinny extents
2017-02-25T18:28:19+01:00 DiskStation kernel: [ 34.009184] JBD2: no valid journal superblock found
2017-02-25T18:28:19+01:00 DiskStation kernel: [ 34.014673] EXT4-fs (dm-0): error loading journal
mount: wrong fs type, bad option, bad superblock on /dev/vg1000/lv,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
quotacheck: Mountpoint (or device) /volume1 not found or has no quota enabled.
quotacheck: Cannot find filesystem to check or filesystem not mounted with quota option.
quotaon: Mountpoint (or device) /volume1 not found or has no quota enabled.
2017-02-25T18:28:19+01:00 DiskStation synocheckhotspare: synocheckhotspare.c:149 [INFO] No hotspare config, skip hotspare config check. [0x2000 virtual_space_layer_get.c:98]
2017-02-25T18:28:19+01:00 DiskStation synopkgctl: pkgtool.cpp:3035 package AudioStation is not installed or not operable
最初に3つのデバイスのうちの1つが存在すると表示されているが、その後強制的にアセンブルされるため、RAIDアレイがアセンブルされ、マウントを試みますが、EXT4マウントエラーが発生します。
この経験の後で再起動しようとしましたが、役に立ちませんでした
2017-02-25T18:36:45+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md3
2017-02-25T18:36:45+01:00 DiskStation kernel: [ 29.579136] md/raid:md2: raid level 5 active with 2 out of 3 devices, algorithm 2
2017-02-25T18:36:45+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md2
2017-02-25T18:36:45+01:00 DiskStation kernel: [ 29.629837] md: md2: change number of threads from 0 to 1
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1000], New vg path: [/dev/vg1000], UUID: [Fund9t-vUVR-3yln-QYVk-8gtv-z8Wo-zz1bnF]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1001], New vg path: [/dev/vg1001], UUID: [FHbUVK-5Rxk-k6y9-4PId-cSMf-ztmU-DfXYoL]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3030 [Info] Activate all VG
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3041 Activate LVM [/dev/vg1000]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3041 Activate LVM [/dev/vg1001]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3084 space: [/dev/vg1000]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3084 space: [/dev/vg1001]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3110 space: [/dev/vg1000], ndisk: [2]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3110 space: [/dev/vg1001], ndisk: [1]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: hotspare_repair_config_set.c:36 Failed to hup synostoraged
2017-02-25T18:36:46+01:00 DiskStation synovspace: virtual_space_conf_check.c:78 [INFO] "PASS" checking configuration of virtual space [FCACHE], app: [1]
2017-02-25T18:36:46+01:00 DiskStation synovspace: virtual_space_conf_check.c:74 [INFO] No implementation, skip checking configuration of virtual space [HA]
2017-02-25T18:36:46+01:00 DiskStation synovspace: virtual_space_conf_check.c:74 [INFO] No implementation, skip checking configuration of virtual space [SNAPSHOT_ORG]
2017-02-25T18:36:46+01:00 DiskStation synovspace: vspace_wrapper_load_all.c:76 [INFO] No virtual layer above space: [/volume2] / [/dev/vg1001/lv]
2017-02-25T18:36:46+01:00 DiskStation synovspace: vspace_wrapper_load_all.c:76 [INFO] No virtual layer above space: [/volume1] / [/dev/vg1000/lv]
2017-02-25T18:36:47+01:00 DiskStation kernel: [ 30.799110] BTRFS: has skinny extents
2017-02-25T18:36:47+01:00 DiskStation kernel: [ 30.956115] JBD2: no valid journal superblock found
2017-02-25T18:36:47+01:00 DiskStation kernel: [ 30.961585] EXT4-fs (dm-0): error loading journal
mount: wrong fs type, bad option, bad superblock on /dev/vg1000/lv,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
quotacheck: Mountpoint (or device) /volume1 not found or has no quota enabled.
quo
成長するRAID5を完全に破壊した後、データをどのように保存しましたか?
3ディスクのRAID5アレイがあり、デバイス番号3が欠落していて、データが破損しているようです。
/ dev/sdd5:(5.45 TiB)6TB、アレイのデバイス1
/ dev/sdd5:(5.45 TiB)6TB、アレイのデバイス2
操作が中断され、デバイス3が取り外されたとき、アレイはRAID1からRAID5への変換の進行中です。デバイス2も削除されるまで、アレイはまだ実行されていました。デバイス2が戻されたとき、ファイルシステムをマウントできませんでした。/dev/md2デバイスが複製され、複製されたパーティションでfsckが実行され、数百万のエラーが見つかりました。
変換とディスクの取り外しが中断された後、MDは明らかにRAIDデータを適切に処理していませんでした。私は何が起こったのかを調査しに行きました:
まず、/var/log/space_operation_error.log
を確認したところ、何が起こったのか正確にわかりました。 3ディスクRAID5は1ディスクでは実行できないため、ディスク2が取り外されるとすぐに、RAIDのステータスが破損に変わりました。しかし、それはまた、RAID1からRAID5への進行中の再形成をRAIDに忘れさせました。
そのため、MDの一部がまだ元の状態のままだったのに、MDがデータ全体をRAID5エンコードされたものとして扱うことで、データの破損が引き起こされるのではないかと考えました。
デバイスのRAIDデータを調べても、役に立ちませんでした。すべてが正常に見えました。
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md124 : active raid5 sda5[0] sdb5[1]
11711575296 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/2] [UU_]
# mdadm -E /dev/sda5
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 58290cba:75757ee2:86fe074c:ada2e6d2
Name : DiskStation:2
Creation Time : Thu Nov 27 11:35:34 2014
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 11711575680 (5584.51 GiB 5996.33 GB)
Array Size : 23423150592 (11169.03 GiB 11992.65 GB)
Used Dev Size : 11711575296 (5584.51 GiB 5996.33 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1a222812:ac39920b:4cec73c4:81aa9b63
Update Time : Fri Mar 17 23:14:25 2017
Checksum : cb34324c - correct
Events : 31468
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing)
しかし、私は、形を変えながらその進行状況を追跡するために、何らかのカウンターが必要だと思いました。ここで説明されているMDスーパーブロックのフォーマットを調べました: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats
RAIDパーティションの1つの最初の10MiBのコピーを取りました(mdadm -Eは小さいコピーでは機能しませんでした):
# dd if=/dev/sda5 of=/volume1/homes/sda5_10M.img bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0622844 s, 168 MB/s
それをHEXエディターで開き、バイト4104のデータを0x00から0x04に変更して、再形成が進行中であることを示しました。
また、4200から始まる8バイトの値にも注目しました。3856372992と表示されます。
変更を保存した後、コピーを調べました。
# mdadm -E /volume1/homes/sda5_10M.img
/volume1/homes/sda5_10M.img:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x4
Array UUID : 58290cba:75757ee2:86fe074c:ada2e6d2
Name : DiskStation:2
Creation Time : Thu Nov 27 11:35:34 2014
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 11711575680 (5584.51 GiB 5996.33 GB)
Array Size : 23423150592 (11169.03 GiB 11992.65 GB)
Used Dev Size : 11711575296 (5584.51 GiB 5996.33 GB)
Data Offset : 2048 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 1a222812:ac39920b:4cec73c4:81aa9b63
Reshape pos'n : 1928186496 (1838.86 GiB 1974.46 GB)
Delta Devices : 1 (2->3)
Update Time : Fri Mar 17 23:14:25 2017
Checksum : cb34324c - expected cb343250
Events : 31468
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing)
ご覧のように、それは変形の進行状況の正確な位置を報告しました。これは、以前に取得した数が512バイトセクターの数であることも教えてくれます。
最初の1838.86 GiBが再形成中に上書きされたことがわかったので、残りのパーティションは変更されていないと想定しました。
したがって、私は新しいRAID5パーツと手つかずのパーツから、報告されたリスペースの位置でカットして、ブロックデバイスを組み立てることにしました(位置の推定については以下の注意をお読みください)。データオフセットは2048セクターであるため、生のパーティション部分のオフセットを取得するには、サイズに1024KiBを追加する必要があります。
#losetup -f --show /dev/md124 --sizelimit=1928186496K
/dev/loop0
#losetup -f --show /dev/sda5 --offset=1928187520K
/dev/loop1
パーツを組み立てるために、メタデータなしでJBODデバイスを作成しました。
# mdadm --build --raid-devices=2 --level=linear /dev/md9 /dev/loop0 /dev/loop1
mdadm: array /dev/md9 built and started.
次に、新しい/ dev/md9デバイスの内容を確認しました
# file -s /dev/md9
/dev/md9: LVM2 PV (Linux Logical Volume Manager), UUID: xmhBdx-uED6-hN53-HOeU-ONy1-29Yc-VfIDQt, size: 5996326551552
RAIDにはLVMボリュームが含まれていたため、ext4ファイルシステムにアクセスするには最初の576KiBをスキップする必要がありました。
# losetup -f --show /dev/md9 --offset=576K
/dev/loop2
# file -s /dev/loop2
/dev/loop2: Linux rev 1.0 ext4 filesystem data, UUID=8e240e88-4d2b-4de8-bcaa-0836f9b70bb5, volume name "1.42.6-5004" (errors) (extents) (64bit) (large files) (huge files)
次に、ファイルシステムをNASの共有フォルダーにマウントしました。
# mount -o ro,noload /dev/loop2 /volume1/homes/fixraid/
そして私のファイルにアクセスできました!
上で使用した位置のサイズ/オフセットを決定する前に、いくつかの値を試しました。私の最初のアイデアは、1838.86 GiB各デバイスの形状が変更されたため、RAID5パーツには3.6 TiBの有効なデータが含まれるため、形状変更位置の2倍の位置を使用しました。それは正常にマウントされましたが、一部のファイルに無効なデータが含まれているようで、一部のファイルの読み取り時にI/Oエラーが発生し、一部のフォルダーが欠落していました。
NEF(Nikon)形式のRAW写真がたくさんあったので、ファイルツールを使用してこれらのいくつかをテストすることにしました。
期待される結果:
# file DSC_7421.NEF
DSC_7421.NEF: TIFF image data, little-endian, direntries=28, height=120, bps=352, compression=none, PhotometricIntepretation=RGB, manufacturer=NIKON CORPORATION, model=NIKON D750, orientation=upper-left, width=160
データが破損した場合の結果:
# file DSC_9974.NEF
DSC_9974.NEF: data
また、特定のフォルダーにls
を書き込んだときに、いくつかのIOエラーが発生しました。
私は自分の大きな写真コレクションのいくつかに行き、それらの完全性をテストすることにしました-最初にファイルをリストし、出力の行数を数えることによって。その後、読み取りエラーがあれば画面に書き込まれます。次に、NEFファイルのいずれかが認識されていないかどうかを確認することにより、破損したデータを示します。ファイルからの出力をフィルタリングし、フィルタリングされた行をカウントしました。
# ls *.NEF -1 | wc -l
3641
# file *.NEF | grep "NEF: data" | wc -l
0
私は多くの写真フォルダーに対してこれを行い、すべてのファイルが読み取り可能で、そのコンテンツが認識されるようにしました。
3856372992Kのサイズと3856374016Kのオフセットを使用して、大量の無効なデータと欠落しているファイル/フォルダーを取得し、他のいくつかの値を試しました。
上記のオフセットとサイズは、私の小さなテストに合格したようです。
上記のように、ファイルシステムはいくつかのエラーを報告します。すべてが回復する前にデバイスにデータを書き込みたくないので、スナップショット書き込みオーバーレイを作成することにしました。そのため、fsck.ext4によるすべての書き込みは、代わりにこのファイルに書き込まれます。
50GiBスパースファイルを作成する
# truncate /volume1/overlay.img -s50G
仮想デバイスを作成する
#losetup -f --show /volume1/overlay.img
/dev/loop3
データを使用してデバイスのサイズを取得します。
# blockdev --getsz /dev/loop2
11711574528
オーバーレイデバイスを作成します(この前に、/ dev/loop2でファイルシステムをアンマウントしました)。
# dmsetup create overlay --table "0 11711574528 snapshot /dev/loop2 /dev/loop3 P 8"
そして、デバイスは/dev/mapper/overlay
で入手可能でした
最後に、エラーを確認して修正できます。
# fsck.ext4 -y -C 0 /dev/mapper/overlay
修正はオーバーレイファイルにのみ書き込まれ、永続的である必要がある場合は物理ディスクにコミットする必要があることに注意してください。