AWS EBSルートボリュームのサイズを小さくするにはどうすればよいですか？
EC2インスタンスの拡大は、息のように簡単です（たとえば、AMIを作成し、そこからインスタンスを起動して、ストレージサイズを変更します）。
しかし、それを減らすことはより困難になります。アマゾンウェブサービス（AWS）EC2インスタンスのElastic Block Store（EBS）ルートボリュームのサイズを小さくしたいのですが。ネットには古い高レベルの手順がいくつかあります。私が見つけたより詳細なバージョンは、StackOverflowの質問に対する1年前の回答です： ebsボリュームの容量を減らす方法 、ステップはかなり高いレベル：
希望するサイズの新しいEBSボリュームを作成します（例：/ dev/xvdg）
インスタンスを起動し、両方のEBSボリュームをそれに接続します
（元のルートボリュームの）ファイルシステムを確認します。（例）e2fsck -f/dev/xvda1
元のルートボリュームを最大限に縮小します（例：ext2/3/4）resize2fs -M -p/dev/xvda1
Ddを使用してデータをコピーします。
チャンクサイズを選択します（16 MBが好きです）。
チャンクの数を計算します（resize2fs出力からのブロック数を使用）：blocks * 4 /（chunk_size_in_mb * 1024）-安全のためにビットを切り上げます
データをコピーします：（例）dd if =/dev/xvda1 ibs = 16M of =/dev/xvdg obs = 16M count = 80
新しい（小さい）EBSボリュームでファイルシステムのサイズを変更します：（例）resize2fs -p/dev/xvdg
（元のルートボリュームの）ファイルシステムを確認します。（例）e2fsck -f/dev/xvdg
新しいEBSルートボリュームをデタッチし、元のインスタンスにアタッチします
「ハウツー」ソリューションの詳細な手順を見つけることができません。
EBSルートボリュームがHVM Ubuntuインスタンスに接続されています。
どんな助けでも本当にいただければ幸いです。
AWSコンソールで：
サイズを変更するインスタンスを停止します
アクティブボリュームのスナップショットを作成し、そのスナップショットから「汎用SSD」ボリュームを作成します。
別の「汎用SSD」ボリュームを必要なサイズに作成します。
これらの3つのボリュームを次のようにインスタンスに接続します。
- / dev/sda1（アクティブボリューム用）。
- ターゲットサイズであるボリュームの/ dev/xvdf。
- アクティブボリュームのスナップショットから作成されたボリュームの/ dev/xvdg。
インスタンスを起動します。
SSH経由で新しいインスタンスにログオンします。
これらの新しいディレクトリを作成します。
mkdir /source /target
- 新しいボリュームにext4ファイルシステムを作成します。
mkfs.ext4 /dev/xvdf
- このディレクトリにマウントします。
mount -t ext4 /dev/xvdf /target
- これは非常に重要です。ファイルシステムは、Linuxがそれを認識して起動するためにe2labelを必要とします。アクティブなインスタンスで「e2label/dev/xvda1」を使用して、それが何であるかを確認します。この場合、ラベルは「/」です。
e2label /dev/xvdf /
- スナップショットから作成されたボリュームをマウントします。
mount -t ext4 /dev/xvdg /source
- 内容をコピーします。
rsync -ax /source/ /target
注：「/ target」の後に「/」はありません。また、シンボリックリンクと属性に関するいくつかのエラーがあるかもしれませんが、サイズ変更はまだ成功しました
- ファイルシステムをマウント解除します。
umount /targetumount /source
AWSコンソールに戻ります。インスタンスを停止し、すべてのボリュームを切り離します。
新しいサイズのボリュームを「/ dev/sda1」としてインスタンスに接続します。
インスタンスを起動すると、起動するはずです。
ステップ10 IS重要：上記のように新しいボリュームに「e2label」のラベルを付けます。そうしないと、インスタンスはawsで起動しているように見えますが、接続チェックに合格しません。
ボリュームがルート（ブート可能）デバイスとして使用されている場合、他のソリューションはどれも機能しません。
新しく作成されたディスクにはブートパーティションがないため、インスタンスがルートボリュームとして使用する前に、GRUBがインストールされ、いくつかのフラグが正しく設定されている必要があります。
ルートボリュームを縮小するための（今日のworking）ソリューションは次のとおりです。
背景：ルートボリュームを縮小するインスタンスAがあります。このボリュームをVAと呼びましょう。縮小したいVA 30GBから10GBとしましょう
- インスタンスAと同じOSで新しいec2インスタンスBを作成します。ストレージとして、VAと同じタイプでサイズが10GBのボリュームを選択します。 （またはターゲットサイズが何であれ）。これで、この新しいボリューム（VBと呼ぶ）をルートボリュームとして使用するインスタンスBができました。
- 新しいインスタンス（B）が実行されたら。停止して、ルートボリューム（VB）を切り離します。
注：次の手順は主に@billのソリューションから取られています：
サイズを変更するインスタンスを停止します（A）。
ボリュームのスナップショットを作成VA次に、そのスナップショットから「汎用SSD」ボリュームを作成します。このボリュームをVASNAPと呼びます。
Amazon Linuxで新しいインスタンスをスピンします。このインスタンスをCと呼びます。このインスタンスを使用して、VASNAPのコンテンツをVBにコピーします。インスタンスAを使用してこれらの手順を実行することもできますが、私は独立したマシンで実行することを好みます。
次のボリュームをインスタンスCに接続します。VBの場合は/ dev/xvdf。/dev/xvdg（VASNAPの場合）。
インスタンスCを再起動します。
SSH経由でインスタンスCにログオンします。
次の新しいディレクトリを作成します。
mkdir /source /target
- VBのメインパーティションをext4ファイルシステムでフォーマットします。
mkfs.ext4 /dev/xvdf1
エラーが発生しない場合は、手順11に進みます。それ以外の場合、/dev/xvdf1がない場合は、次のi-viiを実行してパーティションを作成する必要があります。
i）何らかの理由で/dev/xvdf1が存在しない場合は、作成する必要があります。最初に入力してください：
Sudo fdisk /dev/xvdf。
ii）次のように入力してディスクをワイプします：wipefs
iii）次のように入力して、新しいパーティションを作成します：n
iv）pと入力してプライマリパーティションを作成します
v）Enterキーを押し続けると、デフォルト設定が続行されます。
vi）再度コマンドを要求されたら、wを入力して変更を書き込み、終了します。
vii）次のようにして、/dev/xvdf1パーティションがあることを確認します：lsblk
次のように表示されます。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 250G 0 disk
└─xvda1 202:1 0 250G 0 part
xvdf 202:80 0 80G 0 disk
└─xvdf1 202:81 0 80G 0 part
xvdg 202:96 0 250G 0 disk
└─xvdg1 202:97 0 250G 0 part
次にステップ11に進みます。
- このディレクトリにマウントします。
mount -t ext4 /dev/xvdf1 /target
- これは非常に重要です。Linuxがファイルシステムを認識して起動するには、e2labelが必要です。アクティブインスタンスで「e2label/dev/xvda1」を使用して、それが何であるかを確認します。この場合、ラベルは「/」です。
e2label /dev/xvdf1 /
- / sourceにVASNAPをマウントします。
mount -t ext4 /dev/xvdg1 /source
- 内容をコピーします。
rsync -vaxSHAX /source/ /target
注：「/ target」の後に「/」はありません。また、シンボリックリンクと属性に関するいくつかのエラーがあるかもしれませんが、サイズ変更はまだ成功しました
- Umount VB：
umount /target
AWSコンソールに戻ります：デタッチVB、およびデタッチVA Aから.
新しいサイズのボリューム（VB）をインスタンスに「/ dev/xvda」としてアタッチします。
インスタンスAを起動します。ルートデバイスは10 GBです。
インスタンスBとCの両方、およびVBを除くすべてのボリュームを削除します。VBは、インスタンスAのルートボリュームになりました。
次の手順は私のために働きました
手順1.ルートebsボリュームのスナップショットを作成し、スナップショットから新しいボリュームを作成します（これをボリュームコピーと呼びます）
ステップ2.希望のサイズのebsルートボリュームで新しいインスタンスを作成します。 （これをサイズ変更されたボリュームと呼びます）このebsボリュームには、起動用の正しいパーティションがあります。 （ゼロから新しいebsボリュームを作成することは私にとってはうまくいきませんでした）
手順3. volume-resizeおよびvolume-copyをインスタンスに接続します。
ステップ4. volume-resizeをフォーマットします。
Sudo fdisk -l
Sudo mkfs -t ext4 /dev/xvdf1
注：パーティションボリュームが入力されていることを確認してください/dev/xvdf1ない/dev/xvdf
ステップ5. volume-resizeおよびvolume-copy mkdir/mnt/copy mkdir/mnt/resizeをマウントする
Sudo mount /dev/xvdh1 /mnt/copy
Sudo mount /dev/xvdf1 /mnt/resize
ステップ6.ファイルをコピーする
rsync -ax /mnt/copy/ /mnt/resize
手順7. e2labelがルートボリュームと同じであることを確認する
Sudo E2label /dev/xvdh1 > cloudimg-rootfs
Sudo E2label /dev/xvdf1 cloudimg-rootfs
ステップ8. volume-copyのgrub.confを更新して、新しいボリュームudidに一致させる
/boot/grub/grub.cfgでuudidを検索して置き換えます
ubuntu@server:~/mnt$ Sudo blkid
/dev/xvdh1: LABEL="cloudimg-rootfs" UUID="1d61c588-f8fc-47c9-bdf5-07ae1a00e9a3" TYPE="ext4"
/dev/xvdf1: LABEL="cloudimg-rootfs" UUID="78786e15-f45d-46f9-8524-ae04402d1116" TYPE="ext4"
ステップ9.ボリュームをアンマウントする
手順10.サイズが変更された新しいebsボリュームをインスタンス/ dev/sda1に接続する
以下の記事は、EBSボリュームのサイズを小さくする方法についてのわかりやすいチュートリアルです。ステップバイステップのガイドとスクリーンショットをたどることが簡単です。
これが代替のアプローチです。
実行中のEC2インスタンスに古いEBSボリュームを接続してマウントします。ブートボリュームをコピーする場合は、ライブシステムとして使用されているボリュームではなく、古いボリュームをデータとしてマウントして、別のインスタンスでコピーすることをお勧めします。
目的のサイズの新しいEBSボリュームを作成します。
新しいボリュームをインスタンスに接続し、（mkfsなどを使用して）そのインスタンスで新しいファイルシステムを（慎重に）フォーマットします。それをマウントします。
古いファイルシステムの内容を古いボリュームから新しいボリュームにコピーします。
rsync -vaxSHAX /oldvol/ /newvol/
新しいボリュームをマウント解除し、インスタンスからデタッチします。
ルートファイルシステムをコピーしていた場合、次のようになります。
新しいボリュームのEBSスナップショットを作成します。
スナップショットを新しいAMIとして登録します。