AzureのBlob StorageとManaged DiskをLinuxから操作する方法|azコマンドとストレージ設計の基礎

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Azure > AzureのBlob StorageとManaged DiskをLinuxから操作する方法|azコマンドとストレージ設計の基礎
「Azureのストレージって種類が多くて、結局どれを使えばいいの?」
Azureを触り始めたLinuxエンジニアがよく感じる疑問です。VM間でデータを共有したい、バックアップを保存したい、大量のログをまとめておきたい——それぞれの用途によって使うべきストレージが違います。

この記事では、AzureのBlob StorageとManaged Diskの2つに絞って、Linuxから実際に操作する手順を解説します。azコマンド(Azure CLI)を使ったBlobのアップロード・ダウンロードと一覧確認、Managed DiskのアタッチからXFSフォーマット・UUIDを使ったfstab永続マウント設定、さらにVMを止めずにディスクをオンライン拡張する手順まで、実機の出力例つきで紹介します。

この記事のポイント

・Blob StorageはAWS S3相当のオブジェクト保存、Managed DiskはEBS相当のブロックストレージ
・az storage blob upload/download でLinuxから直接Blobを操作できる
・Managed DiskはazコマンドでVMにアタッチしてXFSフォーマット・UUIDでfstab永続マウントする
・az disk update + growpart + xfs_growfsでVMを停止せずオンラインでディスクを拡張できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

AzureストレージはBlob Storage、Managed Disk、Files の3種類が基本

AzureのストレージはAWS S3やEBSに相当するものが、それぞれ別の名前で提供されています。まずこの3種類の使い分けを頭に入れておくと、後の操作が迷いなく進みます。

Blob Storage(オブジェクトストレージ):ファイルや画像、ログ、バックアップなどのファイルをオブジェクトとして保存する。AWSのS3に相当。
Managed Disk(ブロックストレージ):VM専用の仮想ディスク。AWSのEBSに相当。VMにアタッチしてOSまたはデータディスクとして使う。
Azure Files(ファイルストレージ):SMBプロトコルで複数VMから同時にマウントできる共有ストレージ。AWSのEFSに相当。

AWSを使い慣れたエンジニアには、次の対応表が全体把握の早道になります。
AWS Azure 役割
S3(Simple Storage Service) Blob Storage ファイル・画像・ログ・バックアップのオブジェクト保存
EBS(Elastic Block Store) Managed Disk VM専用ブロックストレージ(OSディスク・データディスク)
EFS(Elastic File System) Azure Files 複数VMから同時にマウントできる共有ストレージ
(AWSアカウント単位) ストレージアカウント Blob/Filesを格納する親リソース。Azureのみに存在する概念
AWSとの最大の違いは、Azureでは「ストレージアカウント」という層がBlobの上にもう一段ある点です。ストレージアカウントはリージョン・冗長化設定・パフォーマンスティアを決める親リソースで、S3でいえばバケット設定とアカウント設定が一体化したようなイメージです。

この記事ではLinuxエンジニアが最も頻繁に扱うBlobとManaged Diskを取り上げます。

Azure CLI(az コマンド)の準備とストレージアカウント作成

1. Azure CLIのインストール

RHEL/Rocky Linux系とUbuntu系のそれぞれにインストール手順があります。ここではRPMパッケージとaptパッケージの両方を紹介します。

RHEL 9.x / Rocky Linux 9.x の場合:

# Microsoftのリポジトリを追加してインストール sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc sudo dnf install -y https://packages.microsoft.com/config/rhel/9.0/packages-microsoft-prod.rpm sudo dnf install -y azure-cli # バージョン確認 az --version

Ubuntu 24.04 LTS の場合:

# Microsoftの署名キーとリポジトリを追加 curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash # バージョン確認 az --version

インストール後の実行結果例(Rocky Linux 9.4で確認):

$ az --version azure-cli 2.61.0 core 2.61.0 telemetry 1.1.0 Python location '/opt/microsoft/azure-cli/bin/python3' Extensions directory '/home/azureuser/.azure/cliExtensions' Python (Linux) 3.11.9 (main, Apr 2 2024, 08:25:16) [GCC 11.4.1 20231218 (Red Hat 11.4.1-3)]

