Azure Storageの項目レベル復元でコンテナー名変更が可能に｜-RenameToの影響と確認ポイント

Azure Storage の Blob / ADLS バックアップを PowerShell で復元している場合、今回まず確認すべき変更は Initialize-AzDataProtectionRestoreRequest に追加された -RenameTo です。2026年5月18日に Azure PowerShell の PR が main ブランチへマージされ、Blob と Azure Data Lake Storage の項目レベル復元で、復元先のコンテナー名を別名にできるようにする変更が入りました。これにより、検証用ストレージアカウントや DR 演習で「同じコンテナー名が既に存在して復元できない」という場面を避けやすくなります。(GitHub)

ただし、この更新は「Azure Storage にコンテナー名変更 API が追加された」という意味ではありません。あくまで Azure Backup / Az.DataProtection の復元要求を作るときに、復元先でのコンテナー名を指定できるようにする変更です。また、同じ PR には AzureBlob の OperationalStore 保持ルール名に関する破壊的変更も含まれるため、復元スクリプトだけでなくバックアップポリシー編集スクリプトも確認が必要です。(GitHub)

今回の Azure Storage 更新で変わること

今回の更新は、Azure Storage 本体の一般的なデータ操作ではなく、Azure PowerShell の Az.DataProtection モジュールに関係する変更です。対象は、Azure Backup で保護された Blob / ADLS の復元処理を PowerShell で自動化している管理者・開発者です。

確認項目	変更内容	実務上の影響
復元要求	Initialize-AzDataProtectionRestoreRequest に -RenameTo が追加	代替場所への項目レベル復元で、元のコンテナー名とは別の名前に復元しやすくなる
対象データソース	AzureBlob と AzureDataLakeStorage のマニフェストでコンテナー名変更が有効化	Blob バックアップ、ADLS vaulted backup の復元設計に影響
入力形式	-RenameTo はハッシュテーブルで、キーに元コンテナー名、値に新コンテナー名を指定	コンテナーごとの名前対応表を事前に作る必要がある
保持ルール	AzureBlob の OperationalStore は Default_OperationalStore を使う方向へ変更	-Name Default 前提のポリシー編集スクリプトが失敗する可能性
リリース状況	PR は main にマージ済みだが、利用環境のモジュールに含まれるかは別途確認が必要	Azure Automation、CI/CD、踏み台端末のモジュールバージョン確認が必要

2026年5月23日時点で PowerShell Gallery の Az 最新表示は 15.6.1 で、リリースノート上の Az.DataProtection は 2.10.1 の修正内容までが確認できます。今回の PR は 2026年5月18日に main へマージされた変更なので、実際に -RenameTo を使う前に、手元の Az.DataProtection に反映済みかを必ず確認してください。([PowerShell Gallery][2])

-RenameTo は何を解決するのか

従来、Blob や ADLS のバックアップから特定コンテナーだけを代替ストレージアカウントへ復元する場合、復元先に同名コンテナーがあると設計上の衝突が起きやすくなります。特に次のような運用では、同じコンテナー名をそのまま使えないことがあります。

• DR 訓練で、本番に近いストレージアカウントへ復元テストを行う
• 監査や障害調査のため、過去時点のコンテナーを隔離環境に復元する
• 開発・検証環境で、本番データの一部を別名コンテナーとして参照したい
• ADLS の $web など、そのままの名前では復元先で扱いにくいコンテナーを別名にしたい

ADLS のサポートマトリックスでは、ターゲット側に同じ名前のコンテナーがあってはならないことや、$web コンテナーは $web のままターゲットへ復元できず renameTo を使う必要があることが示されています。今回の -RenameTo は、このような復元先名の衝突回避に直結する変更です。(Microsoft Learn)

-RenameTo の基本的な使い方

-RenameTo は、元のコンテナー名と復元先で使う新しいコンテナー名を対応させるハッシュテーブルとして渡します。GitHub 上の更新後ヘルプでは、AlternateLocationILR の構文に [-RenameTo] が追加され、入力は「元コンテナー名をキー、新しい名前を値にしたハッシュテーブル」と説明されています。(GitHub)

$instance = Get-AzDataProtectionBackupInstance `
  -SubscriptionId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
  -ResourceGroupName "rg-backup" `
  -VaultName "vault-prod"

