web-dev-qa-db-ja.com

fsckがスーパーブロックまたはパーティションテーブルが破損していると言っているのはなぜですか？

ドライブのイメージ（dd）を作成し、そのドライブでファイルシステムチェックを実行しようとしています：ファイルシステムタイプ：ext3

これがfsckからの元のエラーです：

 fsck -fv -z ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.undo.$(date
+"%Y-%m-%d.%H.%M.%S").und /dev/loop2
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Overwriting existing filesystem; this can be undone using the command:
    e2undo ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.undo.2019-01-17.13.31.41.und /dev/loop2

The filesystem size (according to the superblock) is 122063840 blocks
The physical size of the device is 121604515 blocks
Either the superblock or the partition table is likely to be corrupt!

Fdisk -l/dev/sdaからの情報

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000794ac

Device     Boot  Start       End   Sectors   Size Id Type
/dev/sda1  *        32      8191      8160     4M  4 FAT16 <32M
/dev/sda2       262144 976773119 976510976 465.7G 83 Linux

Fdisk -l ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.imgからの情報

Disk ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img: 464 GiB, 498226311168 bytes, 973098264 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000794ac

Device                                              Boot  Start       End   Sectors   Size Id Type
./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img1 *        32      8191      8160     4M  4 FAT16 <32M
./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img2      262144 976773119 976510976 465.7G 83 Linux

私はパーティションのループデバイスを作成しました：

losetup --offset $((512*262144)) /dev/loop2 ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img

Blockdevから--getbsz/dev/loop2

4096

Blockdevから--getsz/dev/loop2

972836120

Dumpe2fs/dev/loop2から：

Filesystem UUID:          f68ccb5a-bcfa-4e8a-8876-45adaa6e6b85
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30523392
Block count:              122063840
Reserved block count:     6103192
Free blocks:              96939245
Free inodes:              30462657
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      994
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Sat Apr 26 21:28:22 2014
Last mount time:          Wed Jan 16 15:59:22 2019
Last write time:          Thu Jan 17 18:16:50 2019
Mount count:              17
Maximum mount count:      -1
Last checked:             Sat Apr 26 21:28:22 2014
Check interval:           0 (<none>)
Lifetime writes:          10 MB
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:      162d0daa-7968-48f9-8370-f095c9e19f58
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x000059bd
Journal start:            0

続いてたくさんの：

Group 0: (Blocks 0-32767)
  Primary superblock at 0, Group descriptors at 1-30
  Reserved GDT blocks at 31-1024
  Block bitmap at 1025 (+1025)
  Inode bitmap at 1026 (+1026)
  Inode table at 1027-1538 (+1027)
  4 free blocks, 8179 free inodes, 2 directories
...
(SKIPPING TO END)
...
Group 3725: (Blocks 122060800-122063839)
  Block bitmap at 122060800 (+0)
  Inode bitmap at 122060801 (+1)
  Inode table at 122060802-122061313 (+2)
  0 free blocks, 8192 free inodes, 0 directories

終了：

dumpe2fs: /dev/loop2: error reading bitmaps: Can't read a block bitmap

これで、/ dev/sda2を問題なくマウントして、ファイルを読み取ることができますが、/ dev/loop2をマウントすることはできません。

mount -t ext3 /dev/loop2 ./DriveImage/
mount: wrong fs type, bad option, bad superblock on /dev/loop2,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

次を使用してイメージから直接マウントしようとすると、同じエラーが発生します。

mount -o loop,offset=$((512*262144)) ./Seagate.ST3500320NS.SN-9QM5ZHHR.500GB.465GiB.img ./DriveImage

今dumpe2fsによると、スーパーブロックは正しいです！
そして数学によると：

 Superblock says:
 122063840
 Filesystem says:
 121604515

 block size:
 4096

 Math: Sectors * Sector Size = Size / Block Size = Blocks
 Partition 1: 
 8160 * 512 = 4177920 / 4096 = 1020
 Partition 2:
 [From fdisk]
 976510976 * 512 = 499973619712 / 4096 = 122063872
 [From blockdev with /dev/loop2]
 972836120 * 512 = 498092093440 / 4096 = 121604515