2. az login でAzureにサインイン

az login

コマンドを実行するとブラウザが開き、Azureアカウントでサインインを求められます。サーバー環境など、ブラウザが使えない場合は --use-device-code を使うとデバイスコードでのサインインができます。

# ブラウザが使えないサーバーでのログイン az login --use-device-code # → To sign in, use a web browser to open the page https://microsoft.com/devicelogin # and enter the code XXXXXXXX to authenticate.

3. ストレージアカウントの作成

Blob StorageはAzureの「ストレージアカウント」の配下に作成します。まずリソースグループとストレージアカウントを用意します。

# リソースグループの作成(Japan Eastリージョン) az group create \ --name myStorageRG \ --location japaneast # ストレージアカウントの作成 # 名前は英小文字+数字のみ、3~24文字、グローバルで一意である必要がある az storage account create \ --name mystorageaccount20260701 \ --resource-group myStorageRG \ --location japaneast \ --sku Standard_LRS \ --kind StorageV2 \ --access-tier Hot

SKUと冗長化オプションの選択:
SKU名 冗長化 特徴
Standard_LRS ローカル冗長(同一DC内3コピー) 最安。開発・テスト向け
Standard_ZRS ゾーン冗長(同一リージョンの3AZ) AZ障害に耐性あり。本番推奨
Standard_GRS 地理冗長(別リージョンへ非同期コピー) リージョン障害に対応。ミッションクリティカル向け
Standard_GZRS 地理ゾーン冗長(ZRS+GRS) 最高レベルの可用性。コスト高め
AccessTierの選択:
Hot アクセス層:頻繁にアクセスするファイル向け(ストレージ単価高め・転送単価低め)。
Cool アクセス層:アクセス頻度の低いログや長期バックアップ向け(ストレージ単価低め・転送単価高め)。30日以上保存が前提。

Blob StorageをLinuxから操作する(az storage blob)

1. コンテナの作成

Blob Storageのファイルは「コンテナ」という単位でまとめて管理します。S3のバケットに相当するものです。

# アカウントキーを変数に取得(コマンドを短くするため) export AZURE_STORAGE_ACCOUNT=mystorageaccount20260701 export AZURE_STORAGE_KEY=$(az storage account keys list \ --account-name mystorageaccount20260701 \ --resource-group myStorageRG \ --query '[0].value' -o tsv) # コンテナの作成(パブリックアクセスなし) az storage container create \ --name mycontainer \ --public-access off

実行結果:

{ "created": true }

--public-access の設定は3段階あります。

off:プライベート。認証済みリクエストのみ許可(推奨デフォルト)
blob:BlobのURLを知っていれば匿名で読み取り可能
container:コンテナ内の一覧表示も可能(本番環境では使わない)

特別な理由がない限り --public-access off で作成し、外部共有が必要な場合はSASトークン(後述)を使うのが安全です。

2. ファイルのアップロード(upload)

# 単体ファイルのアップロード az storage blob upload \ --container-name mycontainer \ --file /var/log/messages \ --name logs/messages-2026-07-01.log # ディレクトリごと一括アップロード(--pattern でワイルドカード指定可) az storage blob upload-batch \ --source /var/log/ \ --destination mycontainer/logs \ --pattern "*.log"

実行結果(単体アップロード):

{ "etag": "\"0x8DC9A1B2C3D4E5F6\"", "lastModified": "2026-07-01T09:30:00+00:00" }

3. ファイルの一覧確認(list)

# コンテナ内のBlob一覧を表示 az storage blob list \ --container-name mycontainer \ --output table # プレフィックスで絞り込み(logsフォルダ以下のみ) az storage blob list \ --container-name mycontainer \ --prefix "logs/" \ --output table

実行結果:

Name Blob Type Blob Tier Length Content Type Last Modified -------------------------------- ----------- ----------- -------- ------------------------ ------------------------- logs/messages-2026-07-01.log BlockBlob Hot 185432 application/octet-stream 2026-07-01T09:30:00+00:00 logs/secure-2026-07-01.log BlockBlob Hot 12089 application/octet-stream 2026-07-01T09:31:05+00:00