$rp = Get-AzDataProtectionRecoveryPoint `
  -SubscriptionId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
  -ResourceGroupName "rg-backup" `
  -VaultName "vault-prod" `
  -BackupInstanceName $instance.Name

$targetStorageAccountId = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-restore/providers/Microsoft.Storage/storageAccounts/strestore001"

$containers = @(
  "sales-raw",
  "sales-curated"
)

$renameTo = @{
  "sales-raw"     = "sales-raw-restore-20260518"
  "sales-curated" = "sales-curated-restore-20260518"
}

$restoreReq = Initialize-AzDataProtectionRestoreRequest `
  -DatasourceType AzureBlob `
  -SourceDataStore VaultStore `
  -RestoreLocation "japaneast" `
  -RestoreType AlternateLocation `
  -TargetResourceId $targetStorageAccountId `
  -RecoveryPoint $rp[0].Name `
  -ItemLevelRecovery `
  -ContainersList $containers `
  -RenameTo $renameTo

ADLS の場合は、基本的な考え方は同じです。-DatasourceType を AzureDataLakeStorage にし、保護対象のバックアップインスタンス、復旧ポイント、ターゲットストレージアカウントを実環境に合わせて指定します。ADLS のマニフェストでは復元モードが RecoveryPointBased、復元先が AlternateLocation、データストアが VaultStore として定義されているため、元の場所への時点復元ではなく、保管された復旧ポイントから別ストレージアカウントへ復元する前提で設計します。(GitHub)

対象になる復元パターンと対象外のパターン

-RenameTo は便利ですが、すべての Azure Storage 復元で使えるわけではありません。復元方式を誤ると、パラメーターが認識されない、または期待どおりに復元されない原因になります。

復元パターン	-RenameTo の考え方
Azure Blob の vaulted backup から代替場所へ項目レベル復元	主な利用対象。RecoveryPoint、ItemLevelRecovery、ContainersList と組み合わせる
Azure Data Lake Storage の vaulted backup から代替場所へ項目レベル復元	利用対象。復元先の同名コンテナー衝突を避ける用途で有効
Azure Blob の OperationalStore による元の場所への時点復元	名前変更の用途ではない。既存データを指定時点へ戻す設計
ストレージアカウント全体のフル復元	コンテナー単位の別名指定ではなく、全体復元の設計を優先する
通常の Blob コンテナー名変更	対象外。Storage の既存コンテナーをその場でリネームする機能ではない

Azure Blob の復元ドキュメントでは、Operational backup は保持範囲内の任意時点へ復元でき、Vaulted backup はバックアップスケジュールに基づく復旧ポイントから復元するものとして説明されています。今回の -RenameTo は、後者のような復旧ポイントベースの代替場所・項目レベル復元で特に意味を持ちます。(Microsoft Learn)

コンテナー名の決め方で失敗を防ぐ

-RenameTo に指定する新しいコンテナー名は、Azure Storage のコンテナー名ルールに従う必要があります。コンテナー名は小文字で、英数字とハイフンを使い、3〜63文字に収める必要があります。先頭と末尾は英数字にし、連続するハイフンは使えません。ルールに違反すると要求は失敗します。(Microsoft Learn)

| 名前 | 判定 | 理由 |
| —————————- | -: | ———————- |
| sales-raw-restore-20260518 | OK | 小文字、英数字、ハイフンのみで構成されている |
| prod--restore | NG | 連続ハイフンが含まれる |
| Sales_Raw_Restore | NG | 大文字とアンダースコアが含まれる |
| dr | NG | 3文字未満 |
| restore- | NG | 末尾が英数字ではない |

運用では、元コンテナー名-restore-yyyymmdd のように日付を含めると、復元目的と時期を後から追いやすくなります。ただし、元コンテナー名が長い場合は 63 文字を超えないように短縮ルールを決めておきます。たとえば customer-transaction-archive-prod をそのまま使うと長くなりやすいため、復元時は cust-tx-archive-r20260518 のような略称を事前に定義しておくと安全です。

管理者が確認すべき設定

Az.DataProtection のバージョンとヘルプ反映状況

まず、実行環境に今回の変更が入っているかを確認します。Azure Automation アカウント、CI/CD エージェント、運用端末、踏み台サーバーでバージョンが違うと、検証環境では動いたスクリプトが本番で失敗します。

Get-InstalledModule Az, Az.DataProtection | Select-Object Name, Version

Get-Command Initialize-AzDataProtectionRestoreRequest -Syntax

Get-Help Initialize-AzDataProtectionRestoreRequest -Parameter RenameTo

Get-Help で RenameTo が表示されない場合、その環境ではまだ利用できない可能性があります。PR は main に入っていても、PowerShell Gallery の公開、Azure Automation のモジュール更新、社内の固定バージョン運用には時間差が出ます。(GitHub)

Backup vault の権限

