Azure SQLのPITR不変性ロックがプレビュー：保持期間の短縮不能をIaC・復元試験へ組み込む

結論：バックアップ保護の延長は不可逆な設計変更として判断する

【確認済み事実】Azure SQL DatabaseとAzure SQL Managed Instanceでは、任意のロックによってPITRバックアップの不変性を設定済み保持期間に合わせられます。この延長はパブリックプレビューです。ロック後は解除と保持期間の短縮ができず、対応範囲内の延長だけが可能です。根拠は公式資料1・2です。

【編集上の判断】採否は、復旧に必要な履歴期間、保存要件、費用、利用するサービス構成を合わせて決めます。テスト後に設定を元に戻す前提の本番試行は避け、破棄可能な検証用データベースで事前に試験します。保護の強化と業務復旧の成立を、それぞれ確認する方針を提案します。

背景と技術的要因：保持期間と変更不可の期間を分けて管理する

【確認済み事実】一般提供の既定保護は、対応データベースの直近最大7日分のPITRバックアップが対象です。35日の保持設定だけでは、その全期間が不変になるわけではありません。新しいロックは両期間をそろえる機能であり、LTRの設定やデータベース本体の削除防止を兼ねません。根拠は公式資料1・2です。

【編集上の設計案】構成台帳では「保持日数」「不変性の状態」「最古の利用可能な復元時刻」「復旧に使う経路」を別項目にします。日数だけの設定監査では見逃す保護範囲を明示し、PITR、LTR、削除ロック、監査証跡をそれぞれの目的で評価します。

適用日・数値・対象構成とツール版を区別する

【日付の区別】公式資料1のロードマップ登録日と表示更新日は2026-11-03で、プレビュー欄は2026年11月です。厳密な提供開始日、GA適用日、強制導入期限、非推奨化期日は確認できずnullです。公式資料2の表示更新日は2026-11-03、資料3は2026-11-05、資料4は2026-07-14です。Learn資料の初回公表日は確認できずnullとします。本稿の公開日・確認日は2026-11-09です。

【確認済み事実】拡張の上限として35日が案内されていますが、全サービス層が35日を使えるわけではありません。SQL DatabaseのBasicのPITR保持は1〜7日です。自動バックアップ不変性はHyperscaleでは利用できず、Managed InstanceはAlways-up-to-dateまたはSQL Server 2025更新ポリシーが対象で、SQL Server 2022更新ポリシーは対象外です。根拠は公式資料1・2・4です。

【確認済み事実】公式資料3のAz 16.5.0リリースノートは、Az.Sql 7.3.0で短期保持設定コマンドへのLockImmutability／ImmutabilityStatus追加を記載しています。CLIの最小対応版と、この機能に必要な最小REST API版は参照資料から確定できずnullです。sourceDateは資料1で登録日、資料2〜4で表示更新日を保持しています。

設計・実装上の確認事項：パラメーターの存在と設定結果を照合する

【確認済み事実】公式資料2のCLI例は、SQL Databaseではaz sql db str-policy set、Managed Instanceではaz sql midb short-term-retention-policy setに、--retention-daysと--lock-immutability trueを指定します。PowerShellでは対応する短期保持設定コマンドに-LockImmutability $trueを指定します。falseや$falseはロック解除の操作になりません。

【編集上の実装案】CI実行環境でaz version、各コマンドの--help、Get-CommandによるLockImmutabilityパラメーターの存在を確認し、動作検証した版を固定します。サブスクリプション、DB名、サービス層、MI更新ポリシー、実行権限を読み取りで確認してから変更します。記載例の35日を全環境へ一括適用しません。

【編集上のIaC設計案】Terraform・Bicepのモジュール、使用API、プロバイダーがロック状態を表現し、読み戻せるかを検証します。未対応なら成功扱いにせず、検証済みの設定手段とIaCの管理範囲を記録します。保持期間短縮やfalseへの復帰を含むplan／what-ifは審査対象にし、旧テンプレートへの復帰を切戻し手順にしません。

【編集上の実装案】ロックを承認する変更と、後日の保持延長を別々に記録します。変更前後の保持日数とロック表示、使用版、実行者、時刻、結果を採取し、同じ構成の再適用と日数短縮の拒否を検証環境で確認します。本番の値を一時的に長くして試す手順は採用しません。

運用・監視・フェイルオーバー・責任分界の技術論点

【確認済み事実】ロック後もデータベース自体は削除できます。保持期間を延ばしても期限切れのバックアップや過去の復元時点は復活しません。公式資料2には、非HyperscaleからHyperscaleへの移行で不変性保護が失われること、MIで月間約5,000件のDB管理操作がある環境では一部のDBに保護が適用されない場合があることも記載されています。

【確認済み事実】SQL Databaseのgeoリストアは地理的冗長なバックアップ構成が条件です。LRS・ZRSだけでは利用できません。また、既定の不変性に追加料金がないことと、保持・バックアップストレージの費用が発生しないことは同義ではありません。根拠は公式資料2・4です。

【編集上の監視案】日数やロックの変更要求と結果、サービス層・MI更新ポリシーの変更、復元失敗、利用可能な履歴、保管量・費用を観測します。設定が成功したことだけを復元可能性の証明にせず、疑わしい変更の前に戻る復元試験を定期的に実施します。ログの取得先と通知権限もDB管理権限とは分けて確認します。

【編集上のDR設計案】通常のフェイルオーバーに加え、クリーンな時点への復元と、復旧先の接続・認証・アプリ再開を試験します。不変性ロックだけでリージョン障害や不正データの混入まで解決したとは判断せず、復元ポイントの選定、実測RPO・RTO、必要な鍵と接続設定の保全を受入条件にします。

【編集上の責任分界案】DB担当は対象・保護状態・復元、IaC担当は再適用と変更方向、業務責任者は保持期間と再開判定、委託先は作業範囲と証跡提出を担う案を定めます。プレビューを採用する範囲と代替復旧策は、現行の利用条件・契約条件を確認して承認します。

【適用上の前提】本稿は個別環境の設計保証や法的助言を行いません。実装適用にあたっては検証環境での事前テストおよび業務範囲の確認が必要です。以下のチェックリストは編集上の提案であり、環境ごとの受入条件を具体化してください。