こんにちは
木曜日の夕方、管理者の XNUMX 人が KVM 仮想マシンの XNUMX つでディスクのサイズを変更する必要がありました。 まったく簡単な作業のように思えますが、データの完全な損失につながる可能性があります...つまり...全体のストーリーはすでにカットされています
すでに述べたように、木曜日の夕方（雨は降っていないようでした）、管理者の XNUMX 人が長年のタスクを完了し、KVM 仮想マシン内のファイル サイズを増やすことにしました。
以前は、ディスク自体のサイズを 14 GB から 60 GB にすでに増やしており、管理者は仮想マシン内のファイル システムのサイズを増やすだけで済みました。
夜の 12 時頃、管理者は拡張セクションとプライマリ セクションのどちらを作成すべきかを尋ねるメッセージを送信しました。それに応じて、私は仮想マシン自体で以前と同じようにする必要があると彼に書きました。
時間が経ちました...そして管理者は、エラーが発生し、パーティションを拡張できないと言いました...そしてマウントが停止しました...もう午前2時でした...
私は彼に、もう何もせず、仮想マシンを放っておいて、自分で VM ディスク イメージのコピーを作成し、それを vmname_bad と呼ぶようにと手紙を書きました。
管理者がアクションの前にスナップショットを取得せず、マークアップをコピーしなかったという事実により、すべてがさらに複雑になりました...この情報があれば、ロールバックして再試行できます。
朝、新たな考えで、同じ OS (Debian 9) で仮想マシンをセットアップし、ディスクを接続しました。 fdisk を通して、このディスクはすでに 60GB に拡張されており、パーティションが...実際には少し壊れていることがわかります。
管理者から提供されたスクリーンショットを使用して、前のマークアップを見つけようとしましたが、残念ながら無駄でした。 fdisk を使用して値を見つけようとしていますが、残念ながらすべての試みが失敗しました。
fdisk では助けてもらえないので、parted に助けを求めています。 Parted をロードしましょう - 古いパーティション rm 2 を削除し、おおよそのパーティション値がわかったら、レスキューします - パーティションが存在する可能性のある初期値と最終値を示します。 XNUMX分待って別れると、パーティションが見つかり、それに関する情報をシステムに入力するよう提案されます。私は同意して別れました。
パーティションをマウントします - すべて問題ありません。 ファイルは適切な場所にあり、すべて問題ありませんが、サイズはまだ 14GB のままです。 /dev/sdd1 をアンマウントし、resize2fs /dev/sdd1 を実行してから、e2fsck /dev/sdd1 を実行して再度マウントすると、既に拡張されており、すべてのファイルが含まれているパーティションが完全に生きていることがわかりました。
私にとっても管理者にとってもすべてがうまく終わりました。
出所： habr.com