RESTORE ステートメントの引数 (Transact-SQL)

  • [アーティクル]

適用対象:SQL Server

この記事では、RESTORE {DATABASE|LOG} ステートメントと、関連する一連の補助ステートメント (RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE REWINDONLY、RESTORE VERIFYONLY) の「構文」セクションで説明されている引数について説明します。 ほとんどの引数は、これら 6 つのステートメントでのみ使用できます。 各引数のサポート状況については、引数の説明で示します。

Transact-SQL 構文表記規則

構文

構文については、次の記事を参照してください。

Note

SQL Server 2014 (12.x) 以前のバージョンの Transact-SQL 構文を確認するには、以前のバージョンのドキュメントを参照してください。

引数

DATABASE

サポートしているステートメント:RESTORE

対象のデータベースを指定します。 ファイルとファイル グループのリストを指定した場合は、そのファイルとファイル グループだけが復元されます。

データベースで完全な復旧モデルまたは一括ログ復旧モデルを使用しているときは、ほとんどの場合、SQL Server ではデータベースの復元前にログ末尾のバックアップが必要になります。 RESTORE DATABASE ステートメントに WITH REPLACE 句または WITH STOPAT 句が指定されていない場合、最初にログ末尾のバックアップを行わずに、データベースを復元しようとするとエラーが発生します。これらの句は、データのバックアップ終了後の時間またはトランザクションの指定が必要となる句です。 ログ末尾のバックアップの詳細については、「ログ末尾のバックアップ (SQL Server)」を参照してください。

LOG

サポートしているステートメント:RESTORE

トランザクション ログ バックアップをこのデータベースに適用することを指定します。 トランザクション ログは順番に適用する必要があります。 SQL Server では、バックアップされたトランザクション ログがチェックされ、トランザクションが正しいデータベースに正しい順序で読み込まれていることが確認されます。 複数のトランザクション ログを適用するには、最後の復元操作を除くすべての復元操作で NORECOVERY オプションを使用します。

注意

通常、最後に復元されるログは、ログ末尾のバックアップです。 ログ末尾のバックアップ は、データベースを復元する直前 (通常は、データベースでの失敗の後) に行われるログ バックアップです。 損傷した可能性があるデータベースに関するログ末尾のバックアップを使用すると、まだバックアップされていないログ (ログの末尾) がキャプチャされるので、作業の抜けや失敗を防ぐことができます。 詳細については、「 ログ末尾のバックアップ (SQL Server)」を参照してください。

詳細については、「トランザクション ログ バックアップの適用 (SQL Server)」を参照してください。

{ database_name | @database_name_var}

サポートしているステートメント:RESTORE

ログまたはデータベース全体の復元先データベースを指定します。 変数 (@database_name_var) として指定する場合、この名前は、文字列定数 (@database_name_var = database_name) として、または ntext や text データ型を除く、文字の文字列データ型の変数として指定できます。

<file_or_filegroup_or_page> [ ,...n ]

サポートしているステートメント:RESTORE

RESTORE DATABASE または RESTORE LOG ステートメントに含める論理ファイル、論理ファイル グループ、またはページの名前を指定します。 ファイルまたはファイル グループのリストを指定できます。

単純復旧モデルを使用するデータベースでは、FILE および FILEGROUP オプションは、対象のファイルまたはファイル グループが読み取り専用の場合、またはこれが PARTIAL 復元である場合 (結果としてファイル グループの機能停止につながる) にのみ指定できます。

データベースで完全復旧モデルまたは一括ログ復旧モデルを使用している場合、RESTORE DATABASE を使用して 1 つ以上のファイル、ファイル グループ、ページを復元した後では、通常、復元したデータを含むこれらのファイルにトランザクション ログを適用する必要があります。トランザクション ログを適用すると、これらのファイルとデータベースの残りの部分の一貫性がとれるようになります。 ただし、次の場合は例外となります。

  • 復元するファイルが、前回のバックアップ時まで読み取り専用であった場合。この場合、トランザクション ログを適用する必要はありません。RESTORE ステートメントではこの状況が報告されます。

  • バックアップにプライマリ ファイル グループが含まれており、部分バックアップを実行する場合。 この場合、バックアップ セットから自動的にログが復元されるので、復元ログは必要ありません。

FILE = { logical_file_name_in_backup| @logical_file_name_in_backup_var}

データベースの復元に含めるファイルの名前を指定します。

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

データベースの復元に含めるファイル グループの名前を指定します。

指定したファイル グループが読み取り専用で、これが部分復元である場合 (つまり、WITH PARTIAL が使用される場合)、FILEGROUP は単純復旧モデルでのみ使用できます。 復元されなかった読み書き可能なファイル グループは機能していないとマークされ、ここで復元されたデータベースには以降復元できなくなります。

READ_WRITE_FILEGROUPS

読み書き可能なファイル グループをすべて選択します。 このオプションは、読み書き可能なファイル グループを復元した後で、読み取り専用のファイル グループを復元する場合に特に便利です。

PAGE = 'file: _page* [ , ...n ] '

ページ復元の対象となる 1 ページまたは複数ページのリストを指定します (ページ復元は、完全復旧モデルまたは一括ログ復旧モデルを使用しているデータベースに対してのみサポートされています)。 値は次のとおりです。

PAGE
1 つ以上のファイルおよびページで構成されるリストです。

file
復元する特定ページを含むファイルのファイル ID です。

page
ファイル内の復元対象ページのページ ID です。

n
複数のページを指定できることを示すプレースホルダーです。

復元シーケンスで 1 つのファイルに復元できる最大ページ数は、1,000 ページです。 ただし、ファイルに含まれる損傷ページの数が多い場合は、ページでなくファイル全体を復元することをお勧めします。

注意

ページ復元は復旧されません。

