誤ってdd外付けディスクの最初の208MBを使って書きました。私はそれを独自のパーティション（Debian Nestinstaller）に書き込んだので、以前（今は破損している）ext4パーティションの代わりに別の小さなパーティションを見ています。これは私が従うことができるツールとアドバイスを制限します。
私の計画はパーティションテーブルを再作成し、testdisk以下に説明するようにバックアップスーパーブロックを使用してすべてを変更することです。ここ。最初の208MBは失われますが、その中に含まれている他の300GBのデータと比較すると悪くはありません。このように：
mke2fs -n /dev/sdb1 # doesn't work because sdb1 is the 208MB new partition
testdisk ... # used this to create new correct partition table
mke2fs -n /dev/sdb1 # now works fine, get backup superblock positions
e2fsck -b backup_position -y /dev/sdb1 # returns many errors hence the -y
しかし、何も救うためにできることは何もありませんでした。testdisk以前に分割されたテーブルと一致する新しいパーティションテーブルを作成したことがあります。 e2fsckを実行すると、さまざまなエラーが発生します。後でファイルシステムを入手しましたが、ファイルなしで完全に空でした。
Lost + Foundディレクトリはファイル（復元されたファイルであると仮定）でいっぱいですが、ファイルだけでなくディレクトリツリーも復元する必要があります。ファイルが何であるか（顕微鏡画像、質量分析データなど）を知るには、ファイル名と古いディレクトリが必要です。名前とファイルを含むディレクトリがない場合は意味がありません。
私は別の同じハードドライブを入手してドライブ全体のコピーを作成し、dd何も失うことなく回復を試みることができました。どんな提案がありますか？
答え1
ついにこの問題を解決できました。ちなみに私がする方法はこんな感じです。私が見つけた解決策の一部こここれには、ファイルシステムの作成に使用された設定を理解することが含まれます（デフォルトは変更されていないと確信しています）。
デフォルトでは、最初に実際に持っているパーティションテーブルを反映するためにパーティションテーブルを変更する必要がありました（testdiskこれには使用しましたがparted正しく機能するcfdisk必要がありますfdisk）。間違ったパーティションを削除し、正しいCHS値でディスク全体を含む単一のext4タイプパーティションに置き換えました。
残りはほとんど最初のリンクから取られましたが（詳細は読んでください）、基本的にmke2fs -n /dev/xxxスーパーブロックのバックアップがどこにあるかを見つけるために走りました。次に、ディスクの最後に最も近い最後のバックアップを使用してfsckを実行します（ディスクの先頭のバックアップのみがddで上書きされます）。これにより多くのエラーが発生しますが、fsckには-yオプションがあります（fsckとは異なります-a）。
$ sudo e2fsck -a -b backup_block_number /dev/xxx
ファイルが見えないので、これはうまくいかないようですが、実際にはすべてそのlost+foundディレクトリに保存されています。
そのため、最終的にファイル名とディレクトリ構造を維持しながら、ほとんどのファイルを保存しました。これが今後他の人に役立つことを願っています。
答え2
いいですね。 MegaRAIDアレイから予期せず起動したドライブを回復するのに効果的です。私のRAIDコントローラは、再構築中のRAID6アレイのドライブだけでなく、RAIDのすべてのドライブを初期化しました。あや！少なくとも遅い初期化ではなく、高速初期化を行いました。遅い初期化のため、ドライブがゼロに消去されました。
クイック初期化はドライブの最初と最後の10Mをクリアします。したがって、ドライブ全体（Linuxの場合）にext4パーティションがあり、ドライブRAID0があります。ドライブが6TBドライブで、ほぼ5TBがあるため、汗が出ます。私が再構成しているRAID6アレイのバックアップです！
しかし、私は間違いをしませんでした。 LSI MegaRAIDは他のドライブグループのドライブを初期化しないでください。私がしなければならないのは、エンクロージャからドライブを取り外し、新しく配置されたRAID6ドライブグループがある場合は再インポートすることです。愚かな私。私は本当に愚かです...
幸いなことに、LSI MegaRaidはRAID0ドライブに対して特別な機能を実行しません（または1つ以上があるかどうかはわかりません）。私が解決した方法は次のとおりです。 OS = Fedora F22。ドライブ=大きなext4パーティション、partedで完了しました。まず、2つのスペアベイスロットを持つスペアサーバー上の正確な新しいモデルにドライブのスナップショットを撮ります。 ：10時間後に作業が完了しました...
$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s
それは私の黄金の支持です。
ノート -私のドライブは/dev/sdb- 回復したいドライブにドライブを設定する必要があります。ドライブを台無しにしないでください。そうでなければ、より大きな混乱に陥ります。
その後、次のことを行いました。
(1) マシンからスナップショットを削除します。 （それは愚かなことではありません。大胆です。失敗した場合は、地元の緊急治療室にチェックインしている間、人はディスク回復病院に送られます！）
(2) ドライバでFC22機器を再起動します。 partedを実行してパーティションを再実行してください（私の場合は、破損したパーティションを削除して新しい0％〜100％ext4パーティションを作成してください）。生のパーティションがどこにあるか、正確なタイプが何であるかを正確に知る必要があります。次のステップはそれに応じて異なります。そうでない場合は、ここで停止してください。あなたは成功しないでしょう。testdiskおよび/または同様の方法を使用するか、photorec本当に重要な大型ドライブの場合に転送します。
（3）走る mke2fs -n /dev/sdb1（忘れないでください-n。さもなければ歩くことができます...）
私にとって結果は次のとおりです。
$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
それはすべてです。すべてのスペアスーパーブロックがある場所です。最初と最後のスーパーブロックはゴミであることがわかりますが、中間のスーパーブロックは問題ありません。 （非常に気をつければ mkfs.ext4 -n /dev/sdb1同じ結果が得られます。）
（4）実行しますe2fsck -y -b 102400000 /dev/sdb1。-y不足しているディスクの前面に起因する混乱を解決するには、多くの「はい」が必要です。状況を確認または点滅するディスクインジケータ）、マウント可能なパーティション、およびディレクトリのほとんどすべてをそのままにします/lost+found。
とにかく、これが役に立つことを願っています。そして、この記事を注意深く読んだら幸いです。上記を書いてくれた人に感謝します。本当に嫌な結末で私を救ってくれました…