ネクタイ
実際、前奏曲。 彼は私のコンピューターに住んでおり、IDEコントローラーはnVidia MCP65に実装されています。 このコントローラーには、RAID 0およびRAID 1をサポートするRAIDコントローラーに変えるオプションがあります。私の場合、それぞれ250 GBの2つのSamsungのRAID 0です。 一般に、5年前にすでに超自然的なオンボードRAIDを驚かすことは困難でした。 誰かが「偽物」という接頭辞に興味がある場合、これがセミハードウェアRAID実装と呼ばれるものです。 指で分析します。
Windows 2003や、Debian Lenny GNU LinuxなどのOSでは、OSツールを使用してソフトウェアRAIDアレイを実装できます。 最初のケースでは、ディスクをいわゆるダイナミックディスクに変換し、そこで使用可能なパーティションを操作します。たとえば、LVMユーティリティを使用する場合です（一般に、「同様の」ダイナミックディスクでもあります）。 追加のコントローラーの必要性の欠如、操作のためのプロセッサー能力とRAMの使用など。
村の反対側から-ハードウェア実装、たとえば、 Intel SRCSATAWB ：最大16 SATAドライブ、RAIDレベル最大60、コントローラーコスト-約15,000ルーブル...最初のケースと比較-プロセッサーとRAMからの負荷の除去、ハードウェア実装、コストデバイスを購入します。
「ハードウェアRAID」と「ソフトウェアRAID」の概念は相反します。つまり、互いに反対ですが、中間バリアントが存在することを許可します。一般的な名前は「セミハードウェアRAID」または「フェイクRAID」です。 そのようなRAIDの作業の一部がOSのドライバーに委任されているかのように。 実際、ほとんどすべての作業は委任されています：偽のRAIDはぼろ（RAID）のふりをしてOSに伝えることができます。PCにはディスクが2つではなく、1つではあるが2倍以上あり、動作し、ディスクの基本的な監視を行い、知らないうちにディスクをRAIDアレイから外します（ただし、これもハードウェアRAIDの責任です）。 残りは、RAID 0、RAID 1、RAID 5（必要に応じて下線）の機能の実装に関する作業で、RAIDコントローラーのドライバーです。 ちなみに、このIMHOは偽RAIDの主な識別症状です。そのようなデバイスが標準IDEドライバーを使用するシステムで判別および動作できない場合、単一のドライブのように見えますが、独自のドライバー（偽、「偽」、ホーンとひづめ...
うーん...今、プレリュード。 =）自身の技術部門から、クライアントによって残された「動作しない」400 GB WDディスクを自由に使用できるようになったので、いくつかの新しいLinuxディストリビューションを見ることに再び決めました。 今回の選択は、Ubuntu 9.04 x86でした。 すでに構成されたシステムで、偽のRAIDにアクセスしようと突進しました。 昨年使用したユーティリティの名前は覚えていませんでした（ただし、後で覚えたのはdmraidでした）が、数分後に別のソフトウェアmdadmをGoogleで検索しました。 ubbyatnikでソフトウェアを見つけてインストールし、理解し始めました。Googleのどこかで、「 HPA用のドライブによって予約されたスペースを復元するのがいい」と言いました。 （ ビクトリアの助けを借りて）すぐに言われた。 それが判明したように-無駄に。 =）
RAIDが大好きなのは確かです。 ディスクはRAID 0アレイから脱落しているため、できることは、ネジが電源とコントローラー/マザーボードに接触しているかどうかを確認することです。 だからそれは私と一緒です：ディスクは接続されていますが、RAID-BIOSでは、アレイにはそのうちの1つしかありません。 オプションは、アレイを削除することです。
タイの終わりには、リモートRAID 0アレイ、無効化されたRAID-BIOS、利用可能なデータを備えた250ギガの2本の修理可能なネジ（つまり、両方のネジに塗りつけられている）、Ubuntuがインストールされた400 GBのブートネジ、および取得した「過労」を回復したいという同じ願望。
アクション
基本的に、アレイの劣化の原因がドライブのいずれかの障害ではなく、アレイの手動分解だけである場合（たとえば、私の場合のように人的要因の助けを借りて）、RAID 0からデータを回復するのに複雑なことはありません。 おそらくアレイ自体に関する情報を除いて、すべてのデータが配置されています（ただし、アレイからデータを回復するためにデジタル形式ではもはや必要ありません）。 主なことは、RAID 0がどのように構成されているか、 MBRとパーティションテーブルが何であるかを覚えて 、データを収集してアレイの構造を復元し、ディスクからデータをマージすることです。
私の場合のデータ回復アルゴリズムは次のとおりです。
1. 2つのディスクのうち、アレイの最初のディスクと、2番目のディスクを見つけます。
2.アレイ内のストライプのサイズを確認します。
3.このデータをソースとして使用するソフトウェアを使用すると、出力は復元されたデータを提供します（または、データにアクセスするための多かれ少なかれ単純なオプションを提供します）。
4.復元されたデータにアクセスします。
そして、これはすべてLinuxで行うことが望ましい-楽しみのために。 =）
アイテムを順番に並べ替えましょう。
1。
2つのドライブからのRAID 0アレイのデータは、アレイ全体で等しいブロック（ストライプ）で各ディスクに順次書き込まれます。
例：
最初のX Kb-LBAオフセットYでディスク1に（簡単にするために、Y = 0にすることができます-これはディスクの0セクターになります;ディスクの特定のパーティションをマージし、Yはこのセクションの初期セクターの数に等しいことが判明しました）、
次のX Kb-同じオフセットYでディスク2に、
次のX Kb-オフセットY + 1 *（X / 512）のディスク1
次のX Kb-オフセットY + 1 *（X / 512）のディスク2
次のX Kb-オフセットY + 2 *（X / 512）のディスク1
次のX Kb-オフセットY + 2 *（X / 512）のディスク2
次のX Kb-オフセットY + 3 *（X / 512）のディスク1
次のX Kb-オフセットY + 3 *（X / 512）のディスク2
...
16進エディタで両方のディスクのゼロセクターを調べることにより、どのディスクが最初であるかを判断することができます。この場合、アレイの最初のディスクのゼロセクターには、すべてのMBR機能を持つアレイのMBRが含まれます：オフセット510（55AA）の署名1FEh）ゼロセクターのバイト、「無効なパーティションテーブル」というテキスト。 一方、2番目のディスクのゼロセクターでは、これはほとんど確実に行われません。
sudo dd if=/dev/sdb of=/home/f/mbr01 count=1
sudo dd if=/dev/sdc of=/home/f/mbr02 count=1
ghex2 /home/f/mbr01
ghex2 /home/f/mbr02
私の場合、アレイの最初のディスクは/ dev / sdbで、2番目のディスクは/ dev / sdcでした。 以下のデバイスの順序が使用されます。
2。
アレイのストリップのサイズが64 Kbであることを漠然と思い出しました。 ただし、チェックが必要でした。
これを確認するのはそれほど難しくありませんが、手順1よりも厄介です。分析には、手順32で作成したものと同様のダンプが必要でした。
sudo dd if=/dev/sdb of=/home/f/dump01 count=65536
sudo dd if=/dev/sdc of=/home/f/dump02 count=65536
ghex2 /home/f/dump01
ghex2 /home/f/dump02
最大ストライプサイズから開始するのが理にかなっています-原則として64 KBです。 数値65536を16進数システムに変換すると（16進エディターでは、オフセットは自然に表示されます）、10000hになります。 この数の倍数である変位に沿って移動すると、次のことを確信します。これらの変位のすぐ上のデータは、これらの変位のすぐ下のデータと視覚的に非常に異なって見えます。
もちろん、そのようなディスプレイスメント（特にダンプの開始時）は、すべてがゼロの場合、またはその逆の場合、データディスプレイスメントの上下のエントロピーが非常に高いため、このディスプレイスメントが新しいストライプの始まりであるかどうかを結論付けることはできません。
16進エディターでは、オフセット、ストライプサイズ（10000h）の倍数でデータ領域を見つける必要があります。この領域で、ナビゲートして結論を導き出すことができます。
10000hの倍数のオフセットで、一部のデータがスキップされたように（そして、このオフセットでは、ほぼ確実になります）急激な遷移を観察するという確認を受け取ったら、次のステップは、ストライプのサイズが実際にできることを示唆することです2倍小さい-32 Kbまたは8000h。 所定のオフセットサイズに対して上記の操作を繰り返します。 同じ効果を持ついくつかのオフセットが見つかった場合-オフセット境界でデータパターンを変更した場合-ストライプサイズは実際には32 Kbになる可能性があると結論付けられます...ストライプの推定サイズを2倍に減らし-繰り返します...ストライプの現在の推定サイズについて、少なくとも1つのオフセットについて、少なくとも1つの確認に出くわした場合、高い確率で、オフセットの下の部分がオフセットを超える部分の継続であるデータを見つけました。 つまり、明らかに連続した一連のデータが表示されます。 これは、テキストファイルの内容を見つけたときに特に顕著です。 この場合、現在のストライプサイズを放棄し、2倍の前のストライプサイズのオプションに戻り、このオプションを慎重に確認します：テキストドキュメントまたは明らかにシーケンシャルな情報（もちろん、これはゼロのシーケンスとカオスに関係しませんガベージ）は変位境界で検出されないはずです。そうでない場合は、ストライプのサイズをさらに2倍増やす必要があります。
私の場合、ストライプのサイズが確認されました-64 Kb、つまり128セクター。 以下では、この番号が使用されます。
3。
既製のソリューションをGoogleが検索した結果、Windows用のソフトウェアもLinux用のソフトウェアも何も見つかりませんでした。検索が不十分だったかもしれませんが、あまりにも酔っていたかもしれません（ただし、同じことです）。 したがって、1つのディスクイメージファイル（アレイ）を作成するのが最も適切な方法であると判断し、そこで何らかの方法でそれを見つけ出します。 技術部門の従業員である私は、同志tozxと仕事をする名誉のある会社の倉庫でファイルイメージを記録するための媒体を借りました。 =）
Perlでのスクリプトのスキルが低かったのを思い出さなければなりませんでした。
#! /usr/bin/perl
use strict;
use warnings;
my $innnum = 0; # -, ex-
my $outnum = 0; # -, -
my $multipler = 128; # ;
my $lbasize = 488395008; # ex- , ( 128 )
my $timert1 = 0; #
my $timert2 = 0; #
while ($lbasize - $innnum >= $multipler) #
{
system ("dd if=/dev/sdb of=/media/recovery/image count=$multipler skip=$innnum seek=$outnum 2> /dev/null");
$outnum += $multipler;
system ("dd if=/dev/sdc of=/media/recovery/image count=$multipler skip=$innnum seek=$outnum 2> /dev/null");
$outnum += $multipler;
$innnum += $multipler;
$timert1++;
$timert2++;
if ($timert2 == 256) { #
$timert2 = 0;
print ("$innnum OF $lbasize\n");
}
if ($timert1 == 16192) { # ,
$timert1 = 0;
print ("So hot! Sleeping for 33 sec...\n");
sleep (33);
}
}
print ("DONE.\n");
セクター内の1つのディスクのサイズは、ビクトリアを使用するか、ディスク上のラベル（LBA）を調べることで確認できます。
4。
ここに 、いくつかの変更を加えた、使用したHDDイメージをマウントするためのレシピを示します。
sudo losetup /dev/loop0 /media/recovery/image
sudo fdisk -lu /dev/loop0
端末で、画像にあるセクションのリストを取得します。 私の場合：
/dev/loop0: 500.1 , 500116488192
255 heads, 63 sectors/track, 60802 cylinders, 976790016
Units = of 1 * 512 = 512 bytes
Disk identifier: 0xdf39af97
- Id
/dev/loop0p1 * 2048 83891429 41944691 7 HPFS/NTFS
/dev/loop0p2 83892224 488395055 202251416 7 HPFS/NTFS
目的のセクション（私の場合、2番目のセクションに興味がありました）で、「開始」列から数値を取得し、セクターサイズ（512）で乗算して42952818688を取得し、コマンドを入力します。
sudo losetup -o42952818688 /dev/loop1 /dev/loop0
その後、デバイス/ dev / loop1を対応するファイルシステムのパーティションとしてマウントします（事前にマウントするディレクトリを作成することを忘れずに）：
sudo mkdir /media/yuppi
sudo mount -t ntfs -o ro /dev/loop1 /media/yuppi
あとがき
「Everything About Everything」は4晩を過ごしました。 ディスクごとに500 GB（各250 GB）をコピーするのにほぼ1日かかりました。システムコマンドを呼び出す必要がある読み取りごとに、スクリプトがディスクから64 KBを読み取るという事実の影響を受けます。 読み取り速度は約15 Mb / sでした。 操作を高速化するために、真珠スクリプトは、ディスクからデータを読み取る複数のメガバイト（各物理ディスクに1つ）の2つのバッファー配列を追加し、読み取り後にこれらのバッファーからデータをイメージファイルに解析することで改善できます。 しかし、時間を無駄にするのは面倒でした。この機能を真珠に実装するには、説明した方法でゆっくりコピーするよりも時間がかかります。
何も失われなかったことに言及する必要があります... =）
成功。