ページ復元の詳細については、「ページ復元 (SQL Server)」を参照してください。

[ , ...n ]
複数のファイル、ファイル グループ、およびページをコンマ区切りリストに指定できることを示すプレースホルダーです。 数の制限はありません。

FROM { <backup_device> [ ,...n ]| <database_snapshot> }

通常、バックアップを復元する元のバックアップ デバイスを指定します。 または、RESTORE DATABASE ステートメントの中で FROM 句を使用して、データベースを元に戻すためのデータベース スナップショットの名前を指定することもできます。この場合、WITH 句は使用できません。

FROM 句を省略した場合、バックアップの復元は行われず、 代わりにデータベースが復旧されます。 この機能により、NORECOVERY オプションで復元されているデータベースを復旧したり、スタンバイ サーバーに切り替えたりすることができます。 FROM 句を省略する場合は、WITH 句の中で NORECOVERY、RECOVERY、または STANDBY を指定する必要があります。

<backup_device> [ ,...n ]

復元操作に使用する、論理バックアップ デバイスまたは物理バックアップ デバイスを指定します。

サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE REWINDONLY、RESTORE VERIFYONLY。

<backup_device>::= バックアップ操作に使用する論理または物理バックアップ デバイスを、次のように指定します。

{ logical_backup_device_name | @logical_backup_device_name_var }
データベースの復元元である、sp_addumpdevice で作成されたバックアップ デバイスの論理名を指定します。この名前は識別子の規則に従っている必要があります。 変数 (@logical_backup_device_name_var) として指定する場合、バックアップ デバイス名は、文字列定数 (@logical_backup_device_name_var = logical_backup_device_name) として、または ntext や text データ型を除く、文字の文字列データ型の変数として指定できます。

{DISK | TAPE } = { 'physical_backup_device_name' | @physical_backup_device_name_var }
指定したディスク デバイスまたはテープ デバイスから、バックアップを復元することを許可します。 ディスクとテープのデバイスの種類は、DISK ='Z:\SQLServerBackups\AdventureWorks.bak' や TAPE ='\\\\.\TAPE0' のように、デバイスの実際の名前 (たとえば、完全なパスとファイル名) を使用して指定する必要があります。 変数 (@physical_backup_device_name_var) として指定する場合、デバイス名は、文字列定数 (@physical_backup_device_name_var = 'physical_backup_device_name') として、または ntext や text データ型を除く、文字の文字列データ型の変数として指定できます。

UNC 名 (マシン名を含む必要があります) を持つネットワークサーバーを使用している場合は、ディスクのデバイスの種類を指定します。 UNC 名を使用する方法の詳細については、「バックアップ デバイス (SQL Server)」を参照してください。

RESTORE 操作を実行するには、SQL Server を実行するアカウントに、リモート コンピューターまたはネットワーク サーバーへの読み取りアクセス権が与えられている必要があります。

n
最大 64 個のバックアップ デバイスをコンマ区切りリストに指定できることを示すプレースホルダーです。

以下に示すように、復元シーケンスで必要になるバックアップ デバイスの数が、バックアップが含まれるメディア セットの作成で使用したデバイスの数と同じになるかどうかは、復元をオフラインとオンラインのどちらで行うかによって決まります。

  • オフライン復元の場合は、バックアップの作成時よりも少ない数のデバイスでバックアップを復元できます。

  • オンライン復元の場合は、バックアップの作成時に使用されたすべてのバックアップ デバイスが必要です。 それより少ない数のデバイスで復元しようとしても失敗します。

たとえば、サーバーに接続している 4 つのテープ ドライブに、データベースがバックアップされているとします。 オンライン復元を行うには、サーバーに 4 つのドライブを接続する必要がありますが、オフライン復元を行う場合は、マシンに接続しているドライブが 3 つ以下でもバックアップを復元できます。

注意

ミラー化メディア セットからバックアップを復元する場合は、各メディア ファミリに対して 1 つのミラーだけを指定できます。 エラーが発生したとき、他に複数のミラーを用意しておくと復元に関する問題をすばやく解決できる場合があります。 損傷したメディア ボリュームは、別のミラーの対応するボリュームで代替できます。 オフライン復元の場合は、メディア ファミリの数よりも少ない数のデバイスから復元できますが、各ファミリは一度しか処理されないことに注意してください。

<database_snapshot>::=

サポートしているステートメント:RESTORE DATABASE

DATABASE_SNAPSHOT =database_snapshot_name
database_snapshot_name で指定したデータベース スナップショットにデータベースを戻します。 DATABASE_SNAPSHOT オプションは、データベース全体の復元にのみ使用できます。 元に戻す操作では、データベース スナップショットがデータベース全体のバックアップの代わりとなります。

指定したデータベース スナップショットが、データベース上の唯一のデータベース スナップショットであることが必要です。 元に戻す操作の実行中は、データベース スナップショットと出力先データベースの両方が In restore としてマークされます。 詳細については、「RESTORE DATABASE」の「解説」セクションを参照してください。

WITH オプション

復元操作で使用するオプションを指定します。 各オプションを使用するステートメントの概要については、この記事に後述される「WITH オプションのサポートの概要」を参照してください。

注意

ここでは、WITH オプションが「RESTORE {DATABASE|LOG}」の「構文」セクションと同じ順序で構成されています。

PARTIAL

サポートしているステートメント:RESTORE DATABASE

部分復元操作で、プライマリ ファイル グループと指定したセカンダリ ファイル グループを復元することを指定します。 PARTIAL オプションでは暗黙的にプライマリ ファイル グループが選択されるので、FILEGROUP = 'PRIMARY' を指定する必要はありません。 セカンダリ ファイル グループを復元するには、FILE オプションまたは FILEGROUP オプションで明示的にファイル グループを指定する必要があります。

