データを復元しない方法、またはあなたはとても幸運です

ストレージデバイスの障害は定期的に発生します。 通常のOS要求にまだ応答するデバイスからの特別な機器なしで可能なすべてを読み取る方法について、インターネット上に何百もの指示が書かれています。 しかし、何年もの間、私は運が悪かった、ディスクが完全に、または完全に死んだか、ファイルシステムがまだ利用可能であり、通常モードで読み取られたすべてを読んだ。 そして彼は待っていた。 死にかけているディスクが、最も基本的なアクション以上のものを必要とする状態で正確に私のところに来たのは、発生しなければなりませんでしたか？



そして今、この日が来ました。 率直に言って、すべてのナンセンスを保持しているソフトウェアraid0の上のセクションでは、ファイルは利用できませんでした。その理由は、待望のI / Oエラーでした。 予想外に、ファイルのリストは利用できましたが、リードの後半のキャリアデバイスはfdiskの出力にはまったくありませんでした。 再起動-アレイが組み立てられ、ファイルが完全に読み込まれます。 SMARTレポートは、再割り当てされた膨大な数のセクターを示しています。 必要なものだけ。 ディスクをオフにし、回復戦略を検討し始めます。



生き残ったセクターを読み取るために、死にかけているディスクからデータを読み取るためのddの特殊バージョンであるGNU ddrescueを使用することが決定されました。



そこで、最初のディスクをデスクトップに接続すると、接続されたディスクの1つが本当に不良であるとPOSTが厳soleに報告します。 一部のデバイスataエラーに関するいくつかのメッセージを除き、OSは正常に起動しました。 fdisk -lを正常にロードした後、患者は、最終的にraid0データの整合性を復元します。

ddrescue -ndAvv /dev/sdd1 bad mapbad
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロセスは非常に活発に進み、80 MB /秒でした。 冷却ファンディスクのノイズのため、特にそのような場合に廃止されたサーバーから取られるため、死にかけているディスクを読んでいるような冷たい音は、たとえあったとしても聞こえません。 聞いていない方がいいかもしれません。 あなたはあまり知らない-より良く眠る。



朝までにddrescueの作業は完了し、新しいドライブに死にかけている仲間の画像と地図が置かれました。 しかし、何らかの理由でddrescueを再起動すると、疑わしいほど早く終了し、カードは





「何かが明らかにうまくいかなかった」と眠そうな内なる声が促した。 「そしてfdisk -lを試してください-そして心はすでに接続されています。 / dev / sddは出力にありませんでした。 「これはどのように可能ですか？」「ああ、同じことがサーバー上にあった」ので、それはすべてなくなっていませんでした：そのようなものは私の頭の中に一日中ありました。



夕方、実験ディスクは再び生命の兆候を示し、私は困難な仕事をしました： ddrescueは完成したマップで何も読むことを拒否し、パーティションのサイズよりも小さいイメージファイルを残したので、イメージをどうするか。

一方で、 ddrescueは、破損したファイルを後で特定するために、任意のデータでブロックを埋めることができます。 一方、スパースファイル（ -Sパラメーター）を作成するように彼に依頼したわけではありません。画像ファイルのセクションよりも小さい部分を正確に埋めるという質問の強化されたグーグルは未回答のままです。





私は本当にこのケースに頼りたくなかったので、電卓を手にしてディスクマップを調べることにしました。 ディスクの内容の96％が正常に読み取られ、最初の+ブロックに分類されたことが判明しました。 しかし、残念なことに、すべての+ブロックの合計が読み取りイメージのサイズを与えなかったため、すべてのカードが完全に混乱しました。 それが私が反対に行った理由です：私は良いスタートを切っており、悪魔は最後に何を知っているので、古き良きddを手に入れて、理解できないイメージから作業できるものを正確に作成しませんか？

 dd if=bad of=bad_new bs=16M count=42751 dd if=/dev/zero of=bad_new bs=1024 seek=700432384 count=32139617
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、真っ暗なパーティションとまったく同じサイズ、つまり750153729024バイトの新しいイメージが作成されます。 最後にゼロに到達しましょう。 手動で行う





そして実行：

 ddrescue -ndAvv /dev/sdd1 bad_new mapbad
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

やった！ 今ではすべてが順調です。 ディスクから読み取られたブロックは、目的のアドレスの新しいイメージの空のスペースに移動し、マップが再び完成し、私の冒険は終わりに近づいていました。 しかし、おそらく最後の飛躍をして、1つのセクターでブロックを再読み取りしますか？ 今すぐ救助を