4. ファイルのダウンロード(download)

# 単体ファイルのダウンロード az storage blob download \ --container-name mycontainer \ --name logs/messages-2026-07-01.log \ --file /tmp/messages-restored.log # バッチダウンロード(コンテナのlogsフォルダを丸ごとローカルへ) az storage blob download-batch \ --source mycontainer \ --destination /tmp/blob-restore/ \ --pattern "logs/*"

実行結果:

{ "deleted": false, "metadata": {}, "name": "logs/messages-2026-07-01.log", "properties": { "blobType": "BlockBlob", "contentLength": 185432 } }

5. SAS URLでの一時公開(期限付きURL)

Blobをパブリック公開せず、期限付きで外部から参照できるようにするには、SAS(Shared Access Signature)URLを使います。AWSのPresigned URLに相当する機能で、URLを知っている人だけが指定した期間だけアクセスできます。

# 1時間だけ有効なダウンロードURL(読み取り権限のみ)を生成 # --expiry には UTC時刻を ISO8601 形式で指定する EXPIRY=$(date -u -d '+1 hour' '+%Y-%m-%dT%H:%MZ') az storage blob generate-sas \ --container-name mycontainer \ --name logs/messages-2026-07-01.log \ --permissions r \ --expiry $EXPIRY \ --full-uri \ --output tsv

実行結果(URLは一部伏せています):

https://mystorageaccount20260701.blob.core.windows.net/mycontainer/logs/messages-2026-07-01.log?se=2026-07-01T10%3A30Z&sp=r&sv=2022-11-02&sr=b&sig=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

このURLをcurlやwgetで取得できます。1時間が経過すると自動的にアクセス不能になります。

SASの --permissions には複数の権限を組み合わせて指定できます。

r:読み取り(read)
w:書き込み(write)
d:削除(delete)
l:一覧(list)

6. RBACによるアクセス権の設定

SASが一時的なURL共有であるのに対し、長期的かつ恒久的なアクセス権を管理するにはRBAC(ロールベースのアクセス制御)を使います。AWSのIAMに相当する機能です。

# ユーザーにBlob読み取りロールを割り当て(コンテナ単位) az role assignment create \ --assignee "user@example.com" \ --role "Storage Blob Data Reader" \ --scope "/subscriptions/<サブスクリプションID>/resourceGroups/myStorageRG/providers/Microsoft.Storage/storageAccounts/mystorageaccount20260701/blobServices/default/containers/mycontainer" # 割り当て確認 az role assignment list \ --scope "/subscriptions/<サブスクリプションID>/resourceGroups/myStorageRG" \ --output table

Azureのストレージに関連する主なRBACロールは以下のとおりです。

Storage Blob Data Reader:Blobの読み取りのみ。S3のGetObjectに相当
Storage Blob Data Contributor:読み取り・書き込み・削除。S3フルアクセスに相当
Storage Blob Data Owner:コンテナのACL変更権限を含む最上位ロール

本番環境では、アカウントキー(AZURE_STORAGE_KEY)よりもRBACまたはManaged Identityを使った認証が推奨です。アカウントキーが漏洩するとストレージ全体へのフルアクセスを許してしまいます。

Managed DiskをLinux VMにアタッチしてマウントする

Managed DiskはVMの「追加データディスク」として使うブロックストレージです。「Managed(マネージド)」の名のとおり、ストレージアカウントの管理やレプリケーション設定をAzureが自動で担うため、Unmanaged Diskより運用がシンプルです。Blob Storageと違い、直接ファイルシステムをフォーマットしてマウントポイントを設定します。

作業に入る前に、AzureのLinux VMに最初からアタッチされているディスク構成を押さえておきましょう。この2本を混同すると意図せずデータを失う可能性があります。

/dev/sda — OSディスク(Managed Disk):OSがインストールされているディスク。VMを停止・削除してもデータは消えない有料リソース。
/dev/sdb — 一時ディスク(Temporary Disk):Azure側が無料で提供する揮発性ストレージ。VMの再起動・サイズ変更・再デプロイ時にデータが消えることがある。高速だが永続化には絶対に使わないこと。

