RESTORE ステートメント - 議論(Transact-SQL)

適用対象:SQL Server

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

Transact-SQL 構文表記規則

構文

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

• RESTORE (Transact-SQL)

• RESTORE FILELISTONLY (Transact-SQL)

• RESTORE HEADERONLY (Transact-SQL)

• RESTORE LABELONLY (Transact-SQL)

• RESTORE REWINDONLY (Transact-SQL)

• RESTORE VERIFYONLY (Transact-SQL)

引数

DATABASE

支援者:RESTORE

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

データベースで完全な復旧モデルまたは一括ログ復旧モデルを使用しているときは、ほとんどの場合、SQL Server ではデータベースの復元前にログ末尾のバックアップが必要になります。 ログの尾部をバックアップせずにデータベースを復元するとエラーが発生します。ただし、 RESTOREDATABASE 文にWITH REPLACE または WITH STOPAT 節が含まれていなければ、バックアップ終了後に発生した時刻やトランザクションが指定されなければなりません。 ログ末尾のバックアップの詳細については、「ログ末尾のバックアップ (SQL Server)」を参照してください。

LOG

支援者:RESTORE

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

詳細については、「トランザクション ログ バックアップの適用 (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 復元である場合 (結果としてファイル グループの機能停止につながる) にのみ指定できます。

完全またはバルクログのリカバリーモデルを使用するデータベースでは、 RESTOREDATABASE を使って1つ以上のファイル、ファイルグループ、ページを復元した後、通常は復元データを含むファイルにトランザクションログを適用しなければなりません。ログを適用することで、それらのファイルはデータベースの他の部分と整合します。 ただし、次の場合は例外となります。

• 復元されるファイルが最後にバックアップされる前に読み取り専用であれば、トランザクションログを適用する必要がなく、 RESTORE 文がこの状況を知らせます。

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

ファイル = { 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 ]
複数のファイル、ファイル グループ、およびページをコンマ区切りリストに指定できることを示すプレースホルダーです。 数の制限はありません。

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

通常、バックアップを復元する元のバックアップ デバイスを指定します。 あるいは、 RESTOREDATABASE 文では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アカウントがリモートコンピュータやネットワークサーバーへのREADアクセス権を持っている必要があります。

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

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

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

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

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

<database_snapshot>::=

支援者:RESTORE DATABASE

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

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

WITH オプション

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

PARTIAL

支援者:RESTORE DATABASE

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

部分的なオプションは RESTORE LOG文では許可されていません。

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

[ RECOVERY |NORECOVERY |STANDBY ]

支援者:RESTORE

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

その後の RESTORE 操作(RESTORE LOGや差分からの RESTOREDATABASE )を計画する場合は、NORECOVERYまたはSTANDBYを指定すべきです。

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

NORECOVERY

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

データベースバックアップと1つ以上のトランザクションログの復元、または複数の RESTORE 文が必要な場合(例えば、完全なデータベースバックアップの後に差分データベースバックアップを行った場合) RESTORE には、最終的な RESTORE 文以外のすべての文でWITH NORECOVERYオプションが必要です。 ベストプラクティスとしては、希望する回復ポイントに達するまで、すべての文に対してWITH NORECOVERYを複数ステップの復元シーケンスで使用し、その後は復旧専用の別の RESTORE WITH RECOVERY文を使うことです。

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

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

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

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

スタンバイ = standby_file_name

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

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

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

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

回復と回復なしの比較については、 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 ]

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

復元操作オプション

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

'logical_file_name_in_backup' を '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 場合、データベースファイルの再配置や既存ファイルとの衝突を避けるために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 からバックアップを復元する場合にのみ使用されます。

REPLACE

支援者:RESTORE

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

• 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 オプションと共に使用します。

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

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