PARTIAL オプションは、RESTORE LOG ステートメントでは使用できません。

PARTIAL オプションによって段階的な部分復元の初期段階を開始できるようになりました。この場合、残りのファイル グループは後で復元することができます。 詳細については、段階的な部分復元 (SQL Server) に関するページを参照してください。

[ RECOVERY | NORECOVERY | STANDBY ]

サポートしているステートメント:RESTORE

RECOVERY
復元操作に対して、コミットされていないトランザクションをロールバックすることを指定します。 復元操作の後、データベースは使用可能な状態になります。 NORECOVERY、RECOVERY、または STANDBY のいずれも指定しない場合は、RECOVERY が既定値になります。

この後 RESTORE 操作 (差分バックアップからの RESTORE LOG または RESTORE DATABASE) を予定している場合は、代わりに NORECOVERY または STANDBY を指定してください。

以前のバージョンの SQL Server で作成したバックアップ セットを復元するときには、データベースのアップグレードが必要になる場合があります。 このアップグレードは、WITH RECOVERY が指定されていれば自動的に実行されます。 詳細については、「トランザクション ログ バックアップの適用 (SQL Server)」を参照してください。

注意

FROM 句を省略する場合は、WITH 句の中で NORECOVERY、RECOVERY、または STANDBY を指定する必要があります。

NORECOVERY

復元操作に対して、コミットされていないトランザクションをロールバックしないことを指定します。 別のトランザクション ログを後で適用する必要がある場合は、NORECOVERY または STANDBY オプションのいずれかを指定してください。 NORECOVERY、RECOVERY、または STANDBY のいずれも指定しない場合は、RECOVERY が既定値になります。 NORECOVERY オプションを使用したオフライン復元操作が行われている間、データベースは使用できません。

データベース バックアップと 1 つ以上のトランザクション ログを復元する場合や、複数の RESTORE ステートメントが必要な場合 (データベース全体を復元してからデータベースの差分バックアップを復元する場合など) は、最後の RESTORE ステートメントを除くすべての RESTORE ステートメントに、WITH NORECOVERY オプションを指定する必要があります。 推奨事項としては、複数段階に分かれた復元シーケンスで、すべてのステートメントに WITH NORECOVERY を使用して目的の復旧ポイントまで復旧を行います。その後で、個別の RESTORE WITH RECOVERY ステートメントを使用して、復旧のみを行うことをお勧めします。

ファイルまたはファイル グループの復元操作で NORECOVERY を使用した場合、データベースは復元操作の後も復元中の状態になります。 これは、次の状況で効果的です。

  • 復元スクリプトが実行されていて、ログが常に適用される場合。

  • ファイルが順番に復元されており、2 つの復元操作の間でデータベースを使用できないようにする場合。

場合によっては、RESTORE WITH NORECOVERY では、ロールフォワード セットがデータベースとの一貫性を保てるポイントまでロールフォワードされることがあります。 このような場合、ロールバックは発生せず、データはオフラインのままになります。これはこのオプションに想定されている動作ですが、 データベース エンジンからは情報メッセージが返され、RECOVERY オプションを使用してロールフォワード セットを復元できるようになったことが示されます。

STANDBY =standby_file_name

スタンバイ ファイルを指定します。このファイルを使用すると、復旧の結果を元に戻すことができます。 STANDBY オプションは、部分復元を含むオフライン復元で使用でき、 オンライン復元では使用できません。 オンライン復元操作に STANDBY オプションを指定すると、復元操作は失敗します。 また、データベースのアップグレードが必要な場合も、STANDBY は使用できません。

スタンバイ ファイルは、RESTORE WITH STANDBY の Undo パスにおいて変更されるページに対して、"書き込み時コピー" のプリイメージを保持するために使用されます。 スタンバイ ファイルを使用すると、トランザクション ログの復元の間では、読み取り専用でデータベースにアクセスできます。また、このファイルは、ウォーム スタンバイ サーバーを使用する場合や、特別な復旧状況 (ログの復元の間にデータベースを調査する場合など) で使用できます。 RESTORE WITH STANDBY 操作の後、次に RESTORE 操作を行うと、UNDO ファイルは自動的に削除されます。 次に RESTORE 操作を行う前にスタンバイ ファイルを手動で削除した場合は、データベース全体をもう一度復元する必要があります。 データベースが STANDBY の状態にある間、このスタンバイ ファイルは他のデータベース ファイルと同様に扱う必要があります。 ただし他のデータベース ファイルと異なり、このファイルは、アクティブな復元操作の実行中のみ、データベース エンジンによって開かれたままになります。

standby_file_name では、場所がデータベースのログに格納されるスタンバイ ファイルを指定します。 指定した名前が既存のファイルのものである場合はファイルが上書きされ、そうでない場合はデータベース エンジンによってファイルが作成されます。

スタンバイ ファイルのサイズ要件は、復元操作において、コミットされていないトランザクションを元に戻す操作がどれだけあるかによって決まります。

重要

指定したスタンバイ ファイルが格納されるドライブでディスク容量がなくなった場合、復元操作は停止します。

RECOVERY と NORECOVERY の比較については、「RESTORE」の「解説」セクションを参照してください。

LOADHISTORY

サポートしているステートメント:RESTORE VERIFYONLY

復元操作で情報が msdb 履歴テーブルに読み込まれることを指定します。 LOADHISTORY オプションを指定した場合は、確認中の 1 つのバックアップ セットに対して、メディア セットに格納されている SQL Server バックアップに関する情報が、msdb データベース内のバックアップおよび復元履歴テーブルに読み込まれます。 履歴テーブルの詳細については、「システム テーブル (Transact-SQL)」を参照してください。