今回追加するManaged Diskは /dev/sdc 以降のデバイスとして認識されます。

データディスクのSKU(ストレージ種別)は用途に応じて選択します。
SKU名 特徴 主な用途
Standard_LRS HDDベース・低コスト 開発環境・バックアップ・アーカイブ
StandardSSD_LRS SSDベース・安定したIOPS Webサーバー・軽量データベース
Premium_LRS 高速SSD・低レイテンシ 本番データベース・業務アプリ
UltraSSD_LRS 最高IOPSと帯域幅 SAP HANAなど超高負荷DB

1. Managed Diskの作成とVMへのアタッチ

以降のコマンドで繰り返し使う値を変数に設定しておくと、コマンドが短くなってミスも減ります。

# 変数の設定(環境に合わせて変更してください) RG=myStorageRG VM_NAME=myLinuxVM DISK_NAME=myDataDisk LOCATION=japaneast # 100GBのManaged Disk(Premium SSD)を作成 az disk create \ --resource-group $RG \ --name $DISK_NAME \ --sku Premium_LRS \ --size-gb 100 \ --location $LOCATION \ --query "{Name:name, SizeGB:diskSizeGb, State:diskState}" \ -o table

実行結果:

Name SizeGB State ------------ -------- ----------- myDataDisk 100 Unattached

作成直後のStateは「Unattached」です。VMにアタッチされると「Attached」に変わります。ディスクはVMとは独立したリソースとして存在するため、VMを削除してもデータディスクを残すことができます。この点はAWS EBSと同じ設計思想です。

不要になったディスクは az disk delete --resource-group $RG --name $DISK_NAME --yes で明示的に削除してください。VMを削除してもManaged Diskは自動削除されず、課金が継続します。

# 既存VMにアタッチ(--lun は論理ユニット番号、省略すると最小番号が自動割り当て) az vm disk attach \ --resource-group $RG \ --vm-name $VM_NAME \ --name $DISK_NAME # アタッチ結果の確認 az vm show \ --resource-group $RG \ --name $VM_NAME \ --query "storageProfile.dataDisks[].{LUN:lun, Name:name, SizeGB:diskSizeGb}" \ -o table

実行結果:

LUN Name SizeGB ----- ------------ -------- 0 myDataDisk 100

Azureでは実行中のVMにデータディスクをホットアタッチ(無停止アタッチ)できます。Premium SSDとStandard SSDでサポートされています。LUN(Logical Unit Number)は接続番号で、1台のVMに接続できるデータディスクの最大数はVMサイズに依存しますが、多くのDsシリーズで4本以上アタッチ可能です。

2. Linux側でディスクを認識して確認

アタッチ後、VMにSSHで接続してディスクが認識されているか確認します。

# ブロックデバイスの一覧でアタッチされたディスクを確認 lsblk

実行結果:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 30G 0 disk ├─sda1 8:1 0 1G 0 part /boot ├─sda2 8:2 0 2G 0 part [SWAP] └─sda3 8:3 0 27G 0 part / sdb 8:16 0 100G 0 disk ← 新しく追加されたManaged Disk

/dev/sdb として認識されています(VM環境によっては /dev/sdc 等になる場合があります)。パーティションテーブルがない状態(子エントリなし)なので、これからパーティションを作成します。アタッチ直後に表示されない場合は、数秒待ってから再実行してください。

3. パーティションの作成とフォーマット

partedコマンドでGPTパーティションテーブルとパーティションをワンライナーで作成します。100GB超のディスクでは特にGPT推奨です。

# GPTパーティションテーブルを作成(ディスク全体を1パーティションとして使用) sudo parted /dev/sdb --script \ mklabel gpt \ mkpart primary xfs 0% 100% # パーティションが作成されたことを確認 lsblk /dev/sdb

実行結果:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sdb 8:16 0 100G 0 disk └─sdb1 8:17 0 100G 0 part

