誤って初期化されたデータストアからの仮想マシンの復元。 ハッピーエンドを迎えるたった一人の愚かな物語

免責事項： このメモは娯楽目的で使用されます。 そこに含まれる有用な情報の密度は低いです。 「自分のため」に書いたものです。

叙情的な紹介

私たちの組織のファイル ダンプは、Windows Server 6 を実行している VMware ESXi 2016 仮想マシン上で実行されています。これは単なるガベージ ダンプではありません。 これは構造部門間のファイル交換サーバーです。コラボレーション、プロジェクト文書、ネットワーク スキャナーからのフォルダーがあります。 一般に、すべての生産生活はここにあります。

そして、このすべての生産生活の容器がぶら下がり始めました。 さらに、ゲストは他の人に影響を与えることなく、静かに首を吊ることができました。 彼はホスト全体をダウンさせ、それに応じて他のすべてのゲスト マシンをダウンさせることができました。 首を吊って vSphere クライアント サービスをハングさせる可能性があります。つまり、他のゲストのプロセスは生きており、マシンは適切に動作して応答しますが、ファイル ウォッシャーがなく、vSphere クライアントがホストに固執しません。 一般に、システムを特定できませんでした。 日中の低負荷時にはフリーズが発生する可能性があります。 彼らは夜間の無負荷時にそれを行うことができました。 夜間の差分バックアップおよび平均負荷中に発生する可能性があります。 週末の完全バックアップ時や高負荷時に発生する可能性があります。 そして状況は明らかに悪化した。 最初はXNUMX年にXNUMX回、その後は半年にXNUMX回でした。 私の忍耐の終わりに - 週にXNUMX回。
記憶力に問題がありました。 しかし、週末であってもゴミの山を止めて Memtest を実行することは許可されませんでした。 ５月の連休を待っていました。 XNUMX 月の休暇中に Memtest を実行しましたが、エラーは見つかりませんでした。

私はびっくりして休暇を取ることにしました。 私が休暇中、ゴミ捨て場には一件も引っかかりはなかった。 そして月曜日の初日に仕事に戻ると、そこにはゴミの山がありました。 完全バックアップに耐えましたが、完了後すぐにハングしました。 休暇からのこのような温かい歓迎を受けて、私はゲスト マシンのディスクを別のホストに物理的にドラッグするという決断をしました。

そして、休暇明けの初日は何も真剣なことをしてはいけないことは昔から知られていましたが、私は会社までは働かないつもりでいたのですが、またしても凍り付いたことへの憤りで気分も気分も混乱してしまいました。頭の中で誓う…

物理ディスクが別のホストに移動されました。 熱いつながり。 タブのストレージ設定で ドライブ ディスクが表示されます。 タブ上 データストア これらのディスクにはストレージがありません。 Refresh - 表示されません。 まあ、もちろん、最初の衝動は - ストレージを追加。 追加ウィザードでは、何がサポートされているかについて説明します。 もちろんVMFSにも対応しています。 私はそれを疑いませんでした。 各ステップでのウィザードのメッセージを簡単に確認します: [次へ]、[次へ]、[次へ]、[完了]。 主人の階段の一つの窓の下にある、感嘆符の付いた小さな黄色い丸を目で捉えることさえできませんでした。

ウィザードの最後に、新しいデータストアがリストに表示され、それとともに残りの物理ディスクのデータストアも表示されます。

新しく追加されたデータストア内を移動しますが、データストアは空です。 もちろん、私はまた驚きました。 午前8時、休暇明けの最初の15分間、まだコーヒーに砂糖を入れていません。 そしてここにあります。 最初に考えたのは、「ネイティブ」ホストから間違ったディスクを取り出したのではないかということでした。 必要なデータストアが「ネイティブ」ホストに存在するかどうかを確認しました。いいえ、存在しませんでした。 XNUMX番目に思ったのは、「くそー！」ということだった。 よくわかりませんが、XNUMX 番目、XNUMX 番目、少なくとも XNUMX 番目の考えは同じだったと思われます。

疑念を払拭するために、私はテスト用に新しい ESXi をすぐにインストールし、左側のディスクを取り出し、すでにそれを読み取ってウィザードの手順を実行しました。 はい。 ウィザードを使用してデータストアを追加すると、ディスク上のすべてのデータが失われ、操作をロールバックしてデータを復元できなくなります。 その後、フォーラムの XNUMX つで、マスターによるこのデザインの評価を読みました。「くだらないクソだ。」 そして私も本当に同意しました。

