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

適用対象: SQL Server Azure SQL Managed Instance

復元せずにバックアップを確認して、バックアップ セットが完全なものであること、およびバックアップのすべてが読み取り可能であることを確認します。 ただし、RESTORE VERIFYONLY ステートメントが、バックアップ ボリュームに含まれているデータの構造を確認することはありません。 Microsoft SQL Server では、データに対して追加のチェックを行い、エラーの検出率を高めることができるように RESTORE VERIFYONLY が強化されています。 この機能の目的は、実際の復元操作にできるだけ近い状況を実現することです。 詳細については、「解説」を参照してください。

バックアップが有効な場合は、SQL Server データベース エンジンでは正常に終了したことを知らせるメッセージが返されます。

注意

引数の説明については、「RESTORE の引数 (Transact-SQL)」を参照してください。

Transact-SQL 構文表記規則

構文

RESTORE VERIFYONLY  
FROM <backup_device> [ ,...n ]  
[ WITH    
 {  
   LOADHISTORY   
  
--Restore Operation Option  
 | MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name'   
          [ ,...n ]   
  
--Backup Set Options  
 | FILE = { backup_set_file_number | @backup_set_file_number }   
 | PASSWORD = { password | @password_variable }   
  
--Media Set Options  
 | MEDIANAME = { media_name | @media_name_variable }   
 | MEDIAPASSWORD = { mediapassword | @mediapassword_variable }  
  
--Error Management Options  
 | { CHECKSUM | NO_CHECKSUM }   
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }  
  
--Monitoring Options  
 | STATS [ = percentage ]   
  
--Tape Options  
 | { REWIND | NOREWIND }   
 | { UNLOAD | NOUNLOAD }    
 } [ ,...n ]  
]  
[;]  
  
<backup_device> ::=  
{   
   { logical_backup_device_name |  
      @logical_backup_device_name_var }  
   | { DISK | TAPE | URL } = { 'physical_backup_device_name' |  
       @physical_backup_device_name_var }   
}  
  

Note

URL は、Microsoft Azure Blob Storage の場所とファイル名を指定するために使用される形式であり、SQL Server 2012 (11.x) SP1 CU2 以降でサポートされています。 Microsoft Azure ストレージはサービスですが、実装はディスクやテープと似ており、3 つのデバイスすべてで一貫したシームレスな復元エクスペリエンスを実現できます。

引数

RESTORE VERIFYONLY 引数の説明については、「RESTORE の引数 (Transact-SQL)」を参照してください。

全般的な解説

メディア セットまたはバックアップ セットには、Microsoft Tape Format として解釈できるように最小限の正しい情報が含まれている必要があります。 含まれていない場合は、RESTORE VERIFYONLY が停止し、バックアップの形式が無効であることが示されます。

RESTORE VERIFYONLY で実行される確認項目には、次のようなものがあります。

  • バックアップ セットが完全で、すべてのボリュームが読み取り可能であること。

  • ページ ID など、データベース ページのヘッダー フィールドの情報 (データ書き込みを想定した確認)。

  • チェックサム (メディアに存在する場合)。

  • バックアップ先デバイスに十分な容量があるかどうか。

注意

RESTORE VERIFYONLY は、データベース スナップショットでは動作しません。 元に戻す操作を行う前にデータベース スナップショットを確認するには、DBCC CHECKDB を実行してください。

注意

スナップショットのバックアップでは、バックアップ ファイルで指定された場所にスナップショットが存在することが RESTORE VERIFYONLY によって確認されます。 スナップショット バックアップは、SQL Server 2016 (13.x) の新機能です。 スナップショット バックアップの詳細については、「Azure でのデータベース ファイルのスナップショット バックアップ」を参照してください。

セキュリティ

バックアップ操作では、オプションで、メディア セットとバックアップ セットにそれぞれパスワードを設定できます。 メディア セットまたはバックアップ セットにパスワードが設定されている場合は、RESTORE ステートメントで正しいパスワードを指定する必要があります。 これらのパスワードを設定しておくと、SQL Server ツールを使用して不正に復元操作が行われたり、メディアにバックアップ セットが不正に追加されたりするのを防ぐことができます。 ただし、BACKUP ステートメントで FORMAT オプションが使用された場合、パスワードでメディアの上書きを防ぐことはできません。

重要

パスワードによる保護は強力なものではありません。 権限の有無にかかわらず、ユーザーが SQL Server ツールを使用して不適切な復元を行わないようにすることを目的としています。 その他の手段によるバックアップ データの読み取りやパスワードの置き換えを防ぐわけではありません。 この機能は、 SQL Serverの将来のバージョンで削除される予定です。 新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションでは変更を検討してください。バックアップ保護のベスト プラクティスは、バックアップ テープを安全な場所に保存するか、バックアップしたディスク ファイルを適切なアクセス制御リスト (ACL) で保護することです。 ACL は、バックアップを作成するディレクトリのルートに設定する必要があります。

アクセス許可

SQL Server 2008 (10.0.x) 以降では、バックアップ セットやバックアップ デバイスに関する情報の取得には CREATE DATABASE 権限が必要になります。 詳細については、GRANT データベースの権限の許可 (Transact-SQL) に関する記事を参照してください。

次の例ではディスクからのバックアップを検証します。

RESTORE VERIFYONLY FROM DISK = 'D:\AdventureWorks.bak';
GO

参照

BACKUP (Transact-SQL)
メディア セット、メディア ファミリ、およびバックアップ セット (SQL Server)
RESTORE REWINDONLY (Transact-SQL)
RESTORE (Transact-SQL)
バックアップの履歴とヘッダーの情報 (SQL Server)