復元先ストレージアカウントには、Backup vault のマネージド ID に適切な権限が必要です。Azure Blob と ADLS の復元ドキュメントでは、ターゲットストレージアカウントに対して Backup vault に Storage account backup contributor ロールを割り当てる必要があると説明されています。(Microsoft Learn)

権限不足は、復元要求の作成時ではなく、検証や復元開始時に表面化することがあります。新しい -RenameTo を使うかどうかに関係なく、復元先を変える場合は RBAC を先に確認してください。

# 例: 実際の割り当ては組織の権限設計に合わせて実行
# Backup vault のマネージド ID に、ターゲットストレージアカウントの
# Storage Account Backup Contributor ロールがあるか確認する

復元先ストレージアカウントの場所と空き名

ADLS の復元では、ターゲットストレージアカウントはソースストレージアカウントおよび Backup vault と同じ場所である必要があり、Vaulted backup はバックアップ元とは別のストレージアカウントへの復元を前提とします。(Microsoft Learn)

-RenameTo を使う場合でも、新しいコンテナー名が復元先に既に存在すると衝突します。復元前に、ターゲットストレージアカウント内のコンテナー一覧を取得し、RenameTo の値と重複していないか確認しておきます。

# Az.Storage の利用例。実環境の認証方式に合わせてコンテキストを作成してください。
Get-AzStorageContainer -Context $ctx |
  Select-Object -ExpandProperty Name

開発者が確認すべきスクリプト変更

RenameTo の値は配列ではなく文字列にする

PR の実装では、RenameTo の各値が配列の場合はエラーにする検証が入っています。つまり、1つの元コンテナーに対して指定できる復元先名は1つです。複数の復元先名へ分岐させる用途には使えません。(GitHub)

# OK
$renameTo = @{
  "logs" = "logs-restore-20260518"
}

# NG: 値が配列
$renameTo = @{
  "logs" = @("logs-restore-a", "logs-restore-b")
}

ContainersList と RenameTo のキーを合わせる

RenameTo は ContainersList に含めた元コンテナー名をキーにして参照されます。キー名のスペルがずれると、そのコンテナーに期待した新名称が適用されません。安全に運用するなら、ContainersList の全要素に対して RenameTo のキーが存在するかを事前チェックします。

$missing = $containers | Where-Object { -not $renameTo.ContainsKey($_) }

if ($missing.Count -gt 0) {
  throw "RenameTo に未定義のコンテナーがあります: $($missing -join ', ')"
}

PrefixMatch と併用する場合は、キーの基準を元コンテナー名にする

PrefixMatch も RenameTo も、ハッシュテーブルのキーは復元前のコンテナー名を基準にします。復元先名をキーにしてしまうと、対象プレフィックスが正しく渡らない可能性があります。PrefixMatch の値は文字列配列、RenameTo の値は文字列という違いも混同しないようにします。(GitHub)

$prefixMatch = @{
  "sales-raw" = @("2026/05/", "2026/04/")
}

$renameTo = @{
  "sales-raw" = "sales-raw-restore-20260518"
}

OperationalStore の保持ルール名変更に注意

今回の PR は、コンテナー名変更だけでなく、AzureBlob の保持ルール処理にも影響します。ChangeLog では Edit-AzDataProtectionPolicyRetentionRuleClientObject が -Name Default_OperationalStore を要求するよう変更され、Initialize-AzDataProtectionRestoreRequest に RenameTo が追加されたことが示されています。(GitHub)

特に注意すべきなのは、AzureBlob の OperationalStore ライフサイクルを Default という名前で編集しているスクリプトです。PR 上の説明では、AzureBlob の OperationalStore ライフサイクルには Default_OperationalStore を使う必要があり、Default は VaultStore 側の既定ルールとして扱われます。(GitHub)

# 旧: OperationalStore に対して Default を使っている場合は見直し対象
Edit-AzDataProtectionPolicyRetentionRuleClientObject `
  -Policy $policy `
  -Name Default `
  -LifeCycles $operationalLifecycle `
  -IsDefault $true

# 新: AzureBlob の OperationalStore では Default_OperationalStore を使う
Edit-AzDataProtectionPolicyRetentionRuleClientObject `
  -Policy $policy `
  -Name Default_OperationalStore `
  -LifeCycles $operationalLifecycle `
  -IsDefault $true

既存のバックアップポリシー編集スクリプトを探す場合は、単純に Default_OperationalStore の有無だけを見るのではなく、OperationalStore のライフサイクルを作った直後に -Name Default を渡していないかを確認します。

Select-String -Path .\*.ps1 -Pattern "Edit-AzDataProtectionPolicyRetentionRuleClientObject|Default_OperationalStore|OperationalStore"

