ext4 パーティションが失われました: testdisk はファイルをリストしますが、パーティション テーブルの修復に失敗します

ext4 パーティションが失われました: testdisk はファイルをリストしますが、パーティション テーブルの修復に失敗します

まとめ:

Testdisk は失われた ext4 パーティションを見つけ、含まれるファイルを一覧表示できますが、パーティション構造をディスクに書き込もうとしても何も起こりません。

アップデート: を実行後e2fsck -f /dev/sdc1、ディスクはマウントされ、正常に動作しているように見えます。ただし、いくつかのエラーも報告されています (以下の 15. を参照)。

どうしたの:

問題に関連して私が行ったすべてのことをリストアップしてみます:

  1. FAT32 として事前にフォーマットされた新しい外付け 5TB ハード ドライブ (Intenso という名前) を入手しました。
  2. そのパーティションを削除し、gparted を使用して新しい ext4 パーティション (Intenso5TB という名前) を作成しました。
  3. パーティションはルートに属していたため、所有者とグループを自分のユーザーに変更しました。
  4. 数百 GB のデータをそのパーティションに移動し、安全に削除しました。
  5. 次にハードドライブを接続したとき、ハードドライブは読み取り専用としてマウントされました。所有者は私のユーザーのままでした。
  6. Ubuntu の「ディスク」ユーティリティのマウント オプションに「rw」を追加し、ドライブをアンマウントしました。
  7. その後、ディスク ユーティリティはパーティション /dev/sdc1 を「タイプ不明」として表示し、マウントできませんでした。
  8. 「パーティションの編集」を選択し、「タイプ linux (0x83)」を選択しました (タイプは事前に選択されていませんでした)。変化はありませんでした (依然としてタイプは不明です)。
  9. 実行しsudo testdisk /dev/sdcて簡単な分析を行ったところ、次のことがわかりました。

    * Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]
    

    押すとpパーティションに移動したファイルが表示されますそこで、Testdisk にパーティション構造をディスクに書き込むように指示しました。

  10. パーティション テーブルを更新するためにもう一度再起動すると、動作は再び 7 で説明したとおりになりました。
  11. 9.をやり直しました。今回は

    partprobe /dev/sdc
    

    再度再起動を避けるために、次のメッセージが表示されました:

    Error: Partition(s) 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/sdc have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
    
  12. sudo fdisk -lu戻り値

    Disk /dev/sdc: 4,6 TiB, 5000981078016 bytes, 1220942646 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 33550336 bytes
    Disklabel type: dos
    Disk identifier: 0x4400838c
    
    Device     Boot Start        End    Sectors  Size Id Type
    /dev/sdc1  *      256 1220942591 1220942336  4,6T 83 Linux
    
  13. sudo parted /dev/sdc次に を実行しましたrescue 256 1220942591が、何も起こりませんでした (遅延なし、出力なし、parted 内に新しいコマンド プロンプトが表示されるだけ)。 、rescue 0 1220942591またはrescue 1 1220942591を実行した場合も同様ですrescue 1 -1

  14. Testdisk で徹底的な検索を実行したところ、次のような同一行がいくつか報告されました。

    Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]
    

    同様に:

    check_FAT: can't read FAT boot sector
    Invalid FAT boot sector
     0 D FAT16 LBA            252822 192 45 254047 161 57   19677685
      FAT16 LBA            252822 192 45 254047 161 57   19677685
    

    実行中に次のように終了しました:

    TestDisk 7.0, Data Recovery Utility, April 2015
    Christophe GRENIER <[email protected]>
    http://www.cgsecurity.org
    
    Disk /dev/sdc - 5000 GB / 4657 GiB - CHS 76000 255 63
    
    The harddisk (5000 GB / 4657 GiB) seems too small! (< 16 TB / 15 TiB)
    Check the harddisk size: HD jumpers settings, BIOS detection...
    
    The following partition can't be recovered:
         Partition               Start        End    Size in sectors
    >  FAT16 LBA            252822 192 45 254047 161 57   19677685
    
    
    
    
    
    
    
    
    
    
    [ Continue ]
    80 GB / 75 GiB
    
  15. を実行した後e2fsck -f /dev/sdc1、ディスクがランチャーに表示されました。詳細がわかるまでこれ以上の変更を避けるため、e2fsckでキャンセルしましたCtrl+C。クリックするとドライブが正常にマウントされました。読み取りと書き込みができるようです。 からの出力e2fsck:

    e2fsck -f /dev/sdc1
    e2fsck 1.42.13 (17-May-2015)
    ext2fs_open2: Bad magic number in super-block
    e2fsck: Superblock invalid, trying backup blocks...
    Superblock needs_recovery flag is clear, but journal has data.
    Recovery flag not set in backup superblock, so running journal anyway.
    Intenso5TB: recovering journal
    Pass 1: Checking inodes, blocks, and sizes
    Inode 59883521 is in use, but has dtime set.  Fix<y>? yes
    Inode 59883521 has imagic flag set.  Clear<y>? yes
    Inode 59883521 has compression flag set on filesystem compression support.  Clear<y>? yes
    Inode 59883521 has INDEX_FL flag set but is not a directory.
    Clear HTree index<y>? yes
    Inode 59883521, i_blocks is 16777216, should be 0.  Fix<y>? yes
    Deleted inode 59885573 has zero dtime.  Fix<y>? yes
    Deleted inode 59885574 has zero dtime.  Fix<y>? yes
    ^CIntenso5TB: e2fsck cancelled.
    
    Intenso5TB: ***** FILE SYSTEM WAS MODIFIED *****
    

私の質問:

  1. そもそもこの問題の原因となった明らかな間違いは何かあるのでしょうか?

  2. 失われたパーティションを回復できる見込みはありますか? 新しい質問: 報告されたエラーはe2fsck心配するべきものですか? 物理的に損傷したドライブを示唆している可能性がありますか?

  3. partprobe11でエラー メッセージが表示される原因は何ですか?

(データは、それ以来触れていない別のディスクから移動されたため、現在は表示されませんが、そこから復旧できるはずです。)

答え1

実行するとe2fsck -f /dev/sdc1不良スーパーブロックが修正され、デバイスは問題なく認識されました。その後、e2fsck検出されたすべての問題を修正しました。その後の実行では、e2fsckそれ以上のエラーは報告されませんでした。

9時間後にエラーなしで完了した拡張オフラインテストsmartctl(自動スピンダウンによるテストの中止を防ぐために、この回避策)。

関連情報