Zenn
📑

AWS EC2 Linux Instanceへのストレージ追加手順

2025/03/07に公開
AWS
storage
instance
tech

はじめに

こんにちわ。
最近物忘れが激しく、特に普段使わないコマンドラインが、、、ほぼ思い出せないw
と言うことでメモがてらブログに書き残しておきます。


AI生成によるイメージ画像(写っているコードに意味はございません)

こんな時のためのメモブログです

AWS EC2でLinuxインスタンスを運用していると、ストレージ容量が足りなくなる場面に遭遇します。（私が 非常にケチ もとい、倹約家なので 余分な割り当てをしないためですね）
そんなとき、AWSコンソールからEBSボリュームを追加して容量を拡張するのは一般的な解決策です。

しかし、コンソールでボリュームをアタッチしたにも関わらず、インスタンスにログインして df -h コマンドを実行しても、なぜか新しいボリュームが表示されない　という事態に陥ることがあります。

「ボリュームはアタッチしたはずなのに、どこにも見当たらない... あのコマンド、なんだっけ？」

今回は、そんな状況に遭遇した時の解決方法を共有します。

前提条件

  • AWS EC2インスタンス（Ubuntu Server）が稼働中
  • AWSコンソールからEBSボリュームを作成し、インスタンスにアタッチ済み
  • SSHでインスタンスに接続できる環境

1. 問題の状況：追加したはずのボリュームが見えない

EC2インスタンスに新しいEBSボリュームをアタッチしました。しかし、インスタンスにSSHでログイン後、df -h コマンドを実行しても、追加したはずのボリュームが表示されません。

ubuntu@ip-172-31-19-9:~$ df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root        532G  314G  219G  59% /
tmpfs             16G     0   16G   0% /dev/shm
tmpfs            6.2G  976K  6.2G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme0n1p16  891M  105M  724M  13% /boot
/dev/nvme0n1p15   98M  6.4M   92M   7% /boot/efi
tmpfs            3.1G   12K  3.1G   1% /run/user/1000

「あれ？追加したはずの1TBのボリュームがどこにも見当たらない...」

2. 原因を理解する：EBSボリュームの仕組み

この問題の原因を理解するには、AWSのEBSボリュームの仕組みを知る必要があります。

重要ポイント: EBSボリュームをEC2インスタンスにアタッチしただけでは、OSからそのボリュームを使用することはできません。以下の手順が必要です：

  1. ボリュームをインスタンスにアタッチする（AWSコンソールで実施済み）
  2. ボリュームをフォーマット（ファイルシステムの作成）
  3. マウントポイントを作成
  4. ボリュームをマウント
  5. （オプション）再起動時の自動マウント設定

これらのステップを順番に実行していきましょう。

3. 解決までの道のり：ステップバイステップガイド

3.1. ボリュームのアタッチ状況を確認

まずは、AWSコンソールでボリュームがインスタンスに正しくアタッチされているかを確認します。EC2ダッシュボード → ボリューム → 該当ボリュームを選択し、状態が "in-use" で、正しいインスタンスIDにアタッチされていることを確認しましょう。

3.2. デバイス名の確認：lsblk コマンド

次に、インスタンスにログインして lsblk コマンドを実行し、新しいボリュームがどのデバイス名で認識されているかを確認します。

ubuntu@ip-172-31-19-9:~$ lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0          7:0    0 21.9M  1 loop /snap/amazon-ssm-agent/7994
loop1          7:1    0 22.9M  1 loop /snap/amazon-ssm-agent/9882
loop2          7:2    0 48.8M  1 loop /snap/core18/2857
loop3          7:3    0 48.8M  1 loop /snap/core18/2848
loop4          7:4    0 68.8M  1 loop /snap/core22/1720
loop5          7:5    0 68.8M  1 loop /snap/core22/1752
loop6          7:6    0 38.6M  1 loop /snap/snapd/23259
loop7          7:7    0 38.7M  1 loop /snap/snapd/23546
nvme0n1      259:0    0  550G  0 disk 
├─nvme0n1p1  259:1    0  549G  0 part /
├─nvme0n1p15 259:3    0   99M  0 part /boot/efi
└─nvme0n1p16 259:4    0  923M  0 part /boot
nvme1n1      259:2    0 1000G  0 disk