fdiskは適切なブロックにかなり近いと報告しています...（あと32ブロック）しかし、私の本では、fsckはblockdevと同じ方法で（またはそれを使用して）ブロックサイズ情報を取得していますが、dumpe2fsによると実際のパーティションテーブルを確認しています、スーパーブロックは実際には正しく、パーティションテーブルも同様です。

ディスク上の元のデータ（10年分の家族の写真/ビデオおよび重要なファイル）が失われるのを恐れて、元のディスク上でこのデータを実行することは望みません。そこで、このイメージにディスクのコピーを作成しました。また、何かを台無しにした場合に備えて、イメージのコピーも作成しました。 （心配しないでください、私はこれのためのディスクスペースを持っています）。

ここで何が悪いのですか？どうすれば修正できますか？

注：古いドライブに障害が発生し始めたため（いくつかの問題が発生したと想定）、これが私がこれを行っている理由です。
ALSO、何らかの理由でドライブがパーティションテーブルを失ったため、テストディスクを使用して回復する必要がありました。それが回復した後、私は大きなパーティションをマウントし、すべてのデータを読み取ることができました。
SO testdiskが正しく機能しているか、かなり近いので、すべて揃っていると思いました。

（更新＃1）元のドライブでfsckを実行しても、このエラーは発生しないことにも注意してください...

fsck -nfv /dev/sda2
fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

       60735 inodes used (0.20%, out of 30523392)
        1510 non-contiguous files (2.5%)
          49 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 23779/2425/0
    25124595 blocks used (20.58%, out of 122063840)
           0 bad blocks
           1 large file

       56022 regular files
        4704 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
       60726 files

（更新＃2）イメージファイルがドライブと同じではなく、イメージファイルが小さいことがわかりました。
ドライブサイズ：500107862016（ここで間違いがありました。正しい情報に更新された2番目のパーティションのサイズしか取得できませんでした）
画像サイズ：498226311168
画像ファイルに1881550848バイト、1.88GBを超えるデータがありません。 （これも修正されました）
ddがすべてを取得できなかったようで、ドライブに問題があるのは正しいかもしれませんが、ddに読み取りエラーを空白スペースで埋めて、サイズを一致させる方法はありますか？

ループデバイスでfsckを実行して、その機能を確認しています。混乱した場合は、背面のイメージを復元するだけです。

もう1つの重要な注意：これはヘッドレスサーバーシステムで、GUIではなくCLIです。

linuxfilesystemsdata-recoveryfilesystem-corruption
2
asmith

不良ディスクイメージからのエラー

ドライブの故障が原因で画像にエラーが表示されているようです。代わりに gddrescue を使用しますが、読み取りエラーを処理しようとします。

Gddrescue's manual は参考情報です、それはセクションです 10例のある小さなチュートリアル で始まります

例1：/ dev/sdaから/ dev/sdbに2つのext2パーティションがあるディスク全体の完全自動レスキュー。
注：事前に/ dev/sdbをパーティション分割する必要はありませんが、/ dev/sdaのパーティションテーブルが破損している場合は、何らかの方法で/ dev/sdbに再作成する必要があります。

ddrescue -f -r3 /dev/sda /dev/sdb mapfile
fdisk /dev/sdb
e2fsck -v -f /dev/sdb1
e2fsck -v -f /dev/sdb2

デバイス（/ dev/sdb）に直接レスキューする代わりに、ファイルを使用することができます。また、-r 3で開始して不良セクタを3回再試行する代わりに、デフォルト（0）と-n/--no-scrapeを使用して「スクレイピングフェーズをスキップ」し、できるだけ多くを取得します。最初にすばやく。

Gddrescueマップファイルのグラフィックビューを提供する ddrescueview パッケージもあります。これは興味深いかもしれません。

enter image description here

そして、syslogまたはdmesgを監視すると、以前に読み取りエラーが表示されているはずです。そのドライブを使用している間、それらを監視します。

バックアップする重要なファイルはたくさんありますか？

ファイルがまだ読み取り可能な場合、特にバックアップする重要なファイルがドライブ全体よりもはるかに小さい場合は、それらのファイルのみをコピーして、ドライブイメージ全体を忘れてください。 OSは簡単に再インストールできます。

フルディスクイメージのマウント

Like likelosetup -Pは、適切なパーティションループデバイス自体を作成するか、partprobeに加えてkpartxまたはgnome-disk-image-mounterを作成します。

1
Xen2050