3番目から、思考はより建設的な方向に流れました。 わかりました。 初期化には、XNUMXTb ディスクでも数秒かかります。 つまり、これは高レベルの書式設定です。 これは、パーティション テーブルが単純に書き換えられたことを意味します。 したがって、データはまだ残っています。 それでは、フォーマットされていないものを探してみます。これで出来上がりです。

Strelec ブート イメージからマシンを起動します...そして、パーティション回復プログラムが VMFS 以外のすべてを認識していることがわかりました。 たとえば、Synology のパーティション レイアウトは知っていますが、VMFS は知りません。

プログラム全体の検索は安心できるものではありません。GetDataBack と R.Saver は、せいぜい、ライブ ディレクトリ構造とライブ ファイル名を持つ NTFS パーティションを見つけます。 でも、これは私には似合わないんです。 システム ディスクとゴミ箱ファイル ディスクの XNUMX つの vmdk ファイルが必要です。

そして、Windows をインストールし、ファイル バックアップからロールアウトすることになるようです。 そして同時に、そこに DFS ルートがあったことを思い出しました。 また、部門フォルダーへのアクセス権のシステムも、範囲と影響がまったく多岐にわたります。 オプションではありません。 時間的に許容できる唯一のオプションは、データとすべての権限を備えたシステムとディスクの状態を復元することです。

再び Google、フォーラム、KB'shki、そして再び Yaroslavna が叫びました。VMware ESXi はデータ回復メカニズムを提供しません。 すべてのディスカッション スレッドには XNUMX つの結末があります。誰かが高価な DiskInternals VMFS Recovery を使用して回復されたか、誰かが自分のサービスを積極的に宣伝しているソフトウェア スペシャリストによって助けられたかです。 vmfs ツール и dd。 DiskInternals VMFS Recovery ライセンスを 700 ドルで購入するというオプションはありません。 「潜在的な敵の領域」からの部外者に企業データへのアクセスを許可することも選択肢ではありません。 しかし、Googleで調べたところ、VMFSパーティションはUFS Explorerでも読み取ることができました。

DiskInternals VMFS リカバリ

体験版をダウンロードしてインストールしました。 プログラムは空の VMFS パーティションを正常に認識しました。

モードで 削除の取り消し (高速スキャン) また、内部にディスクを含む仮想マシンのフォルダーが含まれる粗末なデータストアも見つけました。

プレビューでは、ファイルが生きていることが示されました。

システムへのパーティションのマウントは成功しましたが、何らかの理由で、XNUMX つのフォルダーすべてに同じ仮想マシンが含まれていました。 もちろん、法律によれば、卑劣なことは要求されていません。

恥の三行恥知らずにもソフトウェアをロックしようとする試みは失敗に終わりました。 しかし、UFS Explorer がロックアップしてしまいました。

私はソフトウェアの盗難に対して非常に否定的な態度をとっています。 私は、無許可使用に対する保護を回避する手段の使用を決して推奨しません。

私は壊滅的な状況にありましたが、自分が講じた対策をまったく誇りに思っていませんでした。

UFSエクスプローラー

ディスク スキャンにより、7 つのノードの存在が示されました。 ノードの数は、VMFS Recovery によって検出された *- flat.vmdk ファイルの数と「驚くべきことに」一致しました。

ファイル サイズとノード サイズを比較すると、バイトまで一致していることがわかりました。 同時に、*- flat.vmdk ファイルの名前と、それに応じて仮想マシンに属するファイルの名前が復元されました。

一般に、ESXi の観点から見た vmdk ディスクは、データ ファイル (<マシン名>- flat.vmdk) と「物理」ディスク レイアウト ファイル (<マシン名>.vmdk) の XNUMX つのファイルで構成されます。 *- flat.vmdk ファイルをローカル マシンからデータストアにアップロードすると、ESXi はそれを有効なディスク ファイルとして認識しません。 VMware ナレッジ ベースには、ディスク記述子ファイルを手動で作成する方法に関する記事があります。 kb.vmware.com/s/article/1002511ただし、これを行う必要はなく、DiskInternals VMFS Recovery のファイル コンテンツ プレビュー領域から対応するファイルのコンテンツをコピーするだけでした。

UFS Explorer から 4 TB ノードをアンロードして 2,5 時間、ハイパーバイザーのデータストアにロードして 20 時間後、クラッシュしたディスク ファイルが新しく作成された仮想マシンに接続されました。 ディスクが拾えました。 データの損失は観察されませんでした。

出所： habr.com