この出力から、nvme1n1 という 1TB のディスクが追加したボリュームであることがわかりました。これは正しくインスタンスに認識されていますが、まだマウントされていないため df -h には表示されていません。

💡 ポイント: EC2インスタンスタイプによって、デバイス名の形式が異なります。最近のインスタンスでは nvme 形式が一般的ですが、旧世代のインスタンスでは /dev/xvdf や /dev/sdf のような形式になることもあります。

3.3. ファイルシステムの作成：mkfs コマンド

新しいボリュームにファイルシステムを作成します。今回は ext4 でフォーマットします。

sudo mkfs -t ext4 /dev/nvme1n1

実行すると、以下のような出力が表示されます：

mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 262144000 4k blocks and 65536000 inodes
Filesystem UUID: f81b6a0d-3f37-4c8a-9a5b-cb1a209d9d5b
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

⚠️ 注意: このコマンドを実行すると、ボリューム上の既存データはすべて消去されます。既存データがある場合は、先にバックアップを取ってください。

3.4. マウントポイントの作成：mkdir コマンド

ボリュームをマウントするためのディレクトリ（マウントポイント）を作成します。

sudo mkdir /mnt/newvolume

💡 ポイント: マウントポイントの名前は任意です。用途に応じて /projectname、/backup-yymmdd など、わかりやすい名前を付けることをお勧めします。

3.5. ボリュームのマウント：mount コマンド

作成したマウントポイントにボリュームをマウントします。

sudo mount /dev/nvme1n1 /mnt/newvolume

このコマンドは成功すると何も出力しません。

3.6. マウントの確認：df -h コマンド

再度 df -h コマンドを実行して、新しいボリュームが正しくマウントされていることを確認します。

ubuntu@ip-172-31-19-9:~$ df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root        532G  314G  219G  59% /
tmpfs             16G     0   16G   0% /dev/shm
tmpfs            6.2G  976K  6.2G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme0n1p16  891M  105M  724M  13% /boot
/dev/nvme0n1p15   98M  6.4M   92M   7% /boot/efi
tmpfs            3.1G   12K  3.1G   1% /run/user/1000
/dev/nvme1n1     984G   28K  934G   1% /mnt/newvolume

おめでとんございます /dev/nvme1n1 が /mnt/newvolume にマウントされ、df -h に表示されるようになりました！

3.7. 永続的なマウント設定：/etc/fstab の編集

このままでは、インスタンスを再起動するとマウントが解除されてしまいます。再起動後も自動的にマウントされるように、/etc/fstab ファイルを編集します。

まず、ボリュームのUUIDを確認します：

sudo blkid /dev/nvme1n1

出力例：

/dev/nvme1n1: UUID="f81b6a0d-3f37-4c8a-9a5b-cb1a209d9d5b" BLOCK_SIZE="4096" TYPE="ext4"

次に、/etc/fstab ファイルを編集します：

sudo nano /etc/fstab

ファイルの末尾に以下の行を追加します：

UUID=f81b6a0d-3f37-4c8a-9a5b-cb1a209d9d5b  /mnt/newvolume  ext4  defaults,nofail  0  2

または、UUIDではなくデバイス名を使用する場合：

/dev/nvme1n1  /mnt/newvolume  ext4  defaults,nofail  0  2

💡 ポイント: 個人的には、UUIDの使用を推奨します。

各フィールドの意味：

  • 1列目: デバイス名またはUUID
  • 2列目: マウントポイント
  • 3列目: ファイルシステムタイプ
  • 4列目: マウントオプション
    • defaults: 読み書き、suid、dev、exec、auto、nouser、async
    • nofail: デバイスが存在しない場合もブートを続行
  • 5列目: dumpユーティリティがバックアップを取るかどうか（0=取らない）
  • 6列目: fsckがチェックする順序（0=チェックしない、1=ルートファイルシステム、2=その他）

変更を保存してエディタを終了します（nanoの場合は Ctrl+X、Y、Enter）。

3.8. マウント設定のテスト

設定が正しいか確認するために、以下のコマンドを実行します：

sudo mount -a