フォーマットはXFSを推奨します。AzureのRHEL/AlmaLinux公式イメージのデフォルトがXFSであり、後述のオンライン拡張(xfs_growfs)がマウントしたまま実行できる点が現場で便利です。

# XFSでフォーマット sudo mkfs.xfs /dev/sdb1

フォーマット実行結果(Rocky Linux 9.4で確認):

meta-data=/dev/sdb1 isize=512 agcount=4, agsize=6553472 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 data = bsize=4096 blocks=26213888, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=12799, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0

Ubuntuを使っている場合や ext4 を好む場合は sudo mkfs.ext4 /dev/sdb1 でフォーマットできます。その場合、後述の拡張コマンドは xfs_growfs の代わりに resize2fs /dev/sdb1 を使います。

4. マウントとfstab設定

# マウントポイントの作成 sudo mkdir -p /data # 動作確認のため仮マウント sudo mount /dev/sdb1 /data # マウント確認 df -h /data

実行結果:

Filesystem Size Used Avail Use% Mounted on /dev/sdb1 98G 24K 93G 1% /data

再起動後も自動マウントされるよう、/etc/fstabにUUIDで登録します(デバイス名は再起動で変わる場合があるためUUID推奨)。

fstab の編集ミスは VM を起動不能にする最も危険な操作のひとつです。必ずバックアップを取ってから編集してください。

# fstab を編集前に必ずバックアップする sudo cp /etc/fstab /etc/fstab.bak # アンマウントしてからUUIDを確認 sudo umount /data sudo blkid /dev/sdb1 # 出力例 /dev/sdb1: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" BLOCK_SIZE="4096" TYPE="xfs" PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" # fstabにUUID指定で追記 echo 'UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /data xfs defaults,nofail 0 2' | sudo tee -a /etc/fstab # 構文チェックをしてからマウントを反映(エラーが出なければ成功) sudo mount -a && echo "OK - fstab設定に問題なし"

nofailオプションについて: Azure VMはディスクのデタッチ操作ができるため、nofail を付けておくとディスクがない状態でも起動に失敗しなくなります。本番環境では必須のオプションです。

ディスクサイズをオンラインで拡張する方法

Azureでは実行中のVMを停止することなくディスクサイズを拡張できます(Premium SSD・Standard SSD対応)。ただし、Azure側で拡張しただけではLinux上のファイルシステムには反映されません。az側とLinux側の両方で作業が必要です。

まずAzure側でディスクサイズを変更します。

# ディスクを100GB→200GBに拡張(アタッチされたままでも実行可能) az disk update \ --resource-group $RG \ --name $DISK_NAME \ --size-gb 200 # Azure側の拡張確認 az disk show \ --resource-group $RG \ --name $DISK_NAME \ --query "{Name:name, SizeGB:diskSizeGb}" \ -o table

実行結果:

Name SizeGB ------------ -------- myDataDisk 200

次にLinux側でパーティションとファイルシステムを拡張します。まずSCSI再スキャンでカーネルに変更を通知してから、growpart を実行します。

# カーネルにディスクサイズの変更を通知(SCSI再スキャン) echo "1" | sudo tee /sys/class/block/sdb/device/rescan # 拡張後のサイズが反映されているか確認(sdbは200GBになっているがsdb1はまだ100GB) lsblk /dev/sdb # growpartでパーティションを拡張(sdb の 1番パーティションを指定) sudo growpart /dev/sdb 1 # XFSファイルシステムをオンラインで拡張(マウントしたまま実行できる) sudo xfs_growfs /data # 拡張後のサイズを確認 df -h /data

実行結果:

Filesystem Size Used Avail Use% Mounted on /dev/sdb1 200G 533M 200G 1% /data

xfs_growfs はマウントしたまま実行できるため、データベースやWebサーバーを稼働したままディスクを拡張できます。ext4 の場合は sudo resize2fs /dev/sdb1 を使います(こちらもオンライン拡張対応)。

ディスクをデタッチして別VMへ移す方法

Managed DiskはVMとは独立したリソースです。デタッチしたディスクはAzure上に残り、別のVMにアタッチして再利用できます。データ移行やVM移行時に活用できます。

