SQL Server Backup to URL for Azure Blob Storage – SQL Serverでまず押さえるべき結論は、Azure Blob StorageをSQL ServerやAzure SQL Managed Instanceのバックアップ先として使う場合、URLでBLOBを指定し、SQL Server Credentialに認証情報を持たせる設計が前提になるという点です。2026年5月時点で特に確認したいのは、単一ブロックBLOBの上限を「約200GB」ではなく約195.3GBとして見積もること、SAS・ストレージキー・マネージドIDを環境ごとに使い分けること、そしてバックアップジョブのストライピング、圧縮、復元テストを見直すことです。(GitHub)
この更新は「バックアップ方式が全面的に変わる」という話ではありません。実務上のポイントは、既存のBACKUP TO URL運用で見落としやすい制限、認証、サイズ設計、Azure SQL Managed Instanceへの移行時の差分を正しく反映することです。特に大容量データベース、オンプレミスSQL ServerからAzureへの移行、SQL Server on Azure VM、SQL Server 2025以降の運用では、設計書とジョブ定義を早めに確認しておきましょう。
SQL Server Backup to URL for Azure Blob Storageの対象範囲
SQL Server Backup to URL for Azure Blob Storageは、SQL ServerのバックアップファイルをAzure Blob Storage上のURLへ直接書き込む機能です。Microsoft Learnの該当ドキュメントでは、対象としてSQL ServerとAzure SQL Managed Instanceが示されており、DISKやTAPEに近い構文でバックアップ・復元を行いつつ、Azure Blob Storage特有の認証やBLOB制限に対応する必要があります。(Microsoft Learn)
注意したいのは、「Azure SQL」といってもすべてのサービスで同じように使うわけではない点です。Azure SQL Databaseは自動バックアップが基本で、この記事の主な対象はAzure SQL Managed Instance、SQL Server on Azure VM、オンプレミスまたはAzure Arc対応のSQL Serverです。
| 環境 | Backup to URLとの関係 | 確認ポイント |
|---|---|---|
| SQL Serverオンプレミス | Azure Blob Storageをバックアップ先にできる | SAS、ストレージキー、プロキシ、回線帯域を確認 |
| SQL Server on Azure VM | Azure Blob Storageへのバックアップに加え、条件を満たせばマネージドIDも利用可能 | SQL Server 2022 CU17以降、SQL IaaS Agent拡張、権限設定を確認 |
| Azure SQL Managed Instance | BACKUP TO URLが利用できるが、SQL Serverと同じではない | COPY_ONLY、ストライプ数、TDE、認証方式を確認 |
| SQL Server enabled by Azure Arc | SQL Server 2025以降ではマネージドID利用が選択肢になる | Primary managed identityとStorage Blob Data Contributorを確認 |
| Azure SQL Database | 通常は自動バックアップやPITRが中心 | ネイティブ.bak運用とは分けて考える |
2026年5月時点で押さえるべき変更点
今回の確認で重要なのは、機能追加そのものよりも、制限値と推奨構成の理解を最新化することです。GitHub上のMicrosoftDocs履歴では、SQL Server Backup to URLのバックアップサイズ制限がより正確に整理され、単一ブロックBLOBの上限が約195.3GBであること、トランザクションログバックアップで複数ファイルを使う場合のMAXTRANSFERSIZEの挙動が明記されています。(GitHub)
| 確認ポイント | 内容 | 管理者・開発者への影響 |
|---|---|---|
| 単一ブロックBLOBの上限 | 約195.3GBとして扱う | 200GBぎりぎりの単一ファイル設計は避ける |
| ストライピング | 最大64 URLで大容量バックアップに対応 | 大容量DBや差分・非圧縮バックアップでは複数URLを前提にする |
| トランザクションログバックアップ | 複数ファイル指定時はMAXTRANSFERSIZEが想定通り効かない場合がある | ログバックアップのサイズ見積もりと検証が必要 |
| ブロックBLOB優先 | SQL Server 2016以降ではブロックBLOBが推奨 | SASを使う設計が基本になる |
| マネージドID | SQL Server 2025、SQL Server on Azure VMなど一部環境で利用可能 | 従来のSAS手順と混同しない |
| 不変ストレージ | SQL Server 2025でコンテナーレベルの不変ストレージをサポート | ランサムウェア対策になるが、上書き運用は見直しが必要 |
仕組みを理解する：URL、BLOB、Credentialの関係
Backup to URLの構成要素はシンプルですが、ここを誤るとバックアップジョブが失敗します。必要なのは、Azure Storageアカウント、コンテナー、BLOB名、そしてSQL Server Credentialです。
TO URLで指定するURLは、コンテナーだけではなく、実際のBLOBファイル名まで含める必要があります。たとえば次のような形式です。
https://<storage-account>.blob.core.windows.net/<container>/<backup-file>.bak既存のBLOB名を指定すると、原則としてバックアップは失敗します。上書きするにはWITH FORMATが必要ですが、ファイルスナップショットバックアップや不変ストレージを使う場合は、上書き前提の運用が問題になります。また、HTTPによるBackup to URLはサポートされていません。(Microsoft Learn)
SQL Server Credentialには、次のいずれかの認証情報を保存します。
| 認証方式 | 主な使いどころ | 注意点 |
|---|---|---|
| SAS | SQL Server 2016以降のブロックBLOB運用で基本になる | トークンの期限、権限、先頭の?に注意 |
| ストレージアカウントキー | 従来構成やページBLOB利用時 | 共有キー無効化やキー漏えいリスクに注意 |
| マネージドID | SQL Server 2025、SQL Server on Azure VMなど対応環境 | 対象環境、Primary managed identity、RBAC設定が必要 |
ブロックBLOBとページBLOBはどう選ぶべきか
実務では、SQL Server 2016以降であればブロックBLOBとSASの組み合わせを第一候補にします。公式情報では、ストレージキーをCredentialで使う場合はページBLOB、SASを使う場合はブロックBLOBになり、SQL Server 2016以降ではブロックBLOBが推奨されています。理由は、SASのほうがアクセス権を限定しやすく、複数ブロックBLOBへのバックアップで大きなバックアップや性能面に対応しやすいためです。(Microsoft Learn)
ただし、ブロックBLOBにも上限があります。単一ブロックBLOBは約195.3GBが目安で、SQL Serverが小さいブロックサイズで書き込むと、ファイルサイズが200GB未満でも50,000ブロック制限に達する可能性があります。差分バックアップや非圧縮バックアップでは、早い段階でストライピングを検討するのが安全です。(GitHub)
管理者が確認すべき設定
Backup to URLで障害が起きる原因の多くは、T-SQLの構文ミスではなく、Azure Storage側の設定、Credential、ネットワーク、権限の不整合です。運用開始前、または更新後の棚卸しでは、次の項目を確認してください。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| コンテナーのアクセスレベル | Azure Storageのコンテナー設定 | 原則privateにする |
| SASの権限 | SASまたはStored Access Policy | 読み取り、書き込み、リスト、削除の必要範囲を確認 |
| SASの期限 | SASトークンまたはポリシー | ジョブの運用期間より短すぎないか |
| Credential | sys.credentials | 名前、IDENTITY、SECRETが環境に合っているか |
| 共有キー設定 | Storage account configuration | 従来のSAS・キー構成でShared Key無効化の影響がないか |
| SQL Server権限 | ロールとサーバー権限 | db_backupoperatorとCredential操作権限を確認 |
| ネットワーク | NSG、Firewall、Proxy、Private Endpoint | 443番ポート、プロキシ認証、名前解決を確認 |
| リージョン | VMとStorage account | SQL Server on Azure VMでは同一リージョンが望ましい |
公式のベストプラクティスでは、BLOBの誤上書きを避けるためにバックアップごとに一意のファイル名を付けること、コンテナーをprivateにすること、Azure VM上のSQL ServerではVMと同じリージョンのStorage accountを使うこと、WITH COMPRESSIONでコストと時間を抑えることが推奨されています。(Microsoft Learn)
SASを使う基本的なバックアップ手順
SASでブロックBLOBへバックアップする場合、Credential名はコンテナーURLに合わせるのが基本です。SASトークンをSECRETに入れるときは、先頭の?を含めないようにします。?付きで登録すると、OSエラー50などの原因になることがあります。(Microsoft Learn)
CREATE CREDENTIAL [https://<storage-account>.blob.core.windows.net/<container>]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = '<sas-token-without-leading-question-mark>';
GO
BACKUP DATABASE [AppDb]
TO URL = 'https://<storage-account>.blob.core.windows.net/<container>/AppDb_full_20260508_01.bak'
WITH COMPRESSION, CHECKSUM, STATS = 5;
GOバックアップ後は、取得できたかどうかだけでなく、復元に使えるかを確認します。運用では、少なくとも定期的に別環境でリストアテストを行い、RTOとRPOに合うか確認してください。
RESTORE VERIFYONLY
FROM URL = 'https://<storage-account>.blob.core.windows.net/<container>/AppDb_full_20260508_01.bak'
WITH CHECKSUM;
GO大容量データベースではストライピングを前提に設計する
大容量DBでは、単一ファイルにこだわらず複数URLへ分割するストライピングを使います。公式情報では、ブロックBLOBの最適化のためにBLOCKSIZE = 65536、MAXTRANSFERSIZE = 4194304が推奨されており、大容量バックアップ時のI/Oエラー対策としても、圧縮、複数URL、MAXTRANSFERSIZE、BLOCKSIZEの組み合わせが示されています。(Microsoft Learn)
BACKUP DATABASE [AppDb]
TO
URL = 'https://<storage-account>.blob.core.windows.net/<container>/AppDb_full_20260508_01.bak',
URL = 'https://<storage-account>.blob.core.windows.net/<container>/AppDb_full_20260508_02.bak',
URL = 'https://<storage-account>.blob.core.windows.net/<container>/AppDb_full_20260508_03.bak',
URL = 'https://<storage-account>.blob.core.windows.net/<container>/AppDb_full_20260508_04.bak'
WITH
COMPRESSION,
CHECKSUM,
MAXTRANSFERSIZE = 4194304,
BLOCKSIZE = 65536,
STATS = 5;
GO判断基準としては、圧縮後のバックアップサイズが150GBを超える、差分バックアップが肥大化しやすい、バックアップ時間がSLAに近い、過去にI/Oエラーやブロック数上限のエラーが出た、といった場合はストライピングを検討します。単一BLOBの上限に近づいてから対処するより、最初から複数URLで設計したほうが運用が安定します。
Azure SQL Managed Instanceでの注意点
Azure SQL Managed InstanceはSQL Server互換性が高いものの、バックアップにはPaaSならではの制限があります。Managed Instanceには自動バックアップがあり、ユーザーが作成できるフルバックアップはCOPY_ONLYが前提です。また、バックアップ先はAzure Blob StorageへのBACKUP TO URLで、FILE、TAPE、バックアップデバイスはサポートされません。(Microsoft Learn)
Managed Instanceでは、バックアップまたは復元でAzure Storageにアクセスする際、認証方式としてマネージドIDまたはSASを使います。アクセスキーはサポートされないため、オンプレミスSQL Serverで使っていたストレージキー前提のスクリプトをそのまま移行しないようにしてください。また、Managed Instanceでは最大32ストライプ、1ストライプあたり195GBという考え方も設計に入れる必要があります。(Microsoft Learn)
移行時は、次の順番で確認すると失敗しにくくなります。
| 手順 | 確認すること |
|---|---|
| 事前評価 | ソースDBのサイズ、TDE、FILESTREAM、互換性レベルを確認 |
| バックアップ設計 | 圧縮後サイズを見積もり、必要なストライプ数を決める |
| 認証設計 | Managed Instance側でSASまたはマネージドIDを準備 |
| 復元テスト | 本番移行前に検証用インスタンスへ復元 |
| 切り戻し計画 | 復元失敗時に戻せる手順と期限を決める |
特にTDEには注意が必要です。サービス管理TDEで暗号化されたManaged Instanceのデータベースでは、BACKUP DATABASE ... WITH COPY_ONLYに制約があります。移行・退避用途でネイティブバックアップを使う場合は、暗号化方式も含めて事前に確認してください。(Microsoft Learn)
SQL Server on Azure VMとマネージドIDの確認ポイント
SQL Server on Azure VMでは、SQL Server 2022 CU17以降などの条件を満たすと、Microsoft EntraのマネージドIDを使ってAzure Blob Storageへバックアップ・復元できます。必要条件には、SQL IaaS Agent拡張への登録、Microsoft Entra認証の構成、Azure Blob Storageへのネットワーク到達性、Primary managed identityへのStorage Blob Data Contributorロール付与などがあります。(Microsoft Learn)
マネージドIDを使う場合、Credentialは次のように作成します。
CREATE CREDENTIAL [https://<storage-account>.blob.core.windows.net/<container>]
WITH IDENTITY = 'Managed Identity';
GOSASトークンを秘密情報として保持しない点はメリットですが、権限不足やPrimary managed identity未設定だと、バックアップ時にアクセス拒否エラーが発生します。トラブルシューティングでは、マネージドIDがVMに割り当てられているか、Storage accountにStorage Blob Data Contributorが付与されているか、FirewallやPrivate Endpointで接続が遮断されていないかを順に確認しましょう。(Microsoft Learn)
SQL Server 2025と不変ストレージの扱い
SQL Server 2025では、Azure Blob Storageの不変ストレージを使ったBackup to URLが重要な選択肢になります。不変ストレージに書き込まれたファイルは、ポリシーに従って変更や削除ができないため、ランサムウェア対策や監査要件のある環境で有効です。公式情報では、現時点でサポートされるのはコンテナーレベルの不変ストレージとされています。(Microsoft Learn)
ただし、不変ストレージでは「同じファイル名に上書きする」運用と相性が悪くなります。WITH FORMATを使って同名バックアップを上書きしようとしても、既存ファイルがある場合は失敗します。したがって、日付、時刻、バックアップ種別、ストライプ番号を含めたファイル名規則を作ることが必須です。
<database>_<backup-type>_<yyyyMMddHHmm>_<stripe-no>.bak
例: AppDb_full_202605081030_01.bak開発者が確認すべき実装・展開上の注意点
アプリケーション開発者やSREが関わる場合、Backup to URLはDBAだけの設定ではありません。CI/CD、インフラコード、監視、障害復旧手順に影響します。
まず、環境ごとにStorage account、コンテナー、Credential名、SAS期限を変数化します。本番と検証で同じコンテナーを使うと、誤削除や誤復元のリスクが高まります。次に、バックアップジョブの成功だけでなく、バックアップサイズ、所要時間、失敗時のエラー番号、BLOBの残存状態を監視します。失敗したバックアップでは、無効なBLOBやアクティブリースが残ることがあり、再実行時の障害原因になります。(Microsoft Learn)
展開時は、次のようなチェックをリリース前に入れておくと安全です。
| チェック | 失敗した場合の影響 |
|---|---|
| Credentialが存在するか | バックアップジョブが即失敗する |
| SASが期限切れでないか | ある日突然バックアップできなくなる |
| Storage accountへ接続できるか | ネットワーク変更で失敗する |
| バックアップ先BLOB名が一意か | 上書き失敗または誤上書きの原因になる |
| ストライプ数がサイズに合うか | ブロック数上限やI/Oエラーの原因になる |
| 復元テスト済みか | 障害時に復旧不能になる |
よくある失敗と対策
Backup to URLの失敗は、エラーメッセージだけを見ると分かりにくいことがあります。代表的な失敗パターンを先に押さえておきましょう。
| 失敗しやすいポイント | 症状 | 対策 |
|---|---|---|
SASトークンの先頭に?を含めてCredentialを作成 | OSエラー50などでバックアップ失敗 | ?を除いた文字列をSECRETに入れる |
| 単一BLOBに大容量バックアップを保存 | I/Oエラー、ブロック数上限、3063エラー | 圧縮、複数URL、MAXTRANSFERSIZE、BLOCKSIZEを使う |
| 同じBLOB名を使い回す | バックアップ失敗、上書きリスク | 日時とストライプ番号を含める |
復元時のBLOCKSIZE不一致 | Filemarkが一致しないエラー | バックアップ時と同じBLOCKSIZEで復元 |
| 失敗したBLOBが残る | 412や409 Conflict | アクティブリースを確認し、不要BLOBを削除 |
| プロキシ制限に引っかかる | 接続切断、502、407 Proxy Authentication Required | WinHTTPプロキシ、認証、スロットリングを確認 |
| SQL Server 2012/2014で大容量バックアップ | 1TB制限やページBLOB関連の問題 | 圧縮、ストライピング、バージョンアップを検討 |
公式のトラブルシューティングでは、大容量バックアップ時にCOMPRESSION、MAXTRANSFERSIZE、BLOCKSIZE、複数URLを検討すること、復元時のFilemarkエラーでは同じBLOCKSIZEを指定して再実行すること、SAS期限切れやルート証明書不足、Storage account種別の不一致などを確認することが示されています。(Microsoft Learn)
既存環境で今すぐやるべき棚卸し
既存のBackup to URL運用がある場合は、次の順番で棚卸ししてください。
まず、全SQL Serverインスタンスでsys.credentialsを確認します。SASを使っているのか、ストレージキーを使っているのか、マネージドIDを使っているのかを分類します。
SELECT
name,
credential_identity,
create_date,
modify_date
FROM sys.credentials
WHERE name LIKE 'https://%.blob.core.windows.net/%'
OR credential_identity IN ('SHARED ACCESS SIGNATURE', 'Managed Identity');次に、バックアップ履歴からファイルサイズと所要時間を確認します。圧縮後サイズが150GBを超えている、差分バックアップが大きい、ログバックアップが肥大化している、バックアップ時間が延びている場合は、ストライピングとパラメーターの見直しを行います。
最後に、復元テストを実施します。バックアップが成功していても、SAS期限切れ、Credential不一致、BLOB削除、ブロックサイズ不一致、TDEキーの問題があると、障害時に復元できません。バックアップ運用の品質は「バックアップ取得」ではなく「復元成功」で判断しましょう。
まとめ：次に取るべき行動
SQL Server Backup to URL for Azure Blob Storage – SQL Serverの確認で重要なのは、Azure Blob Storageを単なる保存先として見るのではなく、認証、BLOB種別、サイズ上限、ネットワーク、復元性まで含めたバックアップ基盤として設計することです。
まず、現在のCredentialとStorage account設定を棚卸ししてください。次に、単一BLOBの上限を約195.3GBとして再計算し、大容量DBではストライピングを検討します。Azure SQL Managed Instanceへ移行する場合は、COPY_ONLY、認証方式、ストライプ数、TDEの制限を確認します。SQL Server on Azure VMやSQL Server 2025以降を使う場合は、マネージドIDと不変ストレージを採用できるか検討しましょう。
最終的には、バックアップジョブを直すだけで終わらせず、復元テスト、監視、ファイル名規則、SAS更新手順、失敗BLOBの削除手順まで運用 Runbook に反映することが、今回の更新を実務に活かす最短ルートです。
コメント