Azure SQLのバックアップ運用で「大容量SQL Serverのフルバックアップが長い」「復元テストに時間がかかる」「本番VMへの負荷を下げたい」と感じている場合、今回のPublic Previewは確認する価値があります。2026年6月3日に案内された「Snapshot backup for SQL Server in Azure VMs」は、Azure VM上で動くSQL Serverに対し、AzureディスクスナップショットとSQL Serverのトランザクションログバックアップを組み合わせるバックアップ方式です。ポイントは、従来よりも短時間・低負荷で大容量データベースのフルバックアップを取得しやすくなることです。(マイクロソフト Azure)
ただし、対象はAzure SQL DatabaseやAzure SQL Managed Instanceではなく、Azure VM上のSQL Serverです。また、ステータスは「In preview」であり、Azure Updates上のプレビュー機能は非本番用途・検証用途として扱うのが前提です。本番適用を急ぐより、まずは対象VM、対応バージョン、復元方式、コスト、既存バックアップとの関係を確認するのが安全です。(マイクロソフト Azure)
まず結論：大容量SQL Server VMのバックアップ負荷を下げるためのプレビュー機能
今回の変更で、Azure BackupはSQL Server in Azure VMsに対して、スナップショットベースのバックアップをプレビュー提供します。従来のストリーミング型バックアップでは、フルバックアップ時にSQL Server側のI/O、ネットワーク、バックアップ処理時間が課題になりやすく、大容量データベースほどバックアップウィンドウの確保が難しくなります。
Snapshot backup for SQL Server in Azure VMsでは、Azure managed diskの増分スナップショットを使ってバックアップポイントを作成し、ログバックアップを組み合わせてポイントインタイムリストアを可能にします。Microsoft Learnでは、大容量データベースのバックアップ性能向上、Instant/operational tierからの高速復元、低RPOの実現が主なメリットとして説明されています。(GitHub)
特に確認すべき対象は、次のような環境です。
- 数TB級のSQL ServerデータベースをAzure VMで運用している
- フルバックアップの処理時間が長く、業務時間外に収まらない
- 復元テストや障害時復旧の所要時間を短縮したい
- Always On Availability Groupsを含むSQL Server VMの保護方式を見直したい
- Azure Backupの標準運用に寄せつつ、SQL Serverネイティブのログ復旧も重視したい
一方で、すべてのSQL Server VMにすぐ適用すべき機能ではありません。プレビュー段階では未対応シナリオがあり、既存のバックアップ設計やDR設計と噛み合わない可能性があります。
何が変わるのか
AzureディスクスナップショットとSQLログバックアップを組み合わせる
新しい方式では、フルバックアップ相当の取得にAzure managed diskの増分スナップショットを使います。Azure Backupは、選択されたデータベースを含むディスク群に対してアプリケーション整合性のあるスナップショットを作成し、ログバックアップはデータベース単位でRecovery Services vaultへ送ります。復元時には、スナップショットを別VMへ戻し、必要に応じてログを適用してポイントインタイムリストアを行います。(GitHub)
実務上の意味は、単に「コピーが速くなる」ことではありません。フルバックアップ時にソースVMのリソースを長時間使い続けにくくなるため、大容量DBのバックアップウィンドウを短縮しやすくなります。Microsoft Learnでは、データベースを短時間quiesceしてアプリケーション整合性のあるスナップショットを取得し、スナップショット作成とoperational tierでの利用可能化は数分で完了すると説明されています。(GitHub)
インスタンス単位で複数データベースをまとめて扱える
従来のSQL Serverバックアップ運用では、データベース単位の保護・復元が中心になりがちです。今回のスナップショットバックアップでは、SQL Serverインスタンス単位でスナップショットを取得し、複数データベースを一度の操作で選択できます。公式ドキュメントでは、1回のスナップショット操作で最大12個のユーザーデータベースを選択できるとされています。(GitHub)
これは、業務システムが複数DBに分かれている場合に重要です。例えば、販売管理DB、在庫DB、認証DB、監査ログDBが同一SQL Serverインスタンス上で連動している場合、個別DBだけを別々のタイミングで戻すと整合性確認が複雑になります。インスタンス単位で近い時点のスナップショットを持てることで、復旧手順の設計がしやすくなります。
ただし、同一インスタンス内で「一部DBはスナップショット方式、一部DBはストリーミング方式」といった混在保護はサポート対象外です。導入前に、インスタンス内のDBをまとめて同じ保護モードにできるか確認してください。(GitHub)
従来のストリーミングバックアップとの違い
| 比較項目 | 従来のSQL Server in Azure VMバックアップ | Snapshot backup for SQL Server in Azure VMs |
|---|---|---|
| 主な方式 | SQL ServerのバックアップデータをRecovery Services vaultへストリーミング | managed diskの増分スナップショットとSQLログバックアップを併用 |
| 向いている環境 | 一般的なDBサイズ、既存運用との互換性重視 | 大容量DB、短いバックアップウィンドウ、復元速度重視 |
| フルバックアップ時の負荷 | VMのI/O、CPU、ネットワークに影響しやすい | ソースVMへの長時間負荷を抑えやすい |
| 復元 | Vault上のバックアップから復元 | Snapshot data storeやVault上の復元ポイントを利用 |
| RPO | ログバックアップにより短縮可能 | スナップショットにログバックアップを組み合わせてポイントインタイム復元を実現 |
| 注意点 | 大容量DBでは時間がかかることがある | プレビュー制限、対応ストレージ、復元方式、追加コストの確認が必要 |
Microsoftは、ストリーミングバックアップで6TBを超えると性能上の問題が出る可能性があるとし、4TBを超えるデータベースで高速なバックアップ・復元が必要な場合はSQL Snapshot backupの利用を推奨しています。(GitHub)
このため、判断基準は「全環境で新方式に置き換える」ではなく、「大容量DBや復元時間が課題の環境から検証する」です。小規模DBや既存バックアップで問題がない環境では、プレビュー段階で急いで変更するメリットは限定的です。
対象範囲とサポート条件
Snapshot backup for SQL Server in Azure VMsの対象は、Azure VM上のSQL Serverです。Azure SQLという大きな枠で見ると混同しやすいですが、Azure SQL DatabaseやAzure SQL Managed Instanceの自動バックアップ機能とは別物です。
プレビュー時点での主な対応・非対応は次のとおりです。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 対応SQL Server | SQL Server 2016以降 |
| 対応OS | Windows Server 2016以降 |
| バックアップ構成 | スタンドアロンインスタンス、Always On AG |
| 対応バックアップ種別 | Snapshot Full、ログバックアップあり/なしのSnapshot Full、アドホックなSnapshot copy-only full |
| 対応クライアント | Azure portal、PowerShell |
| 最大DBサイズ | 35TB |
| 1回のインスタンススナップショットで選択できるDB | 最大12個のユーザーデータベース |
| 非対応ストレージ構成 | Premium SSD v2、Ultra Disk、Write Accelerator付きディスク、Ephemeral OS disk、共有ディスク |
| 非対応復元 | Original Location Restore、Cross Region Restore、Cross Subscription Restore |
| 非対応機能 | SQL圧縮、システムDBのスナップショットバックアップ、同一インスタンス内の保護モード混在 |
| その他 | Resiliency experienceとの統合は未対応 |
特に見落としやすいのは、復元方式です。プレビューではAlternate Location Restoreのみがサポートされ、元の場所へ直接戻すOriginal Location Restoreは非対応です。障害時に「元の本番VMへ即時上書き復元する」運用を前提にしている場合、手順を再設計する必要があります。(GitHub)
管理者が最初に確認すべき設定
Snapshot backupを有効化する前に、Azure管理者とDBAは次の項目を確認してください。
| 確認項目 | 実務上の確認ポイント |
|---|---|
| Recovery Services vault | SQL Server VMと同じリージョン、同じサブスクリプションにあるか |
| VMの接続性 | Azure BackupがVMと通信できるネットワーク構成か |
| .NET Framework | VMに.NET Framework 4.6.2以上が入っているか |
| 既存バックアップ | 同一DBに他のSQL Serverバックアップソリューションが有効になっていないか |
| データベース名 | Azure Backupのデータベース命名ガイドラインに抵触しないか |
| 権限 | managed identityとAzure Backup Snapshot Contributorロールを割り当てられるか |
| SQL権限 | NT SERVICE\AzureWLBackupPluginSvcにSQL Serverのsysadmin権限を付与できるか |
| 対象DB数 | 1回のインスタンススナップショットで選択するDBが12個以内か |
| ストレージ | 非対応ディスク構成に該当しないか |
| 復元先 | ALR用の別VM、ターゲットリソースグループ、接続先変更手順を用意できるか |
公式手順では、Recovery Services vault、VMネットワーク接続、データベース命名、.NET 4.6.2以上、他バックアップソリューションの無効化が前提条件として挙げられています。また、Azure Backupはスナップショット取得・保存のためにユーザー割り当てマネージドIDを使い、Azure Backup Snapshot Contributorロールを必要とします。(GitHub)
SQL Server側では、Azure Backupのワークロード拡張機能がAzureBackupWindowsWorkloadとしてVMにインストールされ、NT SERVICE\AzureWLBackupPluginSvcサービスアカウントが作成されます。このアカウントはバックアップと復元に使われ、SQL Serverのsysadmin権限が必要です。Azure Marketplaceから作成していないSQL Server VMでは、権限不足で検出エラーになることがあるため、事前にSSMSでログインとロールを確認しておくと展開がスムーズです。(GitHub)
バックアップポリシー設計で見るべきポイント
Snapshot backupでは、バックアップポリシーにフルスナップショット、ログバックアップ、保持期間、スナップショットを保存するリソースグループ、マネージドIDを設定します。スケジュール可能なFull Snapshot backupは6時間ごとから24時間ごと、Log backupは15分ごとから24時間ごとです。Instant recovery Snapshotの保持期間は1〜7日、ログバックアップポイントは7〜35日とされています。(GitHub)
おすすめの考え方は、まずRPOとRTOを分けて決めることです。
| 要件 | 設計の考え方 |
|---|---|
| RPOを短くしたい | ログバックアップ間隔を短くする。ログ生成量が多いDBでは性能とコストも確認する |
| RTOを短くしたい | Instant/operational tierのスナップショット保持期間を業務要件に合わせる |
| 長期保存が必要 | Vault側の保持ポリシーを監査・コンプライアンス要件に合わせる |
| 復元テストを頻繁に行う | ALR先の検証VM、ネットワーク、接続文字列切り替え手順を標準化する |
| コストを抑えたい | operational tierの保持日数を短くし、検証用DBから段階展開する |
よくある失敗は、「スナップショットなのでバックアップは速いはず」と考えて、ログバックアップ量や復元先VMの性能を見ないことです。ポイントインタイムリストアでは、スナップショットに加えてログを適用します。ログ生成量が多いシステムでは、ログバックアップの頻度、保存期間、復元時の適用時間まで含めて検証してください。
復元設計ではALR前提で手順を作る
プレビュー時点の重要な制限は、Alternate Location Restoreのみ対応している点です。つまり、復元は別のVMや別の場所へ戻す前提で設計します。復元時には、スナップショット復元ポイントを選択し、必要に応じてPoint in time restoreでトランザクションログを適用します。個別DBの復元では、SnapshotまたはLogを選択でき、Logを選ぶと近いスナップショット復元ポイントにログを適用して細かい時点へ戻せます。(GitHub)
本番運用を想定した検証では、次のような観点をチェックしてください。
| 復元テスト項目 | 確認内容 |
|---|---|
| インスタンス単位復元 | 複数DBをまとめて戻したとき、アプリ側の整合性が取れるか |
| 個別DB復元 | 誤削除や一部破損時に、対象DBだけ戻せるか |
| ポイントインタイム復元 | 目的時点までログを適用できるか |
| 接続先切り替え | アプリケーション、ジョブ、レポート、ETLの接続先を変更できるか |
| セキュリティ | TDE証明書、ログイン、権限、キー管理が復元先で成立するか |
| 運用手順 | DBAだけでなくインフラ担当、アプリ担当、監視担当の作業分担が明確か |
復元テストでは「復元が成功した」だけでは不十分です。復元後にアプリケーションが起動するか、SQL Agentジョブが意図せず動かないか、外部システム連携が二重送信しないかまで確認しましょう。
費用面で注意すべきこと
Snapshot backupは、必ずしも「速いから安い」とは限りません。公式ドキュメントでは、Recovery Services vaultに保存されるスナップショットバックアップはAzure Backup料金に基づき、Protected Instance料金とVaultストレージ料金に加えて、operational tierのスナップショットストレージ料金が発生すると説明されています。また、サブスクリプション内に保持されるmanaged disk snapshotにも保持期間に応じた料金がかかります。(GitHub)
コストを抑えるには、次の順で調整すると現実的です。
| 調整項目 | 影響 |
|---|---|
| Operational tierの保持日数 | 短いほどスナップショット保持コストを抑えやすい |
| ログバックアップ間隔 | 短いほどRPOは良くなるが、ログ量と保存量が増えやすい |
| 対象DBの選定 | 重要DBから始めると不要な保存コストを避けやすい |
| 復元テスト頻度 | 多すぎると検証VMやディスクのコストも増える |
| 長期保持ポリシー | 監査要件と実利用を分けて設計する |
特に検証段階では、全DBを対象にせず、代表的な大容量DBを1〜2個選んでバックアップ時間、復元時間、保存コストを測るのがおすすめです。
管理者・開発者が取るべき展開手順
本番に近い環境へいきなり展開するのではなく、次の順で進めると失敗しにくくなります。
| 手順 | 実施内容 |
|---|---|
| 現状把握 | SQL Server VM、DBサイズ、ログ生成量、既存バックアップ、RPO/RTOを棚卸しする |
| 対象選定 | 4TB超、復元時間が課題、夜間バックアップが伸びているDBを候補にする |
| 対応可否確認 | SQL Server/Windows Serverバージョン、ディスク構成、Always On AG、FCI有無を確認する |
| 権限設計 | managed identity、Azure Backup Snapshot Contributor、SQL sysadmin権限を整理する |
| ポリシー作成 | Full Snapshot backupとLog backupの頻度、保持期間、Snapshot Resource Groupを決める |
| 小規模検証 | 開発・検証VMでDiscovery、Enable Backup、Backup nowを実行する |
| 復元テスト | ALR先VMへインスタンス単位・DB単位で復元し、アプリ動作まで確認する |
| 監視設計 | Backup jobs、アラート、失敗時の再実行、ログ肥大時の対応を決める |
| コスト確認 | Snapshot storage、Vault storage、検証VMコストを実測する |
| 本番判断 | プレビュー制限を許容できる範囲で、非本番または限定用途から展開する |
開発者側は、バックアップ方式の変更を「インフラだけの変更」と見ない方がよいです。復元先が別VMになる場合、接続文字列、DNS、Key Vault参照、Managed Identity、SQLログイン、外部API連携、バッチ起動順が影響を受けます。復元テストには、アプリ担当者も参加すべきです。
すぐ採用すべきケース、慎重にすべきケース
採用検討に向いているケース
次の条件に当てはまる場合は、検証優先度が高いです。
- SQL Server in Azure VMで大容量DBを運用している
- フルバックアップが長時間化している
- 復元テストが遅く、DR訓練が形骸化している
- 同一インスタンス内の複数DBをまとめて整合性ある時点へ戻したい
- 非本番環境で新しいバックアップ方式を評価できる
- ALR前提の復旧手順を許容できる
慎重にすべきケース
次の条件に該当する場合は、既存運用を維持しつつ検証にとどめるのが無難です。
- Azure SQL DatabaseまたはAzure SQL Managed Instanceの話だと誤認している
- 本番でOriginal Location Restoreが必須
- Cross Region RestoreやCross Subscription RestoreをDR設計の中核にしている
- FCIや共有ディスクなど非対応構成を使っている
- 同一インスタンス内でDBごとに保護方式を分けたい
- プレビュー機能を本番SLAに組み込めない
- 既存のSQLバックアップ製品と併用前提で設計している
よくある誤解
スナップショットだけでポイントインタイムリストアできるわけではない
ポイントインタイムリストアには、スナップショットに加えてログバックアップが重要です。スナップショットは大きな復元ポイント、ログバックアップは細かい時点へ戻すための差分と考えると分かりやすいです。
フルバックアップが不要になるわけではない
Snapshot Fullという形でフルバックアップ相当の復元ポイントを作ります。従来の「バックアップファイルを長時間ストリーミングする」方式とは実装が異なりますが、保護設計としてはフル相当の復元ポイントとログの組み合わせを設計する必要があります。
プレビューだから本番では絶対使えない、という意味ではない
プレビュー機能は検証・非本番利用を前提に評価すべきですが、組織によっては限定的な本番用途で検証するケースもあります。ただし、その場合でもサポート条件、制限、障害時手順、責任範囲を明文化する必要があります。少なくとも、既存バックアップを外す前に複数回の復元テストを行ってください。
Azure SQL Databaseの機能追加ではない
今回の対象は、Azure VM上で稼働するSQL Serverです。PaaSのAzure SQL DatabaseやAzure SQL Managed Instanceを利用している場合、バックアップの仕組みや運用ポイントは異なります。記事や公式情報を読むときは、「SQL Server in Azure VM」と「Azure SQL Database」を混同しないことが重要です。
まとめ：まずは大容量DBの検証環境で復元まで試す
Snapshot backup for SQL Server in Azure VMsは、Azure SQLの中でもAzure VM上のSQL Serverを運用している管理者にとって、大容量データベースのバックアップと復元を見直すきっかけになる機能です。最大の価値は、Azure managed diskのスナップショットとSQLログバックアップを組み合わせ、フルバックアップ時の負荷を抑えながら復元時間の短縮を狙える点にあります。
一方で、プレビュー段階ではALRのみ対応、非対応ストレージ構成、最大12DB、同一インスタンス内の保護方式混在不可など、運用設計に直結する制限があります。まずは本番DBのコピーや非本番環境で、バックアップ時間、復元時間、ログ適用、アプリ接続、費用を実測してください。
次に取るべき行動は明確です。SQL Server VMの一覧を作り、DBサイズ、RPO/RTO、既存バックアップ、復元要件を棚卸しし、最も課題の大きい大容量DBからSnapshot backupの検証対象にしましょう。
コメント