# まずLinux側でアンマウントする(このステップを省略するとデタッチが失敗する場合がある) sudo umount /data # Azure側でデタッチする az vm disk detach \ --resource-group $RG \ --vm-name $VM_NAME \ --name $DISK_NAME # 別VMにアタッチする az vm disk attach \ --resource-group $RG \ --vm-name newserver \ --name $DISK_NAME

別VMにアタッチ後、Linux側で lsblk を確認してマウントポイントを作成すれば、以前のデータがそのまま利用できます。fstabへのUUID登録は新しいVM側でも必要です。

Blob StorageとManaged Diskのコスト比較と使い分け判断

用途 推奨ストレージ 理由
VMのOSディスク・データディスク Managed Disk(Premium SSD) ブロックストレージが必要。fsシステム直接マウント
ログ・バックアップの長期保存 Blob Storage(Cool層) ストレージ単価が安く、月額コストを最小化できる
Web資産(画像・CSS・JS)の配信 Blob Storage(Hot層)+ CDN 静的コンテンツ配信はBlob+Azure Front Doorが定番
複数VMで同じファイルを共有 Azure Files SMBマウントで複数VMから同時アクセス可能
スクリプト・CLIでのファイル転送 Blob Storage(az storage blob) azコマンドで操作しやすい。SAS URLで一時共有も可能

トラブルシュート:よくあるエラーと対処

「AuthorizationPermissionMismatch」が出る

ストレージアカウントキーまたはSASトークンが正しく設定されていない場合に発生します。

# エラー例 The request is not authorized to perform this operation using this permission. ErrorCode: AuthorizationPermissionMismatch # 対処: 環境変数が正しくセットされているか確認 echo $AZURE_STORAGE_ACCOUNT echo $AZURE_STORAGE_KEY # または --account-name / --account-key を明示的に指定 az storage blob list \ --container-name mycontainer \ --account-name mystorageaccount20260701 \ --account-key "XXXXXXXX..."

Azure AD(az login)でサインインしているが、RBACロールが未割り当ての場合にも同じエラーが出ることがあります。その場合は現在のユーザーにロールが付いているかを確認します。

# 現在のサインインユーザーのオブジェクトIDを確認 az ad signed-in-user show --query id -o tsv # ロール割り当て一覧を確認 az role assignment list \ --scope "/subscriptions/<サブスクリプションID>/resourceGroups/myStorageRG/providers/Microsoft.Storage/storageAccounts/mystorageaccount20260701" \ --output table

ロールが付いていない場合は az role assignment createStorage Blob Data Contributor などを割り当ててください。

「認証モードが合わない」エラー(--auth-mode)

--auth-mode login(Azure AD認証)で操作しようとしているが、環境変数にアカウントキーがセットされていると認証が競合することがあります。認証方法を明示的に指定して切り分けます。

# Azure AD認証を明示(RBACロールが必要) az storage blob list \ --container-name mycontainer \ --account-name mystorageaccount20260701 \ --auth-mode login # アカウントキー認証を明示(開発・検証環境向け) ACCOUNT_KEY=$(az storage account keys list \ --account-name mystorageaccount20260701 \ --resource-group myStorageRG \ --query '[0].value' -o tsv) az storage blob list \ --container-name mycontainer \ --account-name mystorageaccount20260701 \ --account-key "$ACCOUNT_KEY" \ --output table

本番環境ではアカウントキーの代わりにManaged IdentityやRBACを使うのが推奨です。

Managed Diskアタッチ後にlsblkで見えない

VMへのアタッチが完了しているように見えてもカーネルがデバイスをスキャンできていない場合があります。

# SCSIバスを強制リスキャン(全ホストを対象) for host in /sys/class/scsi_host/host*; do echo "- - -" | sudo tee $host/scan done # デバイスが認識されたか再確認 lsblk

それでも認識されない場合は、azコマンドでアタッチ状態を確認します。

az vm show \ --resource-group $RG \ --name $VM_NAME \ --query "storageProfile.dataDisks[].{LUN:lun, Name:name, SizeGB:diskSizeGb}" \ -o table