msdb 履歴テーブルに既に存在するバックアップに LOADHISTORY を使用すると、新しい backup_set_id で同じ情報が追加されることにご注意ください。 さらに、LOADHISTORY を使用して、別のサーバー上または元のサーバーから削除された後に msdb のバックアップ履歴を再作成する場合は、バックアップの復元コマンドを取得した順序で実行することをお勧めします。 これにより、LSN チェーンはそのまま維持され、SSMS 復元ウィザードでバックアップ履歴が正しく読み取られ、正しい復元シーケンスが生成されます。 LOADHISTORY を使用してバックアップ履歴を順不同で再作成すると、復元しようとした場合にエラーが発生するおそれがあります ("LSN チェーンで中断が発生したため、復元計画を作成できません。 (Microsoft.SqlServer.SmoExtended)")。

<general_WITH_options> [ ,...n ]

RESTORE DATABASE および RESTORE LOG ステートメントでは、次の一般的な WITH オプションがすべてサポートされています。 これらのオプションの一部は、説明したとおり 1 つまたは複数の補助ステートメントでもサポートされます。

復元操作オプション

以下のオプションは、復元処理の動作に影響します。

MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' [ ...n ]

サポートしているステートメント:RESTORE と RESTORE VERIFYONLY

logical_file_name_in_backup で論理名が指定されるデータまたはログ ファイルを、operating_system_file_name で指定される場所に復元して移動するように指定します。 バックアップ セット内のデータ ファイルまたはログ ファイルの論理ファイル名は、バックアップ セットが作成されたときのデータベース内における論理名と同じです。

n は追加の MOVE ステートメントを指定できることを示すプレースホルダーです。 バックアップ セットから新しい位置に復元する論理ファイルごとに、MOVE ステートメントを指定してください。 既定では、logical_file_name_in_backup ファイルが元の場所に復元されます。

注意

バックアップ セットに含まれる論理ファイルの一覧を取得するには、RESTORE FILELISTONLY を使用します。

RESTORE ステートメントを使用して、データベースを同じサーバーに再配置したり、別のサーバーにコピーするとき、データベース ファイルの再配置によって既存ファイルとの衝突が発生するのを防ぐために、MOVE オプションが必要になる場合があります。

RESTORE LOG で MOVE オプションを使用する場合は、復元するログの対象期間中に追加されたファイルを再配置するためにのみ使用してください。 たとえば、ログ バックアップにファイル file23 のファイル追加操作が含まれる場合、このファイルは RESTORE LOG で MOVE オプションを使用して再配置することがあります。

SQL Server スナップショット バックアップで使用する際は、MOVE オプションは、元の BLOB と同じストレージ アカウント内の Azure BLOB にファイルを再配置する場合にのみ使用できます。 ローカル ファイルまたは別のストレージ アカウントには、スナップショット バックアップを復元するのには、MOVE オプションを使用できません。

RESTORE VERIFYONLY ステートメントを使用して、データベースを同じサーバーに再配置するか別のサーバーにコピーする場合は、対象となるサーバーに利用可能な容量が十分あるかどうか、および既存のファイルと衝突する可能性がないかどうかを確認するために、MOVE オプションが必要になる場合があります。

詳細については、「 バックアップと復元によるデータベースのコピー」を参照してください。

CREDENTIAL

サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE VERIFYONLY。

適用対象:SQL Server 2012 (11.x) SP1 CU2 以降

Microsoft Azure Blob Storage からバックアップを復元する場合にのみ使用されます。

注意

SQL Server 2012 (11.x) SP1 CU2 から SQL Server 2016 (13.x) の場合、URL からの復元時にのみ、1 つのデバイスから復元できます。 URL からの復元時に複数のデバイスから復元するには、SQL Server 2016 (13.x) 以降を使用する必要があります。また、Shared Access Signature (SAS) トークンを使用する必要があります。 詳細については、「Microsoft Azure への SQL Server マネージド バックアップを有効にする」と「Simplifying creation of SQL Credentials with Shared Access Signature ( SAS ) tokens on Azure Storage with PowerShell」 (PowerShell を使用する Azure ストレージにおける Shared Access Signature (SAS) トークンでの SQL 資格情報の作成の簡素化) を参照してください。

REPLACE

サポートしているステートメント:RESTORE

指定したデータベースと同じ名前のデータベースが既に存在していても、SQL Server でデータベースとその関連ファイルを作成することを指定します。 この場合、既存のデータベースは削除されます。 REPLACE オプションを指定しない場合、安全性チェックが行われます。 これにより、他のデータベースを誤って上書きするのを防止できます。 安全性チェックで次の両方に該当した場合は、RESTORE DATABASE ステートメントで現在のサーバーにデータベースが復元されることはありません。

  • RESTORE ステートメントで指定したデータベースが、現在のサーバー上に既に存在する。

  • データベース名が、バックアップ セットに記録されているデータベース名と異なる。

REPLACE を指定すると、既存のファイルが復元するデータベースに属するかどうかを確認できない場合も、RESTORE でそのファイルを上書きできます。 通常、RESTORE では既存のファイルは上書きされません。 WITH REPLACE は、RESTORE LOG オプションと同じ方法で使用することもできます。

REPLACE はまた、データベースを復元する前のログ末尾のバックアップの要件をオーバーライドします。

REPLACE オプションを使用した場合の影響については、「RESTORE (Transact-SQL)」を参照してください。

RESTART

サポートしているステートメント:RESTORE

SQL Server で中断されていた復元操作を再開することを指定します。 RESTART では、中断された時点から復元操作が再開されます。

RESTRICTED_USER

サポートしているステートメント:RESTORE。

新しく復元したデータベースへのアクセスを、db_owner、dbcreator、または sysadmin ロールのメンバーに制限します。 RESTRICTED_USER は、DBO_ONLY に置き換わるオプションです。 DBO_ONLY は、SQL Server 2008 (10.0.x) で廃止されました。

