• HOME
  • WordPressのバックアップをAzure Blob Storageに保存する手順（Azure CLI・cron）

2026年8月19日

  • シェア
  • ツイート

    • 2026年8月19日

    WordPressのバックアップをAzure Blob Storageに保存する手順（Azure CLI・cron）

    Azure Blob Storage は Microsoft Azure のオブジェクトストレージです。WordPress サーバーとは別の場所にバックアップを置けるので、サーバーの故障や事業者側の障害が起きても、データを取り戻せます。

    この記事では、Linux サーバー上の WordPress から Azure CLI（az コマンド）を使い、データベースとファイルを Blob Storage へ毎日アップロードする手順を説明します。プラグインを使わずにサーバー側で完結させる方法です。

    前提

    • Azure のサブスクリプションがあり、リソースを作成できる権限があること
    • WordPress サーバーに SSH で入れ、WP-CLI（wp コマンド）が使えること
    • コマンドは Debian / Ubuntu を想定しています（Azure CLI の他のディストリビューション向けの入れ方は、Microsoft の公式ドキュメントを参照してください）

    この記事で使う名前は次のとおりです。自分の環境に合わせて置き換えてください。ストレージアカウント名は Azure 全体で一意である必要があり、英小文字と数字の3〜24文字で付けます。

    種類 この記事での名前
    リソースグループ rg-wp-backup
    ストレージアカウント wpbackup12345
    コンテナー wp-backups
    リージョン japaneast（東日本）

    手順1: Azure CLIを入れてログインする

    作業用の PC か WordPress サーバーに Azure CLI を入れます。Debian / Ubuntu では、Microsoft が用意しているスクリプトで入れられます。

    curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
az version

# 管理者としてログインする（ブラウザーかデバイスコードで認証）
az login

    手順2: ストレージアカウントとコンテナーを作る

    az group create --name rg-wp-backup --location japaneast

az storage account create \
  --name wpbackup12345 \
  --resource-group rg-wp-backup \
  --location japaneast \
  --sku Standard_GRS \
  --kind StorageV2 \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false

az storage container-rm create \
  --storage-account wpbackup12345 \
  --resource-group rg-wp-backup \
  --name wp-backups
    • --sku Standard_GRS は、データを別のリージョン（東日本なら西日本）にも複製する設定です。同じリージョン内の複製だけでよければ Standard_LRS にします。
    • --allow-blob-public-access false で、Blob を匿名で公開できないようにします。バックアップにはデータベースの中身が入っているため、外から読めないようにしておきます。

    誤って削除したバックアップを一定期間戻せるように、Blob の論理的な削除（soft delete）も有効にしておきます。

    az storage account blob-service-properties update \
  --account-name wpbackup12345 \
  --resource-group rg-wp-backup \
  --enable-delete-retention true \
  --delete-retention-days 14

    手順3: WordPressサーバーに書き込み権限を与える

    バックアップを自動で送るには、WordPress サーバーが人の操作なしで Azure にログインできる必要があります。アカウントキーを使う方法もありますが、キーはストレージアカウント全体を操作できるため、ここでは書き込み先のコンテナーに限った権限（Azure の RBAC ロール「Storage Blob Data Contributor」）を与えます。

    まず、権限の範囲（スコープ）としてコンテナーの ID を組み立てます。

    ACCOUNT_ID=$(az storage account show --name wpbackup12345 --resource-group rg-wp-backup --query id -o tsv)
SCOPE="$ACCOUNT_ID/blobServices/default/containers/wp-backups"
echo "$SCOPE"

    WordPress サーバーの種類によって、次のどちらかを選びます。

    WordPressサーバーがAzureの仮想マシンの場合: マネージドID

    仮想マシンにシステム割り当てのマネージド ID を付け、そこにロールを割り当てます。パスワードやキーをサーバーに置かずに済みます。

    az vm identity assign --name wp-vm --resource-group rg-wp \
  --role "Storage Blob Data Contributor" --scope "$SCOPE"

    wp-vm と rg-wp は、WordPress が動いている仮想マシンとそのリソースグループの名前です。仮想マシンの中では、次のコマンドでログインします。

    az login --identity

    それ以外のサーバーの場合: サービスプリンシパル

    国内のレンタルサーバーや VPS など Azure 以外のサーバーからは、サービスプリンシパル（アプリ用の ID）を作って使います。

    az ad sp create-for-rbac --name wp-backup-sp --role "Storage Blob Data Contributor" --scopes "$SCOPE"

    出力される appId・password・tenant は、パスワードと同じように扱います。WordPress サーバーで、バックアップを実行するユーザーとして一度だけログインします。

    read -rs SP_SECRET
az login --service-principal --username APP_ID --password "$SP_SECRET" --tenant TENANT_ID
unset SP_SECRET

    APP_ID と TENANT_ID は出力された値に置き換えます。ログインした情報は実行ユーザーのホームディレクトリの ~/.azure に保存され、cron から実行したときにも使われます。このディレクトリを他のユーザーが読めないようにし、シークレットの有効期限が切れる前に作り直してください。

    ロールの割り当てが反映されるまで、数分かかることがあります。

    手順4: バックアップを送るスクリプトを作る

    スクリプトは、WordPress のファイルの所有者（例: wpuser）で実行します。手順3のログインも同じユーザーで行っておきます。

    /home/wpuser/bin/wp-azure-backup.sh:

    #!/bin/bash
