web-dev-qa-db-ja.com

パーティションを開こうとしているときに短い読み取り

Kubuntu Linux 13.04を実行している個人のホームコンピューターで、私にとって非常に重要なパーティションのマウントに問題があります。私のバックアップポリシーは、毎月約バックアップを実行することです。そのため、8月からバックアップを作成します:)。このドライブにある個人ファイルを回復する方法はありますか?

ドライブは1.5年前の1000ですGiB Western Digital Greenドライブ、ホームは/dev/sdc2にマウントされ、ファイルシステムルートは/dev/sdc6に、メディアファイルは/dev/sdc3。したがって、もちろんsdc2を使用することをお勧めします!私の知る限り、ドライブの稼働中に停電やその他のイベントは発生しませんでした。KubuntuLiveCDを実行して、なんとかこの情報を取得しました:

kubuntu@kubuntu:~$ Sudo fdisk -l

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 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
Disk identifier: 0x00008044

  Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        4094    88066047    44030977    5  Extended
/dev/sdc2        88066048  1419266047   665600000   83  Linux
/dev/sdc3      1419266048  1953523711   267128832   83  Linux
/dev/sdc5            4096     6146047     3070976   82  Linux swap / Solaris
/dev/sdc6         6148096    47106047    20478976   83  Linux
/dev/sdc7        47108096    88066047    20478976   83  Linux


kubuntu@kubuntu:~$ Sudo mount -t ext4 /dev/sdc2 c1
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
  missing codepage or helper program, or other error
  In some cases useful info is found in syslog - try
  dmesg | tail  or so


  kubuntu@kubuntu:~$ Sudo debugfs -c /dev/sdc2 
debugfs 1.42.5 (29-Jul-2012)

/dev/sdc2: Attempt to read block from filesystem resulted in short read while opening filesystem
debugfs:  quit


kubuntu@kubuntu:~$ Sudo fsck /dev/sdc2
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?


kubuntu@kubuntu:~$ Sudo fsck.ext4 -v /dev/sdc2
e2fsck 1.42.5 (29-Jul-2012)
    fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?


kubuntu@kubuntu:~$ dmesg | tail
[ 2684.532855] Descriptor sense data with sense descriptors (in hex):
[ 2684.532858]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 2684.532876]         05 3f c8 b0 
[ 2684.532885] sd 5:0:0:0: [sdc]  
[ 2684.532893] Add. Sense: Unrecovered read error - auto reallocate failed
[ 2684.532898] sd 5:0:0:0: [sdc] CDB: 
[ 2684.532902] Read(10): 28 00 05 3f c8 b0 00 00 08 00
[ 2684.532917] end_request: I/O error, dev sdc, sector 88066224
[ 2684.532927] Buffer I/O error on device sdc2, logical block 22
[ 2684.532973] ata6: EH complete

UnixとLinuxを助けてください。あなたが私たちの唯一の希望です。

8
dotancohen

まだ希望はありますが、ドライブにハードウェアの問題があるようです(dmesg出力の読み取りエラーの私の解釈)。

そのパーティションから回復可能なもののコピーを別のドライブに作成する必要があります(ディスクアクセスを最小限に抑えるため)。そのためには ddrescue を使用します。時間がかかる場合がありますが、パーティションの回復可能なデータのすべてではないにしても、ほとんどが取得されます。

可能であれば、別のディスク、Live CDから起動するか、独自のLinuxが起動する別のコンピューターにドライブを接続します。私がそうする理由は、ddrescueの実行中に読み取りエラーが他のパーティションのディスクアクセス速度に影響を与える可能性があるためです。

そのコピーを取得したら、元のコピーを別のディスクのファイルとして呼び出し、そのコピーのコピーを作成します。次に、そのコピーに対してファイルシステムチェックを実行してください。その回復によってコピーがスクランブルされた場合は、元のコピーから始めて、もう一度何かを試すことができます。

4
Timo

(これは古い質問であることを知っています。自分でこの問題に遭遇し、FSをddrescueなしで復活させたので、他の人のために経験を共有しますこれに遭遇する]

Ext filesystemsはスーパーブロックのバックアップを保存します-このような場合のために。

最初に、バックアップの場所を決定します(-nオプションがあることを確認してください!そうでない場合、これにより新しいファイルシステムでファイルシステムがワイプされます)。

mke2fs -n /dev/sdxx

これは、FS作成ルーチンのテスト実行(つまり、書き込みなし)です。ファイルシステムを作成している場合は、オフセットの場所を通知しますwouldスーパーブロックバックアップを配置します。 FSブロックサイズが4096以外のサイズであることがわかっている場合は、正しい値を取得するためにパラメータ-b {blocksize}も指定する必要があります。

4096サイズのブロックの場合、最初のバックアップスーパーブロックは32768になります。次の操作が失敗し、スーパーブロックの不良/短い読み取りに関する同じエラーメッセージが表示される場合は、mke2fsが提供したリストから次のスーパーブロックバックアップを試してください。

次に、このようなバックアップスーパーブロックを使用してファイルシステムをマウントすることができます

mount -o sb=32768 /dev/sdxx /mnt/sdxx

次に、ファイルマネージャからFSを調べ、破損していないファイルなどをコピーします。

または、実際にFSを修正するには、次のようにバックアップスーパーブロックを使用してfsckを実行します

e2fsck -fy -b 32768 /dev/sdxx

ここで-fは、ダーティではない場合でもディスクをスキャンし、-yは、修正に関するすべての問い合わせに対してyesと回答します。 -bオプションは、バックアップスーパーブロックの指定とは別に、バックアップの情報で元のスーパーブロックを更新します。

この後、ファイルシステムを元に戻す必要があります。

e2fsckがメインスーパーブロックの書き込みに失敗した場合スーパーブロックが不良セクター上にあるために破損した場合e2fsckは実行を終了し、更新を試みますスーパーブロック、そしてあなたに次のエラーメッセージを与えます:

Error writing block 1 (Attempt to write block from filesystem resulted in short write)

明らかに、メインのスーパーブロックは更新されておらず、e2fsckの実行全体が無駄になっています。

そのセクターにゼロを書き込むことによって、そのセクターを再マップするためにディスクにヒントを与える必要があります。これを指摘してくれた@Keithに感謝します。次のコマンドは、タイプミスを行うと多くの混乱を引き起こす可能性があるため、実行する前にそれをトリプルチェックしてください。ここに魔法があります:

dd if=/dev/zero of=/dev/sdxx bs=4096 count=1 seek=0

これにより、4096サイズのゼロのブロック1つがオフセット0のsdxxに書き込まれます。その場合は、異なるブロックサイズを考慮することを忘れないでください。

その後、スーパーブロックに書き込むことができます(これは、透過的に別の物理セクターにあります)。ここで、上記のe2fsckコマンドを再度実行すると、スーパーブロックの書き込みに成功し、FSを正常にマウントできるようになります。

言うまでもありません次に、重要なデータを別のphysicalドライブにバックアップし、ファイルシステムの使用を計画している場合は、走る

e2fsck -fccy /dev/sdxx

[〜#〜] ps [〜#〜]この検索に関する@Nemoへの称賛:FSのスーパーブロックのすべてのバックアップが破損している場合は、mke2fs/mkfsには-Sオプションがあり、新しいファイルシステムを作成する場合と同じようにスーパーブロックとグループ記述子を再作成します。 しかしブロックサイズが正しいことを絶対に確認する必要があり、manページにはその後にe2fsckを実行する必要があると記載されており、保証はありません救助のために残されているデータ。 manページをお読みください そして この答え にプラスを投げます。

14
Ivan Bartsov