RECOVERY オプションと共に使用します。

バックアップ セット オプション

以下のオプションは、復元されるバックアップを含んでいるバックアップ セットに適用されます。

FILE ={ backup_set_file_number | @backup_set_file_number }

サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE VERIFYONLY。

復元するバックアップ セットを特定します。 たとえば、 1 の backup_set_file_number は、バックアップ 目での最初のバックアップ セットを示し、2 の backup_set_file_number は 2 番目のバックアップ セットを示します。 バックアップ セットの backup_set_file_number を取得するには、 RESTORE HEADERONLY ステートメントを使用します。

値を指定しない場合は、RESTORE HEADERONLY を除き、既定値の 1 が使用されます。RESTORE HEADERONLY では、メディア セットにあるすべてのバックアップ セットが処理されます。 詳細については、「バックアップ セットの指定」を参照してください。

重要

この FILE オプションには、データベース ファイルを指定するための FILE オプション (FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }) との関連はありません。

PASSWORD = { password | @password_variable }

サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE VERIFYONLY。

バックアップ セットのパスワードを指定します。 バックアップ セットのパスワードは文字列です。

Note

この機能は、 SQL Serverの将来のバージョンで削除される予定です。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。

バックアップ セットの作成時にパスワードを設定した場合、このバックアップ セットから復元操作を実行するときにはそのパスワードが必要になります。 間違ったパスワードを指定した場合や、パスワードが設定されていないバックアップ セットにパスワードを指定した場合はエラーになります。

重要

このパスワードは、メディア セットを保護する手段としては強力なものではありません。 詳細については、各ステートメントの「権限」を参照してください。

[ METADATA_ONLY | SNAPSHOT ] [ DBNAME = { <database_name> | @database_name_variable } ]

SQL Server 2022 (16.x) で導入されています。

スナップショット バックアップから復元するために必要です。 BACKUP SERVER または BACKUP GROUP... 「Transact-SQL スナップショット バックアップを作成する」を参照してください。

METADATA_ONLY は SNAPSHOT と同義です。 仮想デバイス インターフェイス (VDI) では SNAPSHOT が使用されます。 VDI の詳細については、「仮想デバイス インターフェイス (VDI) リファレンス」を参照してください。

メディア セットのオプション

以下のオプションは、メディア セット全般に適用されます。

MEDIANAME = { media_name | @media_name_variable}

サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE VERIFYONLY。

メディアの名前を指定します。 メディア名を指定する場合、その名前がバックアップ ボリューム上のメディア名と一致している必要があります。一致していない場合、復元操作は終了します。 RESTORE ステートメントにメディア名を指定しない場合は、バックアップ ボリューム上のメディア名と一致するかどうかの確認は行われません。

重要

バックアップ操作と復元操作で同じメディア名を一貫して使用することで、復元操作で選択されたメディアに対する安全性チェックが強化されます。

MEDIAPASSWORD = { mediapassword | @mediapassword_variable }

サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE VERIFYONLY。

メディア セットのパスワードを指定します。 メディア セットのパスワードは文字列です。

Note

この機能は、 SQL Serverの将来のバージョンで削除される予定です。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。

メディア セットのフォーマット時にパスワードを設定した場合、メディア セット上のバックアップ セットにアクセスするときにはそのパスワードが必要になります。 間違ったパスワードを指定した場合や、パスワードが設定されていないメディア セットにパスワードを指定した場合はエラーになります。

重要

このパスワードは、メディア セットを保護する手段としては強力なものではありません。 詳細については、関連するステートメントの「権限」セクションを参照してください。

BLOCKSIZE = { blocksize | @blocksize_variable }

サポートしているステートメント:RESTORE

物理ブロック サイズをバイト単位で指定します。 サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および 65536 (64 KB) バイトです。 テープ デバイスの場合の既定値は 65536 バイトで、他のデバイスの場合の既定値は 512 バイトです。 通常は、RESTORE でデバイスに適するブロック サイズが自動的に選択されるので、このオプションは不要です。 ブロック サイズを明示的に指定すると、自動選択されたブロック サイズがオーバーライドされます。

CD-ROM からバックアップを復元する場合は、BLOCKSIZE=2048 と指定します。

注意

このオプションがパフォーマンスに影響するのは、通常、テープ デバイスから読み取るときだけです。

データ転送オプション

このオプションでは、バックアップ デバイスからのデータ転送を最適化できます。

BUFFERCOUNT = { buffercount | @buffercount_variable }

サポートしているステートメント:RESTORE

復元操作に使用される I/O バッファーの総数を指定します。 任意の正の整数を指定できますが、バッファー数が多いと Sqlservr.exe プロセス内で仮想アドレス空間が不足し、"メモリ不足" エラーが発生する場合があります。

バッファーで使用される領域の合計は、buffercount****maxtransfersize で決定されます。

MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

サポートしているステートメント:RESTORE

バックアップ メディアと SQL Server の間で使用される最大転送単位をバイト単位で指定します。 有効値は 65536 バイト (64 KB) の倍数で、最大有効値は 4194304 バイト (4 MB) です。

注意

データベースで FILESTREAM が構成されているか、メモリ内 OLTP ファイル グループが含まれている場合、復元時の MAXTRANSFERSIZE は、バックアップの作成時に使用されたものより大きくなります。

エラー管理オプション

このオプションでは、復元操作でバックアップのチェックサムを有効にするかどうか、およびエラー発生時に操作を停止するかどうかを指定できます。

{ CHECKSUM | NO_CHECKSUM }

サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE VERIFYONLY。

既定の動作では、チェックサムがある場合はチェックサムの確認が行われ、チェックサムがない場合は確認せずに動作が続行されます。