また、複数のデータディスクをアタッチしている場合は /dev/sdc/dev/sdd など別のデバイス名になっている可能性があります。lsblk -o NAME,SIZE,TYPE,SERIAL でシリアル番号まで表示すると特定しやすくなります。

fstab設定後にVMが起動しない

fstabにUUIDを間違えて記入した場合にVMが起動しなくなることがあります。未然に防ぐには、fstab書き込み前に構文チェックを行うことが重要です。

# fstabの構文チェックだけ行う(実際のマウントはしない) sudo mount --fake -a -v # エラーがなければ続行、エラーが出たら fstab を修正してから再試行 sudo mount -a

--fake オプションを付けると実際のマウントをせずに構文チェックだけ実行します。エラー箇所とともにメッセージが出るので、fstab の該当行を修正してください。

万が一VMが起動しなくなった場合はAzureポータルの「シリアルコンソール」から復旧できます。操作手順:Azureポータル >> VM >> 診断 >> シリアルコンソール。ログイン後にバックアップから復元します。

# バックアップからfstabを復元する sudo cp /etc/fstab.bak /etc/fstab # 再起動する sudo reboot

このためにも、fstab を編集する前のバックアップ(sudo cp /etc/fstab /etc/fstab.bak)が必須です。また、本番環境では nofail オプションを必ず付けてください。ディスクが一時的にデタッチされた状態でもVMの起動が継続できます。

ディスク拡張後にdfの値が変わらない

Azure側で az disk update を実行しても、Linux側の growpartxfs_growfs(または resize2fs)を忘れるとファイルシステムのサイズは変わりません。

# Azure側のディスクサイズを確認(200GBになっているはず) az disk show --resource-group $RG --name $DISK_NAME --query diskSizeGb # Linux側のパーティションサイズを確認(まだ100GBのまま) lsblk /dev/sdb # growpartでパーティション拡張 → xfs_growfsでFS拡張の順に実行する sudo growpart /dev/sdb 1 sudo xfs_growfs /data

本記事のまとめ

やりたいこと コマンド・方法
ストレージアカウントを作成 az storage account create --name ... --sku Standard_LRS
Blobコンテナを作成 az storage container create --name mycontainer
Blobにファイルをアップロード az storage blob upload --container-name ... --file ...
Blob一覧を確認 az storage blob list --container-name ... --output table
Blobをダウンロード az storage blob download --container-name ... --name ...
期限付きSAS URLを生成 az storage blob generate-sas --permissions r --expiry $EXPIRY --full-uri
RBACでアクセス権を付与 az role assignment create --role "Storage Blob Data Contributor"
Managed Diskを作成する az disk create --size-gb 100 --sku Premium_LRS
VMにディスクをアタッチする az vm disk attach --vm-name VM名 --name ディスク名
パーティションを作成する sudo parted /dev/sdb --script mklabel gpt mkpart primary xfs 0% 100%
XFSでフォーマットしてマウント sudo mkfs.xfs /dev/sdb1sudo mount /dev/sdb1 /data
fstabに自動マウント設定 UUID取得後に /etc/fstab へ nofail オプション付きで追記
Azure側でディスクサイズを拡張 az disk update --size-gb 新サイズ
Linux側でパーティション・FSを拡張 sudo growpart /dev/sdb 1sudo xfs_growfs /data
ディスクをデタッチして別VMへ移す az vm disk detachaz vm disk attach --vm-name newserver

Blob StorageとManaged Diskは役割がまったく異なります。VMのデータディスクとして高速アクセスが必要ならManaged Disk、ログや画像などのオブジェクト保存ならBlob Storageという切り分けを軸に選んでください。

AzureのストレージはLinuxエンジニアが避けて通れない実務スキルです。Blob Storageのオブジェクト操作からManaged DiskのマウントとオンラインサイズまでをCLIで体系的に身につけておくことで、現場でのトラブル対応速度が大きく変わります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AzureでのBlob Storage・Managed Disk操作を含むクラウド実務スキルを、現役エンジニアが実機ハンズオンで教えます。Azure実践ハンズオン講座の詳細はこちら >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。