set -euo pipefail

WP_PATH=/var/www/html
ACCOUNT=wpbackup12345
CONTAINER=wp-backups
STAMP=$(date +%Y%m%d-%H%M)
WORK=$(mktemp -d)
trap 'rm -rf "$WORK"' EXIT

# データベースとファイルを一時ディレクトリに書き出す
wp db export "$WORK/db-$STAMP.sql" --path="$WP_PATH" --quiet
gzip "$WORK/db-$STAMP.sql"
tar -czf "$WORK/files-$STAMP.tar.gz" -C "$WP_PATH" .

# サーバー名のフォルダーに分けてアップロードする
for f in "$WORK"/*; do
  az storage blob upload \
    --account-name "$ACCOUNT" \
    --container-name "$CONTAINER" \
    --name "$(hostname)/$(basename "$f")" \
    --file "$f" \
    --auth-mode login \
    --no-progress \
    --only-show-errors
done

echo "$(date '+%F %T') uploaded $STAMP"
    chmod 700 /home/wpuser/bin/wp-azure-backup.sh
/home/wpuser/bin/wp-azure-backup.sh

# アップロードされたか確かめる
az storage blob list --account-name wpbackup12345 --container-name wp-backups \
  --prefix "$(hostname)/" --auth-mode login --query "[].name" -o tsv
    • --auth-mode login は、手順3のログイン（マネージド ID かサービスプリンシパル）の権限でアップロードする指定です。付けないとアカウントキーを取得しようとして、権限不足で失敗します。
    • az storage blob upload は、同じ名前の Blob があると既定では上書きせずにエラーになります。ファイル名に日時を入れているので、毎回別の名前になります。
    • 一時ディレクトリはスクリプトの終了時に trap で削除されます。

    手順5: cronで毎日実行する

    wpuser の crontab に登録します。

    crontab -e
    0 2 * * * /home/wpuser/bin/wp-azure-backup.sh >> /home/wpuser/wp-azure-backup.log 2>&1

    cron の行の中に $(date +%Y%m%d) のような % を直接書くと、改行として扱われて正しく動きません。日付の処理はスクリプトの中に置いています。

    手順6: 古いバックアップを自動で消す

    Blob Storage のライフサイクル管理を使うと、一定の日数が過ぎた Blob を自動で削除できます。次の内容を policy.json として保存します。prefixMatch はコンテナー名から書きます。

    {
  "rules": [
    {
      "enabled": true,
      "name": "delete-old-wp-backups",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 30 }
          }
        },
        "filters": {
          "blobTypes": ["blockBlob"],
          "prefixMatch": ["wp-backups/"]
        }
      }
    }
  ]
}
    az storage account management-policy create \
  --account-name wpbackup12345 \
  --resource-group rg-wp-backup \
  --policy @policy.json

    保存料金を下げるために、古い Blob を Cool・Cold・Archive などのアクセス層へ移すこともできます。ただし、これらの層には最低保存期間があり、期間内に削除すると早期削除の料金がかかります。Archive 層の Blob はすぐには読み出せず、読み出し可能な層へ戻す（リハイドレートする）のに時間がかかります。料金と条件は Azure の料金ページで確認してください。

    手順7: 復元する

    テスト用のディレクトリにダウンロードして、テスト環境に戻す例です。

    mkdir -p /tmp/wp-restore && cd /tmp/wp-restore

az storage blob download --account-name wpbackup12345 --container-name wp-backups \
  --name "$(hostname)/db-20261110-0200.sql.gz" --file db.sql.gz --auth-mode login
az storage blob download --account-name wpbackup12345 --container-name wp-backups \
  --name "$(hostname)/files-20261110-0200.tar.gz" --file files.tar.gz --auth-mode login

gunzip db.sql.gz
wp db import db.sql --path=/var/www/test

    ファイル名の日時は、az storage blob list で確かめたものに置き換えます。files.tar.gz はテスト用のディレクトリに展開し、サイトが表示されてログインできることを確かめてから、本番の復元に使います。

    運用の注意

    • キーやシークレットをスクリプトに書かない: マネージド ID かサービスプリンシパルのログインを使い、スクリプトには認証情報を書きません。
    • 権限はコンテナーに絞る: ロールのスコープをストレージアカウント全体やサブスクリプションにすると、ほかのデータまで書き換えられるようになります。
    • ログを確認する: ログイン情報の期限切れや権限の変更でアップロードが失敗すると、ログにエラーが残ります。定期的に確認するか、失敗時に通知する仕組みを加えます。
    • 復元を練習する: バックアップが取れていても、戻せなければ意味がありません。定期的にテスト環境へ戻してみます。

    まとめ

    • ストレージアカウントは匿名公開を無効にして作り、soft delete を有効にする
    • サーバーには「Storage Blob Data Contributor」をコンテナー単位で与え、Azure の仮想マシンならマネージド ID、それ以外ならサービスプリンシパルでログインする
    • スクリプトは wp db export と tar で書き出し、az storage blob upload --auth-mode login で送る
    • cron の % 問題を避けるため、日付の処理はスクリプトに置く
    • 世代の削除はライフサイクル管理に任せ、復元はテスト環境で確かめる

    関連記事:

    Views: 51

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