Microsoft Azure Blob Storage 向けの SQL Server の Backup to URL
適用対象: 
SQL ServerAzure SQL Managed Instance
この記事では、Microsoft Azure Blob Storage をバックアップ先として使用するために必要な概念、要件、コンポーネントを紹介します。 バックアップと復元の機能は、ディスクまたはテープを使用する場合とよく似ていますが、いくつか相違点もあります。 この記事では、これらの相違点といくつかのコード例も示します。
概要
Microsoft Azure Blob Storage との間でバックアップまたは復元を実行するには、各コンポーネントと、コンポーネント間のやり取りを理解しておくことが重要です。
このプロセスでは、まず、Azure サブスクリプション内に Azure ストレージ アカウントを作成します。 このストレージ アカウントは、このストレージ アカウントで作成されたすべてのコンテナーとオブジェクトに対する完全な管理者権限を持つ管理者アカウントです。 SQL Server では、Azure ストレージ アカウントの名前とアクセス キー値を使用して認証し、Microsoft Azure Blob Storage に対して BLOB の書き込みと読み取りを実行するか、特定のコンテナーで生成された Shared Access Signature トークンを使用して読み取り/書き込み権限を付与することができます。 Azure ストレージ アカウントの詳細については、「 Azure ストレージ アカウントについて 」をご覧ください。Shared Access Signature の詳細については、「 Shared Access Signature、第 1 部: SAS モデルについて」をご覧ください。 この認証情報は、SQL Server 資格情報に格納され、バックアップまたは復元操作中に使用されます。
Azure Storage と S3 互換ストレージ
SQL Server 2012 Service Pack 1 CU2 と SQL Server 2014 では、使い慣れた T-SQL 構文を使用して Azure Storage にバックアップを安全に書き込み、Azure Blob Storage を指す URL にバックアップする機能が導入されました。 SQL Server 2016 (13.x) では、Azure 内のデータベース ファイルのファイル スナップショット バックアップと、Azure Storage セキュリティ ポリシーに対して証明書を認証する安全で簡単な方法である、Shared-Access Signature (SAS) キーを使用したセキュリティが導入されました。 SQL Server 2022 (16.x) では、S3 互換のオブジェクト ストレージにバックアップを書き込む機能が導入されています。バックアップ デバイスの種類として Azure Blob Storage を使用して Backup to URL を行うのと概念的に似た、バックアップと復元の機能があります。 SQL Server 2022 (16.x) では、REST API を使用して新しい S3 コネクタのサポートを追加することで、BACKUP/RESTORE TO/FROM URL 構文が拡張されます。
この記事では、Azure Blob Storage の Backup to URL を使用する方法について説明します。 S3 互換ストレージの Backup to URL を使用する方法の詳細については、「S3 互換オブジェクト ストレージを使用した SQL Server のバックアップと復元」を参照してください。
Azure Storage ブロック BLOB とページ BLOB へのバックアップ
Microsoft Azure Blob Storage に保存できる BLOB には、ブロックとページの 2 種類の BLOB があります。 SQL Server 2016 以降の場合は、ブロック BLOB を使用することをお勧めします。
資格情報内でストレージ キーが使用されている場合は、ページ BLOB が使用されます。Shared Access Signature が使用されている場合は、ブロック BLOB が使用されます。
ブロック BLOB へのバックアップは、SQL Server 2016 またはそれ以降のバージョンでの Azure Blob Storage へのバックアップにのみ使用できます。 SQL Server 2016 またはそれ以降を実行している場合は、ページ BLOB ではなくブロック BLOB にバックアップします。
主な理由は次のとおりです。
- BLOB アクセスを承認する方法としては、ストレージ キーよりも Shared Access Signature の方が安全です。
- 複数のブロック BLOB にバックアップして、バックアップと復元のパフォーマンスを向上させ、より大きなデータベース バックアップに対応できます。
- ブロック BLOB はページ BLOB よりも安価です。
- プロキシ サーバー経由でページ BLOB にバックアップする必要がある場合は、
backuptourl.exeを使用する必要があります。
Azure Blob Storage に大規模なデータベースをバックアップするとき、Azure SQL Managed Instance の T-SQL の相違点、制限、既知の問題に記載されている制限事項が当てはまります。
データベースが大きすぎる場合、次のいずれかの方法を実行します。
- バックアップの圧縮の使用または
- 複数のブロック BLOB へのバックアップ
Linux、コンテナー、Azure Arc 対応 SQL Managed Instance でのサポート
SQL Server インスタンスが Linux でホストされている場合は、次のものが含まれます。
- スタンドアロンのオペレーティング システム
- Containers
- Azure Arc 対応 SQL Managed Instance
- その他の Linux ベースの環境
Azure Blob Storage でサポートされている唯一の URL へのバックアップは、Shared Access Signature を使用して行われる、ブロック BLOB を対象とするものです。
Microsoft Azure Blob Storage
ストレージ アカウント: ストレージ アカウントは、すべてのストレージ サービスの開始点となります。 Microsoft Azure Blob Storage にアクセスするには、まず Azure ストレージ アカウントを作成します。 詳細については、「 ストレージ アカウントの作成」を参照してください。
コンテナー: コンテナーは一連の BLOB をグループ化します。コンテナーには BLOB を無制限に格納できます。 SQL Server のバックアップを Azure Blob Storage に書き込むには、少なくともルート コンテナーが作成されている必要があります。 コンテナーで Shared Access Signature トークンを生成し、特定のコンテナーでのみオブジェクトへのアクセス権を付与できます。
BLOB: 任意の種類とサイズのファイルです。 Azure Blob Storage に保存できる BLOB には、ブロックとページという 2 種類の BLOB があります。 SQL Server のバックアップでは、使用されている Transact-SQL 構文に応じていずれかの BLOB タイプを使用できます。 BLOB は、https://<ストレージ アカウント>.blob.core.windows.net/<コンテナー>/<BLOB> という URL 形式を使用してアドレス指定できます。 Azure Blob Storage について詳しくは、「Azure Blob Storage の概要」をご覧ください。 ページ BLOB とブロック BLOB の詳細については、「 Understanding Block and Page Blobs」 (ブロック BLOB とページ BLOB について) をご覧ください。
Azure スナップショット: ある時点で取得された Azure BLOB のスナップショットです。 詳細については、「 Creating a Snapshot of a Blob」 (BLOB のスナップショットの作成) を参照してください。 SQL Server バックアップで、Azure Blob Storage に保存されたデータベース ファイルの Azure スナップショット バックアップがサポートされるようになりました。 詳細については、「 Azure でのデータベース ファイルのファイル スナップショット バックアップ」を参照してください。
SQL Server のコンポーネント
URL: 一意なバックアップ ファイルの Uniform Resource Identifier (URI) を示します。 URL を使用して SQL Server バックアップ ファイルの場所と名前を指定します。 URL は、コンテナーだけでなく、実際の BLOB を参照している必要があります。 BLOB が存在しない場合は作成されます。 既存の BLOB を指定した場合、BLOB 内の既存のバックアップ ファイルを上書きする "WITH FORMAT" オプションを指定しない限り、BACKUP は失敗します。
サンプル URL 値を次に示します: http[s]://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak。 HTTPS は必須ではありませんが、推奨されています。
資格情報: SQL Server の資格情報は、SQL Server の外部にあるリソースへの接続に必要な認証情報を保存するために使用されるオブジェクトです。 ここで、SQL Server のバックアップおよび復元プロセスによって資格情報が使用され、Azure Blob Storage とそのコンテナー、および BLOB オブジェクトに対する認証が行われます。 資格情報には、ストレージ アカウントの名前と アクセス キー の値またはコンテナーの URL と Shared Access Signature トークンが保存されます。 資格情報が作成されたら、BACKUP/RESTORE ステートメントの構文で BLOB の種類と必要な資格情報を指定します。
Shared Access Signature の作成方法の例については、この記事で後述する「Shared Access Signature の作成」の例を参照してください。SQL Server 資格情報の作成については、この記事で後述する「資格情報の作成」の例を参照してください。
資格情報の全般的な情報については、「 資格情報」をご覧ください。
資格情報が使用されるその他の例については、「 SQL Server エージェント プロキシの作成」ご覧ください。
Azure Blob Storage のセキュリティ
Azure Blob Storage へのバックアップやそこからの復元を実行する場合のセキュリティに関する注意点と要件は次のとおりです。
Azure Blob Storage のコンテナーを作成する際は、アクセス権を private に設定することをお勧めします。 アクセス権を private に設定すると、Azure アカウントの認証に必要な情報を指定できるユーザーまたはアカウントだけがアクセスできるようになります。
重要
SQL Server では、Azure のアカウント名とアクセス キーの認証または Shared Access Signature とアクセス トークンを SQL Server 資格情報に保存する必要があります。 この情報は、バックアップ操作または復元操作の実行時に、Azure アカウントに対する認証に使用されます。
警告
Azure Storage では、ストレージ アカウントの共有キー認可を無効にできます。 共有キー認可が無効になっている場合、URL には SQL Server をバックアップできません。
BACKUP コマンドまたは RESTORE コマンドの発行に使用するユーザー アカウントは、 資格情報の変更 権限を持つ db_backup operator データベース ロールに属している必要があります。
Azure Blob Storage へのバックアップと復元の制限事項
SQL Server では、ページ BLOB でサポートされる最大バックアップ サイズが 1 TB に制限されます。 ブロック BLOB を使ってサポートされる最大バックアップ サイズは、約 200 GB (50,000 ブロック * 4 MB MAXTRANSFERSIZE) に制限されます。 ブロック BLOB では、大幅に大きなバックアップ サイズをサポートするストライピングがサポートされています。この制限は最大 64 個の URL で、その結果、次の式になります:
64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB。重要
1 つのブロック BLOB でサポートされる最大バックアップ サイズは 200 GB ですが、SQL Server でより小さなブロック サイズで書き込むことにより、バックアップ全体が転送される前に、SQL Server が 5 万ブロックの制限に達してしまう場合があります。 特に、差分または非圧縮バックアップを使用する場合は、(サイズが 200 GB 未満の場合でも) バックアップをストライプしてブロックの制限を回避します。
Transact-SQL、SMO、PowerShell コマンドレット、SQL Server Management Studio のバックアップと復元ウィザードを使用して、BACKUP ステートメントや RESTORE ステートメントを実行できます。
Azure Storage アカウントへのバックアップでは、Shared Access Signature (SAS) トークンまたはストレージ アカウント キーを使用した認証のみがサポートされます。 Microsoft Entra ID (旧称 Azure Active Directory) 認証を含む他のすべての認証方法は、サポートされていません。
論理デバイス名の作成はサポートされていません。 そのため、sp_dumpdevice または SQL Server Management Studio を使用してバックアップ デバイスとして URL を追加することはできません。
既存のバックアップ BLOB への追加はサポートされていません。 既存の BLOB へのバックアップは WITH FORMAT オプションを使用した場合にのみ上書きできます。 ただし、ファイル スナップショット バックアップを使用する場合 ( WITH FILE_SNAPSHOT 引数を使用)、元のファイル スナップショット バックアップで作成されたファイル スナップショットが孤立したまま残されるのを避けるために、 WITH FORMAT 引数は使用できません。
1 回のバックアップ操作での複数の BLOB へのバックアップは、ブロック BLOB を使用し、SQL 資格情報のストレージ アカウント キーではなく、Shared Access Signature (SAS) トークンを使用する場合にのみサポートされます。
BLOCKSIZE の指定は、ページ BLOB ではサポートされていません。
MAXTRANSFERSIZE の指定は、ページ BLOB ではサポートされていません。
backupset オプション ( RETAINDAYS と EXPIREDATE ) を指定することはサポートされていません。
SQL Server では、バックアップ デバイス名に最大 259 文字の制限があります。 BACKUP TO URL では、URL の指定に使用する必須要素に 'https://.blob.core.windows.net//.bak ' の 36 文字が使用されるため、アカウント、コンテナー、および BLOB の名前は残りの 223 文字で構成します。
2022 より前のバージョンの SQL Server では、Shared Access Signature (SAS) トークンには 256 文字の制限がるため、使用できるトークンの種類が制限されます (たとえば、ユーザー委任キー トークンはサポートされていません)。
サーバーからプロキシ サーバー経由で Azure にアクセスする場合は、トレース フラグ 1819 を使用し、次のいずれかの方法で WinHTTP プロキシ構成を設定する必要があります。
- Windows XP または Windows Server 2003 以前の場合は proxycfg.exe ユーティリティ。
- Windows Vista および Windows Server 2008 以降の場合は netsh.exe ユーティリティ。
Azure Blob Storage 向けの不変ストレージはサポートされていません。 [不変ストレージ] ポリシーを false に設定します。
Azure Blob Storage でサポートされている引数とステートメント
Azure Blob Storage での BACKUP/RESTORE ステートメントのサポート
| BACKUP/RESTORE ステートメント | サポートされています | 例外 | Comments |
|---|---|---|---|
| BACKUP | 年 | BLOCKSIZE および MAXTRANSFERSIZE は、ブロック BLOB ではサポートされています。 ページ BLOB ではサポートされていません。 | ブロック BLOB への BACKUP には、SQL Server 資格情報に保存された Shared Access Signature が必要です。 ページ BLOB への BACKUP には、SQL Server 資格情報に保存されたストレージ アカウント キーが必要であり、WITH CREDENTIAL 引数を指定する必要があります。 |
| RESTORE | 年 | SQL Server 資格情報を定義する必要があります。また、シークレットとしてストレージ アカウント キーを使用して SQL Server 資格情報を定義する場合は、WITH CREDENTIAL 引数を指定する必要があります。 | |
| RESTORE FILELISTONLY | 年 | SQL Server 資格情報を定義する必要があります。また、シークレットとしてストレージ アカウント キーを使用して SQL Server 資格情報を定義する場合は、WITH CREDENTIAL 引数を指定する必要があります。 | |
| RESTORE HEADERONLY | 年 | SQL Server 資格情報を定義する必要があります。また、シークレットとしてストレージ アカウント キーを使用して SQL Server 資格情報を定義する場合は、WITH CREDENTIAL 引数を指定する必要があります。 | |
| RESTORE LABELONLY | 年 | SQL Server 資格情報を定義する必要があります。また、シークレットとしてストレージ アカウント キーを使用して SQL Server 資格情報を定義する場合は、WITH CREDENTIAL 引数を指定する必要があります。 | |
| RESTORE VERIFYONLY | 年 | SQL Server 資格情報を定義する必要があります。また、シークレットとしてストレージ アカウント キーを使用して SQL Server 資格情報を定義する場合は、WITH CREDENTIAL 引数を指定する必要があります。 | |
| RESTORE REWINDONLY | - |
BACKUP ステートメントの構文と一般的な情報については、「BACKUP (Transact-SQL)」をご覧ください。
RESTORE ステートメントの構文と一般的な情報については、「RESTORE (Transact-SQL)」をご覧ください。
Azure Blob Storage での BACKUP の引数のサポート
| 引数 | サポートされています | 例外 | Comments |
|---|---|---|---|
| DATABASE | 年 | ||
| LOG | 年 | ||
| TO (URL) | 年 | ディスクまたはテープの場合とは異なり、URL では論理名の指定と作成はサポートされていません。 | この引数は、バックアップ ファイルの URL パスの指定に使用されます。 |
| MIRROR TO | 年 | ||
| WITH オプション: | |||
| CREDENTIAL | 年 | WITH CREDENTIAL は、BACKUP TO URL オプションを使用して Azure Blob Storage にバックアップするとき、およびシークレットとしてストレージ アカウント キーを使用して SQL Server 資格情報を定義する場合にのみサポートされます | |
| FILE_SNAPSHOT | 年 | ||
| 暗号化 | 年 | WITH ENCRYPTION 引数が指定されている場合、SQL Server ファイル スナップショット バックアップでは、バックアップを作成する前にデータベース全体が TDE で暗号化されていることを確認し、暗号化されていれば、データベースで TDE に指定されたアルゴリズムを使用して、ファイル スナップショット バックアップ ファイル自体を暗号化します。 データベース全体でデータがすべて暗号化されているわけではない場合、バックアップは失敗します (暗号化プロセスがまだ完了していないなど)。 | |
| DIFFERENTIAL | 年 | ||
| COPY_ONLY | 年 | ||
| COMPRESSION|NO_COMPRESSION | 年 | ファイル スナップショット バックアップではサポートされていません。 | |
| 説明 | 年 | ||
| 名前 | 年 | ||
| EXPIREDATE | RETAINDAYS | - | ||
| NOINIT | INIT | - | BLOB に追加することはできません。 バックアップを上書きするには、WITH FORMAT 引数を使用します。 ただし、ファイル スナップショット バックアップを使用する場合 ( WITH FILE_SNAPSHOT 引数を使用)、元のバックアップで作成されたファイル スナップショットが孤立したまま残されるのを避けるために、 WITH FORMAT 引数は使用できません。 | |
| NOSKIP | SKIP | - | ||
| NOFORMAT | FORMAT | 年 | WITH FORMAT を指定した場合を除き、既存の BLOB に対して実行されるバックアップは失敗します。 WITH FORMAT を指定すると、既存の BLOB が上書きされます。 ただし、ファイル スナップショット バックアップを使用する場合 ( WITH FILE_SNAPSHOT 引数を使用)、元のファイル スナップショット バックアップで作成されたファイル スナップショットが孤立したまま残されるのを避けるために、FORMAT 引数は使用できません。 ただし、ファイル スナップショット バックアップを使用する場合 ( WITH FILE_SNAPSHOT 引数を使用)、元のバックアップで作成されたファイル スナップショットが孤立したまま残されるのを避けるために、 WITH FORMAT 引数は使用できません。 | |
| MEDIADESCRIPTION | 年 | ||
| MEDIANAME | 年 | ||
| BLOCKSIZE | 年 | ページ BLOB ではサポートされていません。 ブロック BLOB ではサポートされています。 | ブロック BLOB で許可される 50,000 ブロックの使用を最適化するため、BLOCKSIZE=65536 にすることをお勧めします。 |
| BUFFERCOUNT | 年 | ||
| MAXTRANSFERSIZE | 年 | ページ BLOB ではサポートされていません。 ブロック BLOB ではサポートされています。 | 既定値は 1048576 です。 指定できる値は、65536 バイト刻みで最大 4 MB までです。 ブロック BLOB で許可される 50,000 ブロックの使用を最適化するため、MAXTRANSFERSIZE=4194304 にすることをお勧めします。 |
| NO_CHECKSUM | CHECKSUM | 年 | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | 年 | ||
| [統計] | 年 | ||
| REWIND | NOREWIND | - | ||
| UNLOAD | NOUNLOAD | - | ||
| NORECOVERY | STANDBY | 年 | ||
| NO_TRUNCATE | 年 |
BACKUP の引数の詳細については、「BACKUP (Transact-SQL)」をご覧ください。
Azure Blob Storage での RESTORE の引数のサポート
| 引数 | サポートされています | 例外 | Comments |
|---|---|---|---|
| DATABASE | 年 | ||
| LOG | 年 | ||
| FROM (URL) | 年 | FROM URL 引数は、バックアップ ファイルの URL パスの指定に使用されます。 | |
| WITH Options: | |||
| CREDENTIAL | 年 | WITH CREDENTIAL は、RESTORE FROM URL オプションを使用して Microsoft Azure Blob Storage から復元する場合にのみサポートされます。 | |
| PARTIAL | 年 | ||
| RECOVERY | NORECOVERY | STANDBY | 年 | ||
| LOADHISTORY | 年 | ||
| MOVE | 年 | ||
| REPLACE | 年 | ||
| RESTART | 年 | ||
| RESTRICTED_USER | 年 | ||
| FILE | - | ||
| PASSWORD | 年 | ||
| MEDIANAME | 年 | ||
| MEDIAPASSWORD | 年 | ||
| BLOCKSIZE | 年 | ||
| BUFFERCOUNT | - | ||
| MAXTRANSFERSIZE | - | ||
| CHECKSUM | NO_CHECKSUM | 年 | ||
| STOP_ON_ERROR | CONTINUE_AFTER_ERROR | 年 | ||
| FILESTREAM | 年 | スナップショット バックアップではサポートされていません。 | |
| [統計] | 年 | ||
| REWIND | NOREWIND | - | ||
| UNLOAD | NOUNLOAD | - | ||
| KEEP_REPLICATION | 年 | ||
| KEEP_CDC | 年 | ||
| ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER | 年 | ||
| STOPAT | STOPATMARK | STOPBEFOREMARK | 年 |
RESTORE の引数の詳細については、「RESTORE の引数 (Transact-SQL)」をご覧ください。
SSMS を使用してバックアップする
SQL Server 資格情報を使用して SQL Server Management Studio のバックアップ タスクで URL にデータベースをバックアップできます。
Note
SQL Server ファイル スナップショット バックアップを作成するには、または既存のメディア セットを上書きするには、SQL Server Management Studio のバックアップ タスクではなく、Transact-SQL、PowerShell、または C# を使用する必要があります。
次の手順では、Azure Storage へのバックアップを可能にするために SQL Server Management Studio でデータベースのバックアップ タスクに対して行う変更について説明します。
オブジェクト エクスプローラーで、SQL Server データベース エンジンのインスタンスに接続し、そのインスタンスを展開します。
[データベース]を展開して目的のデータベースを右クリックし、[タスク] をポイントして、[バックアップ...] を選択します。
[全般] ページの [バックアップ先] セクションで、 [バックアップ先] ドロップダウン リストの [URL] オプションが使用できるようになります。 [URL] オプションを使用して、Windows Azure Storage へのバックアップを作成します。 [追加] を選択すると、[バックアップ先の選択] ダイアログ ボックスが開きます。
[Azure ストレージ コンテナー]: バックアップ ファイルを格納する Microsoft Azure ストレージ コンテナーの名前。 ドロップダウン リストから既存のコンテナーを選択するか、コンテナーを手動で入力します。
[共有アクセス ポリシー]: 手動で入力されたコンテナーの Shared Access Signature を入力します。 このフィールドは、既存のコンテナーを選択した場合には使用できません。
[バックアップ ファイル]: バックアップ ファイルの名前。
[新しいコンテナー]: Shared Access Signature がない既存のコンテナーを登録するために使用します。 「 Connect to a Microsoft Azure Subscription」(Microsoft Azure Subscription への接続) を参照してください。
Note
[追加] は、1 つのメディア セットに対して複数のバックアップ ファイルとストレージ コンテナーをサポートします。
バックアップ先として [URL] を選択すると、 [メディア オプション] ページの一部のオプションが無効になります。 [データベースのバックアップ] ダイアログの詳細については、次の記事を参照してください。
メンテナンス プランを使用してバックアップする
前述のバックアップ タスクと同様に、SQL Server Management Studio のメンテナンス プラン ウィザードでも、バックアップ先として URL も選択できるようになりました。また、SQL 資格情報など、Azure Storage へのバックアップに必要な他のサポート オブジェクトも追加されました。 詳細については、「 メンテナンス プラン ウィザードの使用 」の「 バックアップ タスクを定義する」を参照してください。
Note
Shared アクセス トークンを使用して、ストライプ バックアップ セット、SQL Server ファイル スナップショット バックアップ、または SQL 資格情報を作成するには、メンテナンス プラン ウィザードのバックアップ タスクではなく、Transact-SQL、PowerShell、または C# を使用する必要があります。
SSMS を使用して復元する
データベースの復元タスクには、復元元のデバイスとして [URL] が含まれます。 次の手順は、復元タスクを使用して Azure Blob Storage から復元する方法を示しています。
[データベース] を右クリックして、 [データベースの復元...]を選択します。
[全般] ページで、 [ソース] セクションの [デバイス] を選択します。
参照ボタン ([...]) を選択し、[バックアップ デバイスの選択] ダイアログ ボックスを開きます。
[バックアップ メディアの種類:] ドロップダウン リストから [URL] を選択します。 [追加] を選択して、[バックアップ ファイルの場所を選択] ダイアログ ボックスを開きます。
[Azure ストレージ コンテナー]: バックアップ ファイルを格納する Microsoft Azure ストレージ コンテナーの完全修飾名。 ドロップダウン リストから既存のコンテナーを選択するか、完全修飾コンテナー名を手動で入力します。
[Shared Access Signature]: 指定したコンテナーの Shared Access Signature を入力します。
[追加]: Shared Access Signature がない既存のコンテナーを登録するために使用します。 「 Connect to a Microsoft Azure Subscription」(Microsoft Azure Subscription への接続) を参照してください。
[OK]: 指定した SQL 資格情報を使用して SQL Server が Microsoft Azure Storage に接続され、[Microsoft Azure でのバックアップ ファイルの位置指定] ダイアログ ボックスが開きます。 このページには、ストレージ コンテナーに存在するバックアップ ファイルが表示されます。 復元に使用するファイルを選んで [OK] を選択します。 これにより、[バックアップ デバイスの選択] ダイアログ ボックスが再度表示されます。このダイアログ ボックスで [OK] を選択すると、メインの [復元] ダイアログ ボックスに戻って復元を完了できます。
コード例
ここでは、次の例について説明します。
Note
Azure Blob Storage での SQL Server 2016 の使用方法に関するチュートリアルについては、「チュートリアル: Azure Blob Storage と SQL Server データベースの使用」を参照してください。
Shared Access Signature を作成する
次の例では、新しく作成されたコンテナーで SQL Server 資格情報の作成に使用できる Shared Access Signature を作成します。 このスクリプトでは、保存されているアクセス ポリシーに関連付けられた Shared Access Signature が作成されます。 詳細については、「 Shared Access Signature、第 1 部: SAS モデルについて」を参照してください。 スクリプトはまた、SQL Server に対する資格情報を作成するのに必要な T-SQL コマンドも書き込みます。
Note
この例では、Microsoft Azure Powershell が必要です。 Azure PowerShell のインストールと使用方法については、「 Azure PowerShell のインストールおよび構成方法」をご覧ください。
これらのスクリプトは、Azure PowerShell 5.1.15063 を使用して検証されます。
保存されたアクセス ポリシーに関連付けられた Shared Access Signature
# Define global variables for the script
$prefixName = '<a prefix name>' # used as the prefix for the name for various objects
$subscriptionName='<your subscription name>' # the name of subscription name you will use
$locationName = '<a data center location>' # the data center region you will use
$storageAccountName= $prefixName + 'storage' # the storage account name you will create or use
$containerName= $prefixName + 'container' # the storage container name to which you will attach the SAS policy with its SAS token
$policyName = $prefixName + 'policy' # the name of the SAS policy
# Set a variable for the name of the resource group you will create or use
$resourceGroupName=$prefixName + 'rg'
# adds an authenticated Azure account for use in the session
Connect-AzAccount
# set the tenant, subscription and environment for use in the rest of
Set-AzContext -SubscriptionName $subscriptionName
# create a new resource group - comment out this line to use an existing resource group
New-AzResourceGroup -Name $resourceGroupName -Location $locationName
# Create a new ARM storage account - comment out this line to use an existing ARM storage account
New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -Type Standard_RAGRS -Location $locationName
# Get the access keys for the ARM storage account
$accountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName
# Create a new storage account context using an ARM storage account
$storageContext = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].value
# Creates a new container in Azure Blob Storage
$container = New-AzStorageContainer -Context $storageContext -Name $containerName
$cbc = $container.CloudBlobContainer
# Sets up a Stored Access Policy and a Shared Access Signature for the new container
$policy = New-AzStorageContainerStoredAccessPolicy -Container $containerName -Policy $policyName -Context $storageContext -ExpiryTime $(Get-Date).ToUniversalTime().AddYears(10) -Permission "rwld"
$sas = New-AzStorageContainerSASToken -Policy $policyName -Context $storageContext -Container $containerName
Write-Host 'Shared Access Signature= '$($sas.TrimStart('?'))''
# Outputs the Transact SQL to the clipboard and to the screen to create the credential using the Shared Access Signature
Write-Host 'Credential T-SQL'
$tSql = "CREATE CREDENTIAL [{0}] WITH IDENTITY='Shared Access Signature', SECRET='{1}'" -f $cbc.Uri,$sas.TrimStart('?')
$tSql | clip
Write-Host $tSql
スクリプトが正常に実行されたら、CREATE CREDENTIAL コマンドをクエリ ツールにコピーし、SQL Server のインスタンスに接続し、コマンドを実行して Shared Access Signature を持つ資格情報を作成します。
資格情報を作成する
次の例では、Azure Blob Storage に対する認証に使用する SQL Server 資格情報を作成します。 次のいずれかの操作を行います。
Shared Access Signature を使用
以前のスクリプトを実行して Shared Access Signature を作成した場合は、SQL Server のインスタンスに接続されているクエリ エディターに
CREATE CREDENTIALをコピーして、このコマンドを実行します。次の T-SQL の例では、Shared Access Signature を使用した資格情報を作成します。
IF NOT EXISTS (SELECT * FROM sys.credentials WHERE name = 'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>') CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '<SAS_TOKEN>';ストレージ アカウント ID とアクセス キーを使用
IF NOT EXISTS (SELECT * FROM sys.credentials WHERE name = '<mycredentialname>') CREATE CREDENTIAL [<mycredentialname>] WITH IDENTITY = '<mystorageaccountname>' ,SECRET = '<mystorageaccountaccesskey>';
データベースの完全バックアップの実行
次の例では、Azure Blob Storage への AdventureWorks2022 データベースの完全バックアップを実行します。 次のいずれかのサンプルを使用します:
Shared Access Signature を使用した TO URL
BACKUP DATABASE AdventureWorks2022 TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'; GOストレージ アカウント ID とアクセス キーを使用した TO URL
BACKUP DATABASE AdventureWorks2022 TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak' WITH CREDENTIAL = '<mycredentialname>' ,COMPRESSION ,STATS = 5; GO
STOPAT を使用して特定の時点に復元する
次の例では、AdventureWorks2022 サンプル データベースを特定の時点の状態に復元し、復元操作を示します。
Shared Access Signature を使用した FROM URL
RESTORE DATABASE AdventureWorks2022 FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_16_00_00.bak'
WITH MOVE 'AdventureWorks2022_data' to 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.mdf'
,MOVE 'AdventureWorks2022_log' to 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.ldf'
,NORECOVERY
,REPLACE
,STATS = 5;
GO
RESTORE LOG AdventureWorks2022 FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_18_00_00.trn'
WITH
RECOVERY
,STOPAT = 'May 18, 2015 5:35 PM'
GO
関連するコンテンツ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示