CHECKSUM
バックアップ チェックサムを必ず確認することを指定します。バックアップにバックアップ チェックサムがない場合、復元操作は失敗し、チェックサムがないことを示すメッセージが返されます。

注意

ページ チェックサムは、バックアップ チェックサムが使用されている場合にのみバックアップ操作に関連します。

既定では、無効なチェックサムが検出されると、RESTORE によってチェックサム エラーがレポートされ処理が停止します。 ただし、CONTINUE_AFTER_ERROR を指定した場合は、破損による影響がない限り、チェックサム エラーと無効なチェックサムを含むページ番号が返された後、RESTORE の処理が続行します。

バックアップ チェックサムの操作の詳細については、「バックアップ中および復元中に発生する可能性があるメディア エラー (SQL Server)」を参照してください。

NO_CHECKSUM
復元操作によるチェックサムの検証を、明示的に無効にします。

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE VERIFYONLY。

STOP_ON_ERROR
最初にエラーが発生した時点で、復元操作を停止することを指定します。 これは RESTORE の既定の動作ですが、VERIFYONLY の場合を除きます。この既定は、CONTINUE_AFTER_ERROR になります。

CONTINUE_AFTER_ERROR
エラーが発生した後も、復元操作を続行することを指定します。

バックアップに破損したページが含まれている場合は、エラーがない別のバックアップ、たとえばページが破損する前に作成したバックアップなどを使用して、復元操作をもう一度実行することをお勧めします。 ただし、最終的な手段として、復元ステートメントの CONTINUE_AFTER_ERROR オプションを使用して破損したバックアップを復元し、データの復旧を試みることもできます。

FILESTREAM オプション

FILESTREAM ( DIRECTORY_NAME =directory_name )

サポートしているステートメント:RESTORE と RESTORE VERIFYONLY

適用対象: SQL Server 2012 (11.x) 以降

Windows と互換性のあるディレクトリ名です。 この名前は、SQL Server インスタンス内のすべてのデータベース レベルの FILESTREAM ディレクトリ名の間で一意である必要があります。 一意性の比較では、SQL Server の照合順序の設定とは関係なく、大文字と小文字は区別されません。

監視オプション

このオプションでは、バックアップ デバイスからのデータ転送を監視できます。

STATS [ =percentage ]

サポートしているステートメント:RESTORE と RESTORE VERIFYONLY

指定したパーセンテージが完了するたびにメッセージを表示します。進行状況を判断する場合に使用できます。 percentage を省略した場合、SQL Server では約 10% 完了するごとにメッセージが表示されます。

STATS オプションでは、次のパーセンテージ間隔を報告するしきい値に達した時点までに、完了したパーセンテージを報告します。 このしきい値は、指定したパーセンテージを正確に反映するものではありません。たとえば、STATS=10 の場合、データベース エンジンでは正確に 40% ではなく、43% の時点でメッセージが表示される場合があります。 大きいバックアップ セットの場合、これは重要な問題にはなりません。それは、完了した I/O コール間の完了パーセンテージの差異はそれほど大きくないためです。

テープ オプション

このオプションはテープ デバイスにのみ適用されます。 テープ以外のデバイスが使用される場合、このオプションは無視されます。

{ REWIND | NOREWIND }

このオプションはテープ デバイスにのみ適用されます。 テープ以外のデバイスが使用される場合、このオプションは無視されます。

REWIND
サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE VERIFYONLY。

SQL Server でテープを解放して巻き戻すように指定します。 既定値は REWIND です。

NOREWIND
サポートしているステートメント:RESTORE と RESTORE VERIFYONLY

これ以外の復元ステートメントで NOREWIND を指定するとエラーが発生します。

SQL Server でバックアップ操作後にテープを開いたままにしておくことを指定します。 このオプションを使用すると、1 つのテープに対して複数のバックアップ操作を実行する場合のパフォーマンスを向上できます。

NOREWIND は暗黙的に NOUNLOAD も意味しています。この 2 つのオプションを同一の RESTORE ステートメント内で同時に使用することはできません。

注意

NOREWIND を使用する場合、テープ ドライブの所有権は SQL Server インスタンスによって保持されます。同じプロセス内で実行される BACKUP ステートメントや RESTORE ステートメントで REWIND オプションまたは UNLOAD オプションが使用されるか、サーバー インスタンスがシャットダウンすると、所有権は解放されます。 テープを開いたままにすると、他のプロセスではそのテープにアクセスできません。 開いているテープの一覧を表示する方法、および開いているテープを閉じる方法については、「バックアップ デバイス (SQL Server)」を参照してください。

{ UNLOAD | NOUNLOAD }

サポートしているステートメント:RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE REWINDONLY、RESTORE VERIFYONLY。

このオプションはテープ デバイスにのみ適用されます。 テープ以外のデバイスが使用される場合、このオプションは無視されます。

注意

UNLOAD または NOUNLOAD はセッションの設定であり、セッションが終了するまで、または代わりとなるオプションの指定によりリセットされるまで有効です。

UNLOAD
バックアップ完了後、テープの巻き戻しおよびアンロードを自動的に行います。 UNLOAD は、セッション開始時の既定値です。

NOUNLOAD
RESTORE 操作の後、テープ ドライブにテープを読み込んだままにすることを指定します。

<replication_WITH_option>

このオプションは、バックアップ作成時にデータベースがレプリケートされた場合にのみ使用します。

KEEP_REPLICATION
サポートしているステートメント:RESTORE

