AMNRハードドライブの障害回復(ext4)

AMNRハードドライブの障害回復(ext4)

ハードドライブの破損したパーティションからできるだけ多くのデータを回復しようとしています。残念ながら、fsckは問題を解決できませんでした。マウントの出力は次のとおりです。

$ sudo mount /dev/sda3 /mnt/
mount: wrong fs type, bad option, bad superblock on /dev/sda3,

dmesgの出力は次のようになります。

[77027.447708] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[77027.447714] ata1.00: irq_stat 0x40000001
[77027.447719] ata1.00: failed command: READ DMA
[77027.447726] ata1.00: cmd c8/00:08:00:28:c3/00:00:00:00:00/e8 tag 25 dma 4096 in
                    res 51/01:00:00:28:c3/00:00:08:00:00/e8 Emask 0x9 (media error)
[77027.447730] ata1.00: status: { DRDY ERR }
[77027.447733] ata1.00: error: { AMNF }
[77027.448901] ata1.00: configured for UDMA/100
[77027.448915] sd 0:0:0:0: [sda] tag#25 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[77027.448919] sd 0:0:0:0: [sda] tag#25 Sense Key : 0x3 [current] 
[77027.448922] sd 0:0:0:0: [sda] tag#25 ASC=0x13 ASCQ=0x0 
[77027.448926] sd 0:0:0:0: [sda] tag#25 CDB: opcode=0x28 28 00 08 c3 28 00 00 00 08 00
[77027.448929] blk_update_request: I/O error, dev sda, sector 147007488
[77027.448934] Buffer I/O error on dev sda3, logical block 0, async page read
[77027.448967] ata1: EH complete

Smartctlの出力は次のとおりです。

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   200   200   051    Pre-fail  Always       -       108
  3 Spin_Up_Time            0x0003   242   185   021    Pre-fail  Always       -       2891
  4 Start_Stop_Count        0x0032   081   081   000    Old_age   Always       -       19060
  5 Reallocated_Sector_Ct   0x0033   199   199   140    Pre-fail  Always       -       1
  7 Seek_Error_Rate         0x000f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   076   076   000    Old_age   Always       -       17595
 10 Spin_Retry_Count        0x0013   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   100   100   051    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   084   084   000    Old_age   Always       -       16934
190 Airflow_Temperature_Cel 0x0022   056   028   045    Old_age   Always   In_the_past 44
194 Temperature_Celsius     0x0022   106   078   000    Old_age   Always       -       44
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   182   182   000    Old_age   Always       -       761
198 Offline_Uncorrectable   0x0010   182   182   000    Old_age   Offline      -       763
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       1
200 Multi_Zone_Error_Rate   0x0009   161   127   051    Pre-fail  Offline      -       1311

..いくつかの過度の出力を削除しました...

After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
01 51 00 00 28 c3 e8  Error: AMNF at LBA = 0x08c32800 = 147007488

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
-- -- -- -- -- -- -- --  ----------------  --------------------
c8 00 08 00 28 c3 08 00      21:23:05.524  READ DMA
ca 00 08 20 31 bf 02 00      21:23:05.524  WRITE DMA
ca 00 08 20 30 bf 02 00      21:23:05.523  WRITE DMA
ca 00 08 60 2f bf 02 00      21:23:05.523  WRITE DMA
ca 00 08 08 2f bf 02 00      21:23:05.523  WRITE DMA

影響を受けるセクタは、パーティションの最初のセクタです。

代替スーパーブロック(mke2fs -n /dev/sda2を使用して検索)を使用しても、dumpe2fs、tune2fs、およびdebugfsはドライブを読み取ることができません。奇妙なことに、影響を受けたセクタを追加してもエラーは発生しません。

sudo dd if=/dev/sda of=/dev/null bs=512 skip=147007488 count=1
1+0 records in
1+0 records out
512 bytes copied, 0.000177462 s, 2.9 MB/s

データ復旧についてはあまり期待していませんが、これを試すのに必要なプロセスには興味があります。影響を受けたセクタにゼロを書く必要がありますか、それとも良い方法がありますか?

ありがとう

ベストアンサー1

使用救うddをインストールすると(読み取りエラーを無視する)、fsckさまざまなパラメータを使用してダンプされたイメージで実行できます-b

男fsck:

   -b superblock
          Instead  of  using  the  normal  superblock,  use an alternative
          superblock specified by superblock.   This  option  is  normally
          used  when the primary superblock has been corrupted.  The loca‐
          tion of the backup superblock is dependent on  the  filesystem's
          blocksize.    For  filesystems  with  1k  blocksizes,  a  backup
          superblock can be found at block 8193; for filesystems  with  2k
          blocksizes,  at  block  16384;  and  for 4k blocksizes, at block
          32768.

おすすめ記事