そして次のように実行します：

 ddrescue -ndAvv /dev/sdd1 -1 bad_new mapbad
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般的に、彼は私が期待したようにまったく振る舞いませんでした。 ブロックの不良セクタにつまずいた後、彼は次のブロックに移り、最後のブロックから自信を持って読み取り値を取得するまで待ちました。 1時間後、CTRL-Cを使用してこの混乱を停止し、通常の速度で読み取りを開始しました。 セクションの最後から数ギガバイトは、 ddrescueが再び不良セクタに達するまで読み取られました。何らかの理由で、システムから/ dev / sddが消失し、カードが最終的に完成しました。 ブロック。 それをすべて整理することはもう意味がありませんでした。私は死にかけている男の拷問をやめ、最終的にアレイの組み立てを開始することにしました。 しかしその前に、塗りつぶしモードを使用するとどうなるかを知りたいと思いました。 カードを元のカードと交換することを忘れずに、プレースホルダーを準備し、充填モードをオンにします。

 printf "BADSECTOR" > tmpfile ddrescue --fill-mode=- tmpfile bad mapbad
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、適切なサイズの別の画像を取得します！ 彼がこれをどのように行ったかは謎です。なぜなら、サイズの合計とカードのブロックを数回数えたが、完成したファイルのサイズと一致しなかったからです。



そして今、磁気の魂を神に捧げる人の代わりに、彼の健康な兄弟はすでにあり、私はコマンドを実行します：

 losetup /dev/loop1 bad_new mdadm --assemble -o /dev/md12 /dev/loop1 /dev/sdd1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、結果は、控えめに言っても、24時間の成功を期待して期待したものではありません。

 mdadm: no RAID superblock on /dev/loop1 mdadm: /dev/loop1 has no superblock - assembly aborted
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、Googleやセクションと話をしてみましょう。

 #mdadm --examine /dev/loop1 mdadm: No md superblock detected on /dev/loop1.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-つまり、どのようにmdスーパーブロックが検出されないのですか？

-そして、これはまだ健康な人ですか？

 #mdadm --examine /dev/sdd1 /dev/sdd1: Magic : a92b4efc Version : 0.90.00 UUID : 64d38efd:b8e92c8c:f5292846:21864477 Creation Time : Fri Oct 10 20:22:23 2008 Raid Level : raid0 Raid Devices : 2 Total Devices : 2 Preferred Minor : 2 Update Time : Fri Oct 10 20:22:23 2008 State : active Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : 6f768a67 - correct Events : 1 Chunk Size : 4K
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-バージョン0.90.00？ そして、 mdadm 0.90.00スーパーブロックはどこにあるべきですか？

-セクションの最後。

-そして、 mdadmを使用してそれを読む方法は？

-いや。

-つまり、どのようになりますか？ さて、それでどこがより正確ですか？

-セクションの最後から128K以内、64K以内、64K、4Kサイズの境界に揃えて配置。



N-yes、私はddを取り、チェックします：

 dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 dd if=last128 of=bad_new bs=1024 seek=732571873 count=128
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、スーパーブロックはセクションの最後に正しいアドレスで記録されますが、2つの同一のスーパーブロックで配列を組み立てたくないので、死にかけているスーパーブロックからそのスーパーブロックを与える必要があります。



読んだだけの場合は、ドライブを再度交換します。

 #dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 dd: reading `/dev/sdd1': Input/output error 0+0 records in 0+0 records out
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「はい、グレートコンビネーターはそのような打撃を一度も経験したことがありません」と、何らかの理由で、この不滅の引用が私の記憶に浮かびました。

まあ、私たちはそれほど簡単にgiveめません。 そしてここにあります：

 dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 conv=noerror
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ああ、 last128 size> 0 but <128K。 それはどこですか？ どのように作業するのですか？ そして、殺されたセクターの代わりにタックトゥを作る方法は？ など：

 dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 conv=noerror,sync
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これが最後の128Kです。 イメージの最後にそれらを登録し、正常なディスクで再起動すると、アレイが組み立てられます！

簡単なコマンドが残っています。

 #mount -o ro /dev/md11 /srv/old/ mount: wrong fs type, bad option, bad superblock on /dev/md11, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まあ、これは何らかの形で完全に不快です。 アレイがサーバーに最後に構築され、 ext3がマウントされたとき。 dumpe2fsの出力は疑わしくありません。 クリーンセクションのステータス、代替スーパーブロックのアドレスは表示されますが、何らかの理由でマウントされません。 それを処理する必要がありますが、この形式で、バックアップなしの半分のデータでは、処理することは不可能です。 ええ、もう1テラバイトを投げる必要があります。 もちろん、良い方法で、 ddrescueを使用して現在条件付きで動作するディスクからイメージを作成する必要がありますが、これはすべて非常に疲れているため、これを行います：

 dd if=/dev/md11 of=ext3 bs=16M conv=noerror,sync
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、眠り、そして朝に私は試してみます：

 losetup /dev/loop2 ext3 mount -o ro /dev/loop2 /srv/old/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして搭載されています！ 一見したところのディレクトリ構造は変更されておらず、ハッシュのあるファイルはエラーなしで読み込まれました。 復元されたパーティションでは20 GBのみが空いているため、そのループファイルは当然の属性を受け取りました。

 chattr +i ext3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてfstabに書き込みます：

 /srv/ext3 /srv/old ext3 ro,loop 0 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論として、私はここを読んでお勧めします：

• 重要ではないデータの自動バックアップを設定します。
• SMARTレポートを定期的に表示し、
• USBからSATAデバイスまたはドライブに類似したものを使用して回復します。
• 死にかけている人のように、イメージを取得したいディスクを扱い、GNU ddrescueを使用します。
• 本当に重要なデータを回復することになると、そのような運は絶対にありません。