ファイル = { 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 文を使うことで得られます。

指定しない場合、デフォルトは 1ですが、 RESTORE HEADERONLY の場合はメディアセット内のすべてのバックアップセットが処理されます。 詳細については、「バックアップ セットの指定」を参照してください。

PASSWORD = { password | @password_variable }

サポート:RESTORE、 RESTORE FILELISTONLY、 RESTORE HEADERONLY、 RESTORE VERIFYONLY。

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

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

[ 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。

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

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

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) です。

エラー管理オプション

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

{ 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 オプション

ファイルストリーム(DIRECTORY_NAME =directory_name )

サポート:RESTORE および RESTORE VERIFYONLY

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

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

監視オプション

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

STATS [ = 時間 ]

サポート:RESTORE および RESTORE VERIFYONLY

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

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

テープ オプション

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

{ 巻き戻し |NOREWIND }

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

REWIND
サポート対象:RESTORE、 RESTORE FILELISTONLY、 RESTORE HEADERONLY、 RESTORE LABELONLY、 RESTORE VERIFYONLY。

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

NOREWIND
サポート:RESTORE および RESTORE VERIFYONLY

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

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

NOREWINDはNOUNLOADを意味し、これらの選択肢は単一の RESTORE 文内で互換性がありません。

{ UNLOAD |NOUNLOAD }

サポート対象:RESTORE、 RESTORE FILELISTONLY、 RESTORE HEADERONLY、 RESTORE LABELONLY、 RESTORE REWINDONLY、 RESTORE VERIFYONLY。

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

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 LOG文では、ターゲット時間またはトランザクションを同一のSTOPAT、STOPATMARK、またはSTOPBEFOREMARK節で指定しなければなりません。

特定の時点への復元の前提条件として、最初にエンド ポイントが目的の復旧ポイントよりも前になっているデータベースの完全バックアップを復元する必要があります。 どのデータベースバックアップを復元すべきかを特定するために、オプションで RESTOREDATABASE 文でWITH STOPAT、STOPATMARK、STOPBEFOREMARKの節を指定することで、指定された目標時刻に対してデータバックアップが新しすぎる場合にエラーを発生させます。 ただし、目的の時間が指定されている場合でも常にデータのバックアップ全体が復元されます。

{ STOPAT |STOPATMARK |STOPBEFOREMARK }

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

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

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

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

RESTORE DATABASEもRESTORELOGもlsn_numberパラメータをサポートしています。 このパラメーターは、ログ シーケンス番号を指定します。

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

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

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

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

RESTORE DATABASEもRESTORELOGもlsn_numberパラメータをサポートしています。 このパラメーターは、ログ シーケンス番号を指定します。

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

RESTORE LOG文でAFTER datetimeを省略すると、指定された名前の最初のマークの直前で回復が停止します。 AFTER datetime を指定すると、datetime 以降の指定した名前を持つ最初のマークの直前に復旧が停止します。

結果セット

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

• RESTORE FILELISTONLY (Transact-SQL)

• RESTORE HEADERONLY (Transact-SQL)

• RESTORE LABELONLY (Transact-SQL)

解説

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

• RESTORE (Transact-SQL)

• RESTORE HEADERONLY (Transact-SQL)

• RESTORE LABELONLY (Transact-SQL)

• RESTORE REWINDONLY (Transact-SQL)

• RESTORE VERIFYONLY (Transact-SQL)

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

バックアップ セット には、正常に終了した 1 つのバックアップ操作のバックアップが含まれます。 RESTORE、 RESTORERESTORE FILELISTONLY、 RESTORERESTORE HEADERONLY、 RESTORERESTORE VERIFYONLY 文は、指定されたバックアップデバイスまたは複数の機器のメディアセット内の単一のバックアップセット上で動作します。 該当するメディア セット内の必要なバックアップを指定する必要があります。 バックアップセットの backup_set_file_number は RESTORE HEADERONLY 文を使うことで得られます。

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

ファイル ={ 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 番目のバックアップ セットというように示されます。

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

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

以下のWITHオプションは RESTORE 文のみでサポートされています:BLOCKSIZE, BUFFERCOUNT, MAXTRANSFERSIZE, PARTIAL, KEEP_REPLICATION, { RECOVERY |回復なし |スタンバイ}、置換、再起動、RESTRICTED_USER、そして{ STOPAT |ストップマーク |STOPBEFOREMARK}

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

{FILE | とは異なる ^{1 つの} FILE =backup_set_file_numberFILEGROUP}。

アクセス許可

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

• RESTORE (Transact-SQL)

• RESTORE FILELISTONLY (Transact-SQL)

• RESTORE HEADERONLY (Transact-SQL)

• RESTORE LABELONLY (Transact-SQL)

• RESTORE REWINDONLY (Transact-SQL)

• RESTORE VERIFYONLY (Transact-SQL)

例

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

• RESTORE (Transact-SQL)

• RESTORE FILELISTONLY (Transact-SQL)

• RESTORE HEADERONLY (Transact-SQL)

次の手順

• BACKUP (Transact-SQL)
• RESTORE (Transact-SQL)
• RESTORE FILELISTONLY (Transact-SQL)
• RESTORE HEADERONLY (Transact-SQL)
• RESTORE LABELONLY (Transact-SQL)
• RESTORE REWINDONLY (Transact-SQL)
• RESTORE VERIFYONLY (Transact-SQL)
• SQL Server データベースのバックアップと復元
• FILESTREAM(SQL Server)