エラーが表示されなければ、設定は正常です。念のため、インスタンスを再起動して、ボリュームが自動的にマウントされることを確認することをお勧めします。

4. 新しいボリュームの使用方法

4.1. ボリュームへのアクセス

新しいボリュームは /mnt/newvolume にマウントされているので、このディレクトリに移動して使用します。

cd /mnt/newvolume

4.2. 権限の設定

デフォルトでは、マウントしたボリュームのルートディレクトリは root ユーザーが所有しています。一般ユーザーが書き込めるようにするには、権限を変更します：

# 特定のユーザー（例：ubuntu）に所有権を変更
sudo chown ubuntu:ubuntu /mnt/newvolume

# または、誰でも書き込めるように権限を変更
sudo chmod 777 /mnt/newvolume

⚠️ 注意: chmod 777 は全ユーザーに全権限を与えるため、セキュリティ上のリスクがあります。本番環境では、より制限的な権限設定を検討してください。

4.3. 使用例

新しいボリュームにファイルを作成してみましょう：

echo "Hello, new volume!" > /mnt/newvolume/test.txt
cat /mnt/newvolume/test.txt

出力：

Hello, new volume!

5. トラブルシューティング

5.1. ボリュームが認識されない場合

lsblk コマンドで新しいボリュームが表示されない場合：

  1. AWSコンソールでボリュームが正しくアタッチされているか確認
  2. インスタンスを再起動してみる
  3. 別のデバイス名（/dev/sdf など）でアタッチし直してみる

5.2. マウントエラーが発生する場合

mount: /mnt/newvolume: wrong fs type, bad option, bad superblock...

このようなエラーが表示される場合：

  1. ファイルシステムが作成されているか確認

    sudo file -s /dev/nvme1n1

    出力が data のみの場合、ファイルシステムが作成されていません。

  2. ファイルシステムを作成

    sudo mkfs -t ext4 /dev/nvme1n1

5.3. 再起動後にマウントされない場合

  1. /etc/fstab の設定を確認
  2. UUIDが正しいか確認
    sudo blkid /dev/nvme1n1
  3. 手動でマウントしてエラーメッセージを確認
    sudo mount /dev/nvme1n1 /mnt/newvolume

6. 応用：複数のボリュームを管理する

大規模なシステムでは、複数のEBSボリュームを管理することがあります。以下に、複数ボリュームを効率的に管理するためのヒントを紹介します。

6.1. 論理ボリュームマネージャ（LVM）の使用

複数のボリュームを1つの論理ボリュームとして管理したい場合は、LVMを使用します：

# LVMパッケージのインストール
sudo apt-get update
sudo apt-get install -y lvm2

# 物理ボリュームの作成
sudo pvcreate /dev/nvme1n1 /dev/nvme2n1

# ボリュームグループの作成
sudo vgcreate vg_data /dev/nvme1n1 /dev/nvme2n1

# 論理ボリュームの作成
sudo lvcreate -l 100%FREE -n lv_data vg_data

# ファイルシステムの作成
sudo mkfs.ext4 /dev/vg_data/lv_data

# マウント
sudo mkdir /mnt/data
sudo mount /dev/vg_data/lv_data /mnt/data

6.2. ボリュームのラベル付け

複数のボリュームを識別しやすくするために、ラベルを付けることができます：

# ラベルの設定
sudo e2label /dev/nvme1n1 data_volume

# ラベルでマウント
sudo mount LABEL=data_volume /mnt/data

まとめ

EC2インスタンスにEBSボリュームを追加した際に、df -h に表示されない問題を解決するための手順とコマンドを紹介しました。

主なステップ:

  1. lsblk コマンドでデバイス名を確認
  2. mkfs コマンドでファイルシステムを作成
  3. マウントポイントを作成
  4. mount コマンドでマウント
  5. /etc/fstab を編集して永続マウント設定

これらの手順を踏むことで、無事に新しいボリュームを利用できるようになります。

AWSクラウド環境でのストレージ管理は、クラウドインフラを運用する上で重要なスキルの一つです。この記事が皆さんの日々の運用の一助となれば幸いです。
（特に、私のように たまにしか作業されない方）

今回の参考情報

Discussion