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

[アーティクル]
03/12/2024

適用対象: 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)

次の方法で共有

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

構文

引数

全般的な解説

セキュリティ

アクセス許可

例

参照

フィードバック

その他のリソース