RESTORE 声明 - VERIFYONLY (Transact-SQL)

適用対象:SQL ServerAzure SQL Managed Instance

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

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

注意

議論の説明については、 RESTORE Arguments (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 }   
}

注意

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

引数

RESTORE VERIFYONLY論証の説明については、RESTORE Arguments (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 は、バックアップを作成するディレクトリのルートに設定する必要があります。

アクセス許可

2008 SQL Server(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)

  • Last updated on