仮想マシンで完全なデータ損失につながる可能性のある簡単な方法をお教えしますが、まだ解決方法は見つかりました：parted
ソースデータ：
OS：デビアブ9 64ビット
FS： LVMなしのext4
目的：仮想マシンのFSを14GBから60GBに拡張する
原則として、管理者にとってこのタスクは簡単ですが、スターが収束して、すべてが思い通りに進まないことがあります。 カットの下で、最初の管理者が動作するVMをほとんど受け取らなかったという事実につながるイベントのコースを復元しようとします。
1日目：
管理者には完全に簡単なタスクが与えられました-VM上のFSのサイズを拡張する必要があります。 以前は、このVMのディスクイメージを拡張する作業が既に行われていたため、VM上のFSのサイズを拡張するというタスクは小さいままでした。
VMのFS構造：
/ブート-56Mb
/-残りのすべてのスペース-ext4
仮想マシンはテンプレートから作成されるため、LVMはありません。これにより、手順全体が簡単になります。
そして、木曜日の夜に管理者がタスクの実行を開始します。 彼の最初の手順は、isoイメージ（SystemRescue）を使用してVMをブートすることでした。 iso-imageの助けを借りてVMを正常にロードした後、管理者は作業を開始し、fdiskの助けを借りて/（/ dev / vda2）セクションを削除します。 パーティション（/ dev / vda2）を削除した後、管理者は新しいパーティション-/ dev / vda2を作成し、ここで最初のエラーが発生します-管理者は最初に拡張パーティションを作成し、その後プライマリを作成し、新しいマークアップを比較した後、fdiskを終了してパーティションのマウントを試みます：
ディスクレイアウトが変更され、/ dev / vda5パーティションの開始と終了が変更されたため、スーパーブロックが見つからなかったかエラーであることを示す予期されるエラーが表示されました。 このエラーは非常に重大であり、間違った解決策に近づくと、ファイルを失ったり、beatられたりする可能性があります。 もちろんロールバックできますが、問題は、管理者が作業前に以前のディスクレイアウトのスクリーンショットを撮っていないという事実にもあります。
パーティションをマウントできないため、管理者は作成したパーティションを削除して新しいプライマリを作成することで状況を修正しようとしますが、データを含むバッチの終了を意味するものではないため、すべての試みは同じ結果につながります：
スーパーブロックが無効です。
自分でパーティションを復元しようと何度か試みた後、最初の管理者が2番目の管理者に助けを求めます。
最初に、2番目の管理者がVMを離れ、vm_bad_diskという名前の現在のディスクイメージをコピーします。 次に、VMは同じOSバージョン（Debian 9 64ビット）から立ち上がり、2番目のディスク（vm_bad_disk）に接続します。
sshを介して新しいVMにアクセスしました。VMのディスクのリストを確認します。
root@recovery:~# fdisk -l
Disk /dev/vda: 4.9 GiB, 5242880000 bytes, 10240000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x09dea38e
Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 499711 497664 243M 83 Linux
/dev/vda2 501758 10237951 9736194 4.7G 5 Extended
/dev/vda5 501760 10237951 9736192 4.7G 83 Linux
Disk /dev/vdb: 58.6 GiB, 62914560000 bytes, 122880000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe8c76303
Device Boot Start End Sectors Size Id Type
/dev/vdb1 * 2048 194559 192512 94M 83 Linux
/dev/vdb2 196606 30717951 30521346 14.6G 5 Extended
/dev/vdb5 198656 30717951 30519296 14.6G 83 Linux
これが/ dev / vdbです。これはvm_bad_diskです。 2番目の管理者が最初に/ dev / vdb2および/ dev / vdb5を削除し、194560が開始され、おおよその終了で/ dev / vdb2を作成しようとしますが、以下も取得されます：
スーパーブロックが無効です。
/ dev / vdbパーティションを使用するには、partedユーティリティがインストールされ、パーティションの操作がより便利になります。
/ dev / vdb2を既にpartedから削除し、ヘルプを実行してアクションを繰り返します。
管理者の注意はレスキューコマンドに向けられています。これにより、パーティションの開始と終了を設定して、FSを見つけることができます。 コマンド構文には複雑なものはありません。
partedを入力するだけです：
>救助
システムは次を尋ねます：
開始-194560を示しました
次に、管理者はEnd（パーティションの終わり）を計算する必要があります。 管理者はディスク全体のサイズが14GBであり、1セクターが512バイトであることを最初に知っていたため、次の計算が行われます。
14 GBは約15032385536バイトです。セクターの数を計算します。
15032385536/512 = 29360128
この値は、partedで指定する必要があります。
終了29360128
Enterを大胆に押して結果を待ちます...この場合、私は長く待つ必要はなく、FSが見つかったことと、変更を加える価値があるかどうかを示しました-はいと答えます
Partedは必要な変更を行い、管理者はpartedを終了します。
管理者はシステムのコマンドラインに戻り、次のことを行います。
マウント/ dev / vdb2 / mnt
パーティションは問題なくマウントされ、FSがまだ拡張されていないため、そのサイズが約14GBであることを示しています。これは正しいことです。 管理者はファイルをすばやくチェックし、一見したところアーティファクトや破損したファイルはないとすべてが言います。
パーティションはライブに見えるので、管理者はumount / dev / vdb2を実行して開始します。
検証が終了した後、 e2fsck / dev / vdb2-コマンドを実行してセクションを展開します。
resize2fs / dev / vdb2
操作は問題なく通過し、管理者はパーティションを再度マウントして、すべてが正常であることを確認します。
マウント/ dev / vdb2 / mnt
パーティションはエラーなしでマウントされ、 df -pコマンドを使用すると、既に拡張されたパーティションが表示されます。
管理者はこのバッチのファイルとディレクトリを再度確認し、ファイルシステムとファイルに問題がないことを確認します。
管理者はコマンドshutdown -p nowを実行し、アクションが実行されたVMからマッピングされたドライブを削除します。
元のVMディスクイメージを保存します。これにより、すべてが別のストレージで開始され、正しいディスクイメージに置き換えられ、VMが起動するように送信されます。
VMは問題なく起動し、すべてのデータが揃っています。
道徳：
1）アクションの前にスナップショットを撮る
2）目的の設定のスクリーンショットを撮ります（この場合、パーティションマークアップ）
3）作業の前に、重要なファイルをバックアップします