展開前に実施したい検証手順

本番の復元作業で初めて -RenameTo を使うのは避けるべきです。復元は権限、リージョン、ターゲット名、モジュールバージョンのどれか一つがずれても失敗します。次の順序で検証すると、原因を切り分けやすくなります。

| 手順 | 確認内容 | 失敗時に見るポイント |
| -: | ————————————————— | —————————————- |
| 1 | 検証環境で Az.DataProtection のバージョンと -RenameTo のヘルプを確認 | モジュール未更新、古い Azure Automation モジュール |
| 2 | 1つの小さなコンテナーだけを対象に復元要求を作成 | ContainersList と RenameTo のキー不一致 |
| 3 | 復元先ストレージアカウントに新しいコンテナー名が存在しないことを確認 | 名前衝突、命名規則違反 |
| 4 | Backup vault のマネージド ID 権限を確認 | Storage account backup contributor 未付与 |
| 5 | 検証コマンドで復元可能性を確認 | ターゲット場所、RBAC、復旧ポイント指定の誤り |
| 6 | 復元を実行し、Backup Jobs で状態を追跡 | 長時間実行、権限不足、対象データの不整合 |
| 7 | 復元後にコンテナー、メタデータ、アプリ側参照を確認 | 復元先名をアプリ設定に反映していない |

Azure Blob の復元では、復元中に対象範囲のデータ操作がブロックされることや、アクティブなリースがある Blob を含む復元が失敗する可能性、コンテナー削除は operational restore で戻せないことなど、復元方式ごとの制約もあります。-RenameTo は名前衝突の解決策であり、これらの復元制約を取り除くものではありません。(Microsoft Learn)

よくある失敗と対処法

症状	主な原因	対処
-RenameTo が認識されない	Az.DataProtection が未対応バージョン	Get-Help と Get-Command -Syntax で確認し、検証済みバージョンへ更新
DatasourceType ... does not support renaming containers が出る	Blob / ADLS 以外、または未対応マニフェストで使用	対象データソースを確認し、対応していない場合は -RenameTo を外す
RenameTo の値に関するエラーが出る	ハッシュテーブルの値を配列にしている	1コンテナーにつき1つの文字列を指定
復元検証で権限エラーになる	Backup vault のマネージド ID に権限がない	ターゲットストレージアカウントへ Storage account backup contributor を付与
復元先で名前衝突する	RenameTo の新名称が既に存在	事前にコンテナー一覧を取得し、未使用名へ変更
ポリシー編集が失敗する	AzureBlob の OperationalStore に Default を使っている	Default_OperationalStore を使うようスクリプトを修正

今回の更新を本番運用に入れる判断基準

すぐに本番へ入れるべきかどうかは、現在の運用がどれだけ PowerShell 復元に依存しているかで判断します。

状況	推奨アクション
Blob / ADLS の復元を手動ポータル中心で行っている	急いで変更する必要は小さい。次回の復元手順書更新時に反映
PowerShell で DR 演習や定期復元テストをしている	検証環境で -RenameTo を組み込んだ復元パターンを追加
ターゲットストレージアカウントを使い回している	名前衝突回避の効果が大きいため、優先的に検証
AzureBlob のバックアップポリシーをコード管理している	Default_OperationalStore 対応を先に確認
Azure Automation Runbook で Az を自動更新している	自動更新後に破壊的変更が表面化しないよう、バージョン固定とステージング検証を実施

実務では、-RenameTo を使う前に「復元先名の命名規則」「ターゲットストレージアカウントの使い捨て方針」「復元後のアプリケーション接続先」をセットで決めておくことが重要です。コンテナー名だけを変えても、アプリや分析ジョブが旧名を参照したままだと、復元後の確認作業で混乱します。

まず取り組むべき次のアクション

今回の Azure Storage documentation update は、Blob / ADLS の項目レベル復元をより扱いやすくする一方で、Az.DataProtection のバージョン差分と保持ルール名変更に注意が必要な更新です。まずは本番環境で使っている PowerShell スクリプトから、Initialize-AzDataProtectionRestoreRequest、Edit-AzDataProtectionPolicyRetentionRuleClientObject、OperationalStore、-Name Default を検索してください。

次に、検証用のターゲットストレージアカウントを用意し、1コンテナーだけを -RenameTo 付きで復元します。そこでモジュールバージョン、RBAC、コンテナー名ルール、復元ジョブ追跡まで確認できれば、本番の DR 手順や復元Runbookへ安全に展開しやすくなります。

[2]: https://www.powershellgallery.com/packages/Az/15.6.1 “
PowerShell Gallery
| Az 15.6.1
“