以前にmdadm
を使用してRAID-1にセットアップされた/dev/sdb1
と/dev/sdc2
がありますが、再インストールして古い構成を失いました。愚かさから、私は走った
Sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
rAIDを再構成しようとしています。ドライブを同期させた後(おっと?)、/dev/md0
、/dev/sdb1
、または/dev/sdc2
のいずれもマウントされません。 /dev/md0
の場合、スーパーブロックのマジックナンバーが悪いと文句を言います。 /dev/sd{b,c}1
の場合、iノードの欠落について文句を言います。
要するに、質問はこれです:私はすべてのデータを壊しただけですか、それともアレイをまだ回復することは可能ですか?
これらのパーティションのdumpe2fs
の出力は次のとおりです。
brent@codpiece:~$ Sudo dumpe2fs /dev/md0
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Bad magic number in super-block while trying to open /dev/md0
Couldn't find valid filesystem superblock.
brent@codpiece:~$ Sudo dumpe2fs /dev/sdb1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /var/media
Filesystem UUID: 1462d79f-8a10-4590-8d63-3fcc105b601d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61054976
Block count: 244189984
Reserved block count: 12209499
Free blocks: 59069396
Free inodes: 60960671
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 965
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Feb 10 21:04:42 2010
Last mount time: Fri May 10 20:25:34 2013
Last write time: Sun May 12 14:41:02 2013
Mount count: 189
Maximum mount count: 38
Last checked: Wed Feb 10 21:04:42 2010
Check interval: 15552000 (6 months)
Next check after: Mon Aug 9 22:04:42 2010
Lifetime writes: 250 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 7cd5ce46-b823-4453-aa66-00ddaff69952
Journal backup: inode blocks
dumpe2fs: A block group is missing an inode table while reading journal inode
編集:
@ hauke-lagingは、以前は1.0メタデータRAIDであったものの上に1.2メタデータバージョンRAID-1を作成したのは正しかったようです。正しいバージョンでmdadm --create
を再実行しましたが、ファイルシステムが破損しています。パーティションテーブルをいじる必要がありますか、それとも単にfsck /dev/md0
を実行できますか?
以下は、fsck
とdumpe2fs
の新しい出力です。
brent@codpiece:~$ Sudo fsck /dev/md0
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
The filesystem size (according to the superblock) is 244189984 blocks
The physical size of the device is 244189952 blocks
Either the superblock or the partition table is likely to be corrupt!
brent@codpiece:~$ Sudo dumpe2fs /dev/md0
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 1462d79f-8a10-4590-8d63-3fcc105b601d
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 61054976
Block count: 244189984
Reserved block count: 12209499
Free blocks: 240306893
Free inodes: 61054965
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 965
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Feb 10 21:04:42 2010
Last mount time: n/a
Last write time: Mon May 13 10:38:58 2013
Mount count: 0
Maximum mount count: 38
Last checked: Wed Feb 10 21:04:42 2010
Check interval: 15552000 (6 months)
Next check after: Mon Aug 9 22:04:42 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 7cd5ce46-b823-4453-aa66-00ddaff69952
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00215ad3
Journal start: 0
Group 0: (Blocks 0-32767) [ITABLE_ZEROED]
Checksum 0x4453, unused inodes 0
Primary superblock at 0, Group descriptors at 1-59
Reserved GDT blocks at 60-1024
Block bitmap at 1025 (+1025), Inode bitmap at 1041 (+1041)
Inode table at 1057-1568 (+1057)
23513 free blocks, 8181 free inodes, 2 directories
Free blocks: 12576-12591, 12864-12879, <...>
Free inodes:
Group 1: (Blocks 32768-65535) [ITABLE_ZEROED]
Checksum 0x348a, unused inodes 0
Backup superblock at 32768, Group descriptors at 32769-32827
Reserved GDT blocks at 32828-33792
Block bitmap at 1026 (bg #0 + 1026), Inode bitmap at 1042 (bg #0 + 1042)
Inode table at 1569-2080 (bg #0 + 1569)
31743 free blocks, 8192 free inodes, 0 directories
Free blocks: 43232-43239, 43264-43271, <...>
Free inodes:
Group 2: (Blocks 65536-98303) [ITABLE_ZEROED]
Checksum 0x2056, unused inodes 0
Block bitmap at 1027 (bg #0 + 1027), Inode bitmap at 1043 (bg #0 + 1043)
Inode table at 2081-2592 (bg #0 + 2081)
32768 free blocks, 8192 free inodes, 0 directories
Free blocks: 66417-66432, 66445-66456, 66891, <...>
Free inodes: 23921-24576
Group 3: (Blocks 98304-131071) [ITABLE_ZEROED]
Checksum 0x4254, unused inodes 0
Backup superblock at 98304, Group descriptors at 98305-98363
Reserved GDT blocks at 98364-99328
Block bitmap at 1028 (bg #0 + 1028), Inode bitmap at 1044 (bg #0 + 1044)
Inode table at 2593-3104 (bg #0 + 2593)
31743 free blocks, 8192 free inodes, 0 directories
Free blocks: 99334-99339, 99438-99443, 99456-99459, <...>
Free inodes: 24585-32768
Group 4: (Blocks 131072-163839) [ITABLE_ZEROED]
Checksum 0x6a00, unused inodes 0
Block bitmap at 1029 (bg #0 + 1029), Inode bitmap at 1045 (bg #0 + 1045)
Inode table at 3105-3616 (bg #0 + 3105)
32768 free blocks, 8192 free inodes, 0 directories
Free blocks: 131074-131075, 131124-131129, <...>
Free inodes: 32769-40960
Group 5: (Blocks 163840-196607) [ITABLE_ZEROED]
Checksum 0x37e0, unused inodes 0
Backup superblock at 163840, Group descriptors at 163841-163899
Reserved GDT blocks at 163900-164864
Block bitmap at 1030 (bg #0 + 1030), Inode bitmap at 1046 (bg #0 + 1046)
Inode table at 3617-4128 (bg #0 + 3617)
31743 free blocks, 8192 free inodes, 0 directories
Free blocks: 164968-164970, 164979, <...>
Free inodes: 40961-49152
Group 6: (Blocks 196608-229375) [ITABLE_ZEROED]
<...>
この質問を見てください 。それはあなたの問題に精通していると思います。
RAID-1を再作成し、同期しても、データが破壊されることはありません。明らかに、MDデバイスは別のオフセットで開始します。したがって、mountがスーパーブロックを探す場所にデータがあります。これは、少なくとも2つの方法で発生した可能性があります。
--metadata
のman mdadm
を参照)。したがって、スーパーブロックは現在別の位置にあります(またはサイズが異なります)。古いメタデータ形式が何であったかを知っていますか?mdadm --examine /dev/sdb1
(質問に出力を追加)を参照してください。ディスクの最初の領域(/ dev/sdb1)でスーパーブロックを探す必要があります。多分これはparted
または同様のツールで行うことができます。ただし、そのためにそれぞれのパーティションを削除する必要がある場合があります(パーティションテーブルを簡単にバックアップおよび復元できるため、問題ありません)。
または、ループデバイスを作成します/ DMオフセットが増加するデバイス(必ずしもディスク全体ではなく、数MiBで十分です)を作成し、それらに対してdumpe2fs -h
を試してください。これを実行する場合しかし、そのためのシェルコードを提供する方法がわかりません。
最悪のケースは、新しいMDスーパーブロックがファイルシステムスーパーブロックを上書きしたことです。その場合、スーパーブロックコピーを検索できます(mke2fs
の出力を参照)。同じサイズのダミーデバイスでmke2fs
を実行すると、スーパーブロックコピーの位置がわかる場合があります。
編集1:
これで、を読み、dumpe2fs
の出力を理解しました。古いRAID-1の最後にスーパーブロックがありました(0.9または1.0)。これでおそらく1.2になり、ファイルシステムの一部が上書きされました。被害の大きさを評価することはできません。これはe2fsck
の場合です。ただし、最初にRAIDを古いタイプにリセットする必要があります。古いバージョンを知るのに役立ちます。
DMデバイスを完全な/dev/sdb1
および/dev/sdc1
の上に置き、それらのスナップショットを作成し(dmsetup directly
を使用して)新しいアレイを作成することにより、リスクを減らすことができます。スナップショット。これにより、ディスクの関連部分が書き込まれなくなります。dumpe2fs
出力から、MDデバイスのサイズは1000202174464バイトである必要があることがわかります。これは、テストの作成後にすぐに確認する必要があります。