KEEP_REPLICATION は、ログ配布と共に動作するようにレプリケーションを設定する場合に使用します。 これによって、データベースのバックアップまたはログのバックアップをウォーム スタンバイ サーバーで復元し、データベースが復旧したときに、レプリケーションの設定が削除されるのを防ぐことができます。 NORECOVERY オプションを使用してバックアップを復元するときにこのオプションを指定することはできません。 復元の後、レプリケーションを確実に機能させるには、次のことが必要です。

  • ウォーム スタンバイ サーバーにある msdb および master データベースが、プライマリ サーバーにある msdb および master データベースと同期していること。

  • ウォーム スタンバイ サーバーの名前が、プライマリ サーバーと同じ名前に変更されていること。

<change_data_capture_WITH_option>

このオプションは、バックアップ作成時にデータベースで変更データ キャプチャが有効になっていた場合にのみ使用します。

KEEP_CDC

サポートしているステートメント:RESTORE

KEEP_CDC は、データベースのバックアップまたはログのバックアップを別のサーバーで復元してデータベースを復旧するときに、変更データ キャプチャの設定が削除されないようにするために使用する必要があります。 NORECOVERY オプションを使用してバックアップを復元するときにこのオプションを指定することはできません。

KEEP_CDC を指定してデータベースを復元すると、変更データ キャプチャ ジョブは作成されません。 データベースを復元した後にログから変更を抽出するには、復元されたデータベースに対してキャプチャ プロセス ジョブとクリーンアップ ジョブを再作成します。 詳細については、「sys.sp_cdc_add_job (Transact-SQL)」を参照してください。

データベース ミラーリングでの変更データ キャプチャの使用については、「変更データ キャプチャとその他の SQL Server 機能」を参照してください。

<service_broker_WITH_options>

Service Broker のメッセージ配信を有効または無効にするか、新しい Service Broker 識別子を設定します。 このオプションは、バックアップ作成時にデータベースに対して Service Broker が有効 (アクティブ) になっていた場合にのみ使用します。

{ ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER }

サポートしているステートメント:RESTORE DATABASE

ENABLE_BROKER
復元の終わりに Service Broker メッセージ配信を有効にして、メッセージをすぐに送信できるようにすることを指定します。 既定では、Service Broker メッセージ配信は復元中に無効化されています。 データベースは、既存の Service Broker 識別子を保持します。

ERROR_BROKER_CONVERSATIONS
データベースがアタッチまたは復元されていることを示すエラーと共に、すべてのメッセージ交換を終了します。 これによりアプリケーションは、既存のメッセージ交換に対して、通常のクリーンアップを実行できます。 Service Broker メッセージ配信はこの操作が完了するまで無効になり、その後有効になります。 データベースは、既存の Service Broker 識別子を保持します。

NEW_BROKER
データベースに新しい Service Broker 識別子を割り当てることを指定します。 データベースは新しい Service Broker と見なされるため、データベースにおける既存のメッセージ交換は、終了ダイアログ メッセージを生成せずに、直ちに削除されます。 古い Service Broker 識別子を参照するルートは、新しい識別子を使用して作成し直す必要があります。

<point_in_time_WITH_options>

サポートしているステートメント:RESTORE {DATABASE|LOG} および完全または一括ログ復旧モデルの場合のみ。

STOPAT、STOPATMARK、または STOPBEFOREMARK 句で目的の復旧ポイントを指定することで、特定の時点またはトランザクションにデータベースを復元できます。 指定された時間またはトランザクションへの復元は、常にログ バックアップから行われます。 復元シーケンスのすべての RESTORE ステートメントで、同一の STOPAT、STOPATMARK、STOPBEFOREMARK のいずれかの句で目的の時間またはトランザクションを指定する必要があります。

特定の時点への復元の前提条件として、最初にエンド ポイントが目的の復旧ポイントよりも前になっているデータベースの完全バックアップを復元する必要があります。 復元するデータベース バックアップを識別しやすくするには、RESTORE DATABASE ステートメントで WITH STOPAT、WITH STOPATMARK、WITH STOPBEFOREMARK のいずれかの句をオプションで指定し、指定した目的の時間に対してデータのバックアップが近すぎる場合はエラーが発生するようにします。 ただし、目的の時間が指定されている場合でも常にデータのバックアップ全体が復元されます。

注意

特定の時点を指定する WITH オプションは RESTORE_DATABASE と RESTORE_LOG で似ていますが、mark_name 引数をサポートするのは RESTORE LOG のみです。

{ STOPAT | STOPATMARK | STOPBEFOREMARK }

STOPAT = { 'datetime' | @_datetime_var* }
datetime または @datetime_var パラメーターで指定された日時の状態にデータベースを復元するように指定します。 日付と時刻の指定については、「日付と時刻のデータ型および関数 (Transact-SQL)」を参照してください。

STOPAT に変数を使用する場合、変数は varchar、char、smalldatetime、または datetime データ型にする必要があります。 指定した日付と時刻以前に書き込まれたトランザクション ログ レコードだけが、データベースに適用されます。

注意

指定した STOPAT 時間が前回のログ バックアップ後である場合、データベースは、NORECOVERY を指定して RESTORE LOG を実行した場合と同様に、復旧されていない状態のままになります。

詳細については、「SQL Server データベースを特定の時点に復元する (完全復旧モデル)」を参照してください。

STOPATMARK = { 'mark_name' | 'lsn:lsn_number' } [ AFTER 'datetime' ]
復旧を、指定された復旧ポイントに指定します。 指定したトランザクションは復旧に含められますが、このトランザクションがコミットされるのは、トランザクションの実際の生成時に既にコミットされていた場合のみです。

RESTORE DATABASE と RESTORE LOG の両方で lsn_number パラメーターがサポートされます。 このパラメーターは、ログ シーケンス番号を指定します。

mark_name パラメーターは、RESTORE LOG ステートメントでのみサポートされます。 このパラメーターは、ログ バックアップでトランザクション マークを識別します。

RESTORE LOG ステートメントでは、AFTER datetime を省略すると、指定された名前の最初のマークで復旧が停止します。 AFTER datetime を指定すると、datetime 以降の指定した名前を持つ最初のマークで復旧が停止します。

注意

指定したマーク LSN または時間が前回のログ バックアップ後である場合、データベースは、NORECOVERY を指定して RESTORE LOG を実行した場合と同様に、復旧されていない状態のままになります。

詳細については、「マークされたトランザクションを使用して関連するデータベースを一貫した状態に復元する方法 (完全復旧モデル)」と「ログ シーケンス番号への復旧 (SQL Server)」を参照してください。

STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' } [ AFTER 'datetime' ]
復旧を、指定された復旧ポイントまでに指定します。 指定したトランザクションは復旧に含められず、WITH RECOVERY を使用していればロールバックされます。

RESTORE DATABASE と RESTORE LOG の両方で lsn_number パラメーターがサポートされます。 このパラメーターは、ログ シーケンス番号を指定します。

mark_name パラメーターは、RESTORE LOG ステートメントでのみサポートされます。 このパラメーターは、ログ バックアップでトランザクション マークを識別します。

RESTORE LOG ステートメントでは、AFTER datetime を省略すると、指定した名前の最初のマークの直前に復旧が停止します。 AFTER datetime を指定すると、datetime 以降の指定した名前を持つ最初のマークの直前に復旧が停止します。

重要

部分復元シーケンスで FILESTREAM ファイル グループを除外した場合、特定の時点への復元はサポートされません。 復元シーケンスを強制的に実行して続行することもできます。 ただし、RESTORE ステートメントから除外された FILESTREAM ファイル グループは復元できません。 特定の時点への復元を強制的に実行するには、STOPAT、STOPATMARK、または STOPBEFOREMARK オプションに CONTINUE_AFTER_ERROR オプションを組み合わせて指定します。 CONTINUE_AFTER_ERROR を指定した場合、部分復元シーケンスは正常に実行されますが、FILESTREAM ファイル グループは復元できなくなります。

結果セット

結果セットについては、次の記事を参照してください。

解説

その他の解説については、次の記事を参照してください。

バックアップ セットの指定

バックアップ セット には、正常に終了した 1 つのバックアップ操作のバックアップが含まれます。 RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、および RESTORE VERIFYONLY ステートメントは、単一または複数の指定バックアップ デバイス上のメディア セット内にある単一のバックアップ セットに対して機能します。 該当するメディア セット内の必要なバックアップを指定する必要があります。 バックアップ セットの backup_set_file_number を取得するには、 RESTORE HEADERONLY ステートメントを使用します。

復元するバックアップ セットを指定するときのオプションは次のとおりです。

FILE ={ backup_set_file_number | @backup_set_file_number }

ここで backup_set_file_number は、メディア セット内のバックアップの位置を示します。 たとえば、backup_set_file_number が 1 (FILE = 1) の場合はバックアップ メディア内の最初のバックアップ セット、backup_set_file_number が 2 (FILE = 2) の場合は 2 番目のバックアップ セットというように示されます。

次の表で説明するように、このオプションの動作はステートメントによって異なります。

ステートメント バックアップ セットの FILE オプションの動作
RESTORE 既定のバックアップ セット ファイル番号は 1 です。 1 つの RESTORE ステートメントでは、1 つのバックアップ セットの FILE オプションのみが許可されます。 ここではバックアップ セットを順序どおり指定することが重要です。
RESTORE FILELISTONLY 既定のバックアップ セット ファイル番号は 1 です。
RESTORE HEADERONLY 既定では、メディア セット内のすべてのバックアップ セットが処理されます。 RESTORE HEADERONLY の結果セットでは、メディア セット内における位置など、各バックアップ セットに関する情報が返されます。 特定のバックアップ セットの情報が返されるようにするには、その位置番号を FILE オプションの backup_set_file_number 値として使用します。

注:テープ メディアの場合、RESTORE HEADER では、読み込まれているテープのバックアップ セットのみが処理されます。
RESTORE VERIFYONLY 既定の backup_set_file_number は 1 です。

注意

バックアップ セットを指定するための FILE オプションには、データベース ファイルを指定するための FILE オプション (FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }) との関連はありません。

WITH オプションのサポートの概要

次の WITH オプションは、RESTORE ステートメントのみがサポートしています。BLOCKSIZE、BUFFERCOUNT、MAXTRANSFERSIZE、PARTIAL、KEEP_REPLICATION、{ RECOVERY | NORECOVERY | STANDBY }、REPLACE、RESTART、RESTRICTED_USER、{ STOPAT | STOPATMARK | STOPBEFOREMARK }

注意

PARTIAL オプションは、RESTORE DATABASE でのみ使用できます。

次の表は、1 つ以上のステートメントで使用できる WITH オプションと、各オプションの対応ステートメントの一覧です。 チェックマーク (√) はそのオプションが使用できることを示し、ダッシュ (-) は使用できないことを示します。

WITH のオプション RESTORE RESTORE FILELISTONLY RESTORE HEADERONLY RESTORE LABELONLY RESTORE REWINDONLY RESTORE VERIFYONLY
{ CHECKSUM

| NO_CHECKSUM }		 -
{ CONTINUE_AFTER_ERROR

| STOP_ON_ERROR }		 -
FILE1 - -
LOADHISTORY - - - - -
MEDIANAME -
MEDIAPASSWORD -
MOVE - - - -
PASSWORD - -
{ REWIND | NOREWIND } REWIND のみ REWIND のみ REWIND のみ -
[統計] - - - -
{ UNLOAD | NOUNLOAD }

1 FILE =backup_set_file_number, which is distinct from {FILE | FILEGROUP}.

アクセス許可

権限については、次の記事を参照してください。

例

たとえば、次の記